On 08/10/2010 00:43, Dombo wrote:
> David Brown schreef:
>> On 06/10/2010 21:53, Dombo wrote:
>>> David Brown schreef:
>>>> On 06/10/2010 03:31, Frank Buss wrote:
>>>>> Dombo wrote:
>>>>>
>>>>>> My experience is that syntax differences are easy to overcome,
>>>>>
>>>>> You are right, if you don't do advanced stuff, e.g. member function
>>>>> pointers or template metaprogramming, which can be really
>>>>> indecipherable,
>>>>> if you are not Scott Meyers :-)
>>>
>>> The books of Scott Meyers, though somewhat dated, contain a lot of good
>>> advise and are easy to read.
>>>
>>
>> The guy has his own personal warning flag in gcc - it seems a lot of
>> people agree with his advice.
>>
>> <http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Weffc_002b_002b-176>
>>
>>
>> "Effective C++" is a book I've been planning to get for a while - this
>> thread has prompted me to actually order it. The third edition is from
>> 2005, so it's presumably been updated a bit. Is "More Effective C++"
>> also any good? It doesn't look like it has been updated since 1995.
>
> Yes, "More Effective C++" is definitely worthwhile.
>
> You may also want to take a look here: http://www.gotw.ca/gotw/index.htm
>
That's a dangerous site! (I could spend /far/ too long reading the
articles...)
>>> If you really want to see how far one can go with C++ templates take a
>>> look at "Modern C++ Design" from Andrei Alexandrescu; this books takes
>>> metaprogramming in C++ to whole different level using the template
>>> mechanism as a sort of functional program language to generate code. As
>>> ingenious as the template techniques presented in this book are, they
>>> are (IMO) too hard to understand even for experienced C++ programmers.
>>> When this book came out the same applied also to most C++ compilers of
>>> the day; since then the Loki library presented in this book is used as a
>>> benchmark for C++ compilers.
>>
>> Would that be " Modern C++ Design, Applied Generic and Design Patterns"
>> by Scott Meyers - John M. Vlissides - Andrei Alexandrescu -
>> Alexandrescu, Andrei ? I hope so, because I've just ordered it!
>
> Apparently so, though in the book I have Scott Meyers & John M.
> Vlissides on wrote the foreword.
>
> This book was an eyeopener to me that C++ templates could be used for
> much, much more than generic containers of type T and generic functions.
> However I haven't found much use for the techniques presented in this
> book simply because they are way beyond the knowledge of the average C++
> programmer, and frankly at times also beyond my understanding of C++
> (which I was taught in 1992, and I have used it for the majority of
> projects I have done since 1995 so I do consider my knowledge of C++ a
> bit above average). Since the code I'm responsible for needs to be
> maintained by people that are not necessarily C++ gurus, the
> 'understandability' of code is an important concern for me.
>
Understandability is certainly critical in programming. But sometimes
it's okay for one person to write code that is tough to understand, but
others can use - after all, how many programmers could read the source
of their compiler's libraries and understand it? And there are many
more users of boost than wizards who can read and write such code.
>
>> I can't claim to be a very experienced C++ programmer - I've used
>> enough to know there is a lot to like, and a lot to dislike in the
>> language. And I've seen enough of other people's C++ code to know
>> there is a huge amount of badly written C++ code out there, but that
>> it's also possible to write very nice code.
>
> The skill of the programmer is very important with C++, more so than
> with simpler programming languages (such as C) or a more restrictive
> programming languages (such as Java).
>
Agreed.
>
>> Template programming appeals to me - there's a lot that can be done
>> with it. I've heard many people talk about how template programming
>> leads to code bloat, and it's a terrible thing for embedded
>> programming (where code space is often at a premium). I think that
>> when done well, it can lead to much smaller code as well as neater and
>> clearer source. In particular, templates let the compiler do more work
>> at compile time, and save the target from work at run time. So a book
>> on advanced template programming is definitely of interest to me.
>
> Templates can be great for generic libraries (e.g. the boost library),
> and do not necessarily create code bloat (though easily can when one is
> not careful). However writing a good and efficient templated C++ library
> requires a lot of skill and know-how. It helps a lot if one has a mental
> picture how the compiler works. My experience is that this can be
> expected only from a very few C++ programmers.
>
I don't yet have a lot of practical experience with C++ projects, but I
have a better understanding of how compilers work than most programmers.
I write my C code with a very firm idea of how the compiler will
interpret the code, and what sort of object code it will produce. I do
the same with the C++ code I have worked with, especially when trying
out different formulations - I like to understand the detailed meaning
of the source code according to the standards, as well as reading the
assembly code in practice.
>> One of the things that has kept me back from doing more C++
>> programming is the state of compilers and standards. Compiler features
>> such as link-time optimisation (or whole-program IPA, or whatever a
>> particular toolset likes to call it) mean that code can be structured
>> in completely different ways. You no longer need to define all the
>> little getter/setter style functions for a class in its header file -
>> even if they are in a cpp file, LTO means they can be inlined
>> properly. And "auto" type inference means that you no longer have to
>> write immensely ugly type names when using templates (the syntax is
>> still ugly in the definitions of the templates, but at least that's
>> hidden in the implementation part).
>
> Advances in compiler technology means that some advise with respect to
> efficiency that was good a decade ago is poor advise today. I still
> regularly have to demonstrate to people that ugly hacks that they think
> are more efficient than well written (straightforward) code actually
> aren't more efficient with modern compilers and at times even less
> efficient.
>
Yes, been there and done that. I also cringe when re-reading some of my
old code, with things like local pointer variables for stepping through
arrays. It used to be the case that this sort of "source level
optimisation" made smaller and faster code - now the opposite is true.
>>> Exceptions are not necessarily bad, but exceptions do require a
>>> different coding style; if one is not familiar with the RAII idiom one
>>> better is better off avoiding the use of exceptions in C++ program.
>>
>> You can use RAII even without exceptions, but obviously you have to
>> handle your errors explicitly. Otherwise I agree with you - exceptions
>> /can/ be a good thing, but they can also be a bad thing. If you are
>> going to use exceptions, you have to consider them throughout your
>> entire program. The worst thing is when a function throws an exception
>> deep within the program, and the programmer had not considered that
>> possibility - the exception propagates and may cause far more harm
>> than if the function had simply returned an invalid result.
>
> On the other hand with return values it is all to easy to ignore return
> codes that indicate an error. Also propagating an error from the point
> where it is detected to the point where it handled involves typically a
> lot of code that really doesn't improve the overall clarity. It is
> tempting for many programmer just 'forget' to handle that unlikely
> failure scenario.
>
Programmers can always find ways to "simplify" their code.
Use of lint-type programs, or at least compilers with lots of warnings,
can help. For example, with gcc you can give a function an
"warn_unused_result" attribute. If the programmer ignores the return
code, it gives a compiler warning. Of course, the programmer can still
ignore the warning...
> It is unfortunate that the C++ exception specification is worse than
> useless and is best avoided. In Java exception specifications are
> mandatory and enforced at compile time, so it is instantly obvious for
> the caller what kind of exceptions to expect. It would be nice to have
> something similar in C++, rather than the current runtime check of the
> exception specification.
>
Yes - I think functions should by default be "throw()" so they cannot
propagate exceptions unless explicitly allowed. And of course,
exception specifications should work like people think they work, not as
they /do/ work. In other words, they should be checked and enforced at
compile time (not run time), and they should allow the compiler to
optimise on the assumption that functions behave according to their
declared exception specification.
Most compilers probably do try to figure out if exception specifications
are held or violated at compile time, but they can't do that across
compilation units (at least, not without some sort of link-time
optimisation). And compilers vary as to whether they actually enforce
the specifications at run time (as the standard says they should).
Apparently MS VC++ does not (or did not) enforce them, and gcc has a
flag to tell it not to check them at run-time.
>> Consider, for example, a function that displays a value on a screen
>> with three digits. A typical C implementation would either ignore the
>> possibility of the value being over 999 (perhaps that's a valid
>> assumption in that program), or display either 999 or something like
>> ###. If your C++ version decides to throw an exception in that case,
>> it could lead to better error handling. But if the code that uses that
>> function does not take account of the possibility of the exception,
>> then an overflow that would otherwise result in a slightly strange
>> display will instead probably lead to a total program failure.
>
> On the other hand just muddling along with invalid data can have
> disastrous consequences as well. I have worked on systems where the
> software is actually deliberately stopped as soon as a pre- or
> postcondition violation is detected, just to prevent from failures go
> unnoticed and causing more costly (and difficult to analyze) problems
> later.
>
> It depends very much on the kind of application which behavior is more
> desirable.
>
>> Exceptions are also expensive - they can be very code space, run time
>> and data/stack space costly, especially on small processors. They also
>> enforce limitations on the compiler's ability to re-arrange code since
>> functions can have extra side effects, and this will hobble the
>> optimiser.
>
> Exceptions can be implemented by the compiler in various ways, with some
> implementations the runtime overhead is zero as long as no exceptions
> are thrown, at the expense of more runtime overhead when exceptions are
> thrown. However when every byte counts exceptions are not a good choice.
>
>> All in all, exceptions are something you should only use (particularly
>> in embedded systems) if you have thought through the consequences and
>> decided that implementing them throughout the program is a good thing
>> overall.
>
> True, but this applies to most features in C++. Are exceptions good or
> bad? As with most things it is a trade-off and the only right answer is:
> "it depends".
>
That's certainly true.
>>> Especially on platforms with limited resources a downside of C++ is that
>>> the compiler can generate a lot more code behind the scenes than is
>>> immediately apparent when looking at the source code. C++ wouldn't be my
>>> first choice when the target is a 8-bit uC with 1K program memory.
>>
>> It depends on how you use it. C++ certainly makes it easier to hide
>> large amounts of code behind seemingly minor statements. But it can go
>> the other way too. I've done some tests with C++ on the avr, and it
>> can go both ways. Sometimes the use of classes means the compiler
>> can't recognise certain patterns, and it produces poorer code than if
>> plain data types were used. But other times it does better - wrapping
>> an eight bit variable in a class will stop the compiler from doing
>> 8-bit to 16-bit integer promotion, and can give smaller code.
>
> Agreed.