Monday, January 19, 2015

Digest for comp.lang.c++@googlegroups.com - 5 updates in 3 topics

David Brown <david.brown@hesbynett.no>: Jan 19 09:37AM +0100

On 17/01/15 11:00, Jorgen Grahn wrote:
>> advantages. If I write modern C++, I need to make sure I have a very
>> recent compiler that supports the features
 
> Surely almost anyone can get at least to the C++98 point today?
 
By "modern C++", I meant "C++11" or above, rather than C++98/C++03.
There are a fair number of features introduced in C++11, and enhanced in
C++14 (and C++17), that greatly improve the language (in my humble and
not too experienced opinion).
 
> market for non-Unix embedded environments is shrinking, and that gcc
> (including the C++ compiler) is replacing proprietary C compilers
> inside that market, too.
 
gcc (and occasionally clang) is certainly taking more of the embedded C
and C++ space. In particular, it dominates the ARM development market,
and is also very popular for AVR and msp430, and for new architecture,
gcc and/or clang is almost always the starting point for the tools. But
there are lots of parts of the embedded world where gcc is rarely seen.
In safety-critical or automotive industries, companies are extremely
conservative - suppliers like Green Hills or IAR dominate even when gcc
gives a better compiler. In legal terms, if something goes wrong, "I
paid lots of money for an "industry standard" certified development
tool" is a better defence than "I picked the tool with fewest bugs".
And for smaller cpus, like the infamous 8051, there are no gcc ports.
 
One of the reasons for this is that C++ is getting increasingly
difficult to parse and implement. Proprietary vendors simply cannot
keep up with the development costs, and do not try.
 
And for targets which are not dominated by gcc, C++ support is generally
limited and expensive. It seldom goes beyond C++03 standards, and C++
support can cost many times the price of a C compiler. (For example,
Metrowerks for Freescale's chips is free for most targets up to a quite
usable code size limit, as long as you stick to C - write a single line
of C++, and you need $5K for a permanent license.)
 
 
Much of the embedded industry can be incredibly backwards regarding
language support. Two or three years ago I saw an advert for the latest
version of a DSP development suite, costing multiple $K - "now
supporting most of C99" (no C++ of any sort). MISRA-C, the coding
standard required for automotive development in the EU, upgraded to C99
support in 2012. At our company we have newly-purchased development
tools (for conformance testing of a communications stack) that can only
be run on DOS - without any virtualisation.
 
And while in the *nix world it is not uncommon to find C code whose
heritage goes back 20 years, in the embedded world the same code needs
to be compiled on the 20 year old tools for the 20 year old
architecture. (I think modification of 19 year old code is my personal
record.)
 
For this sort of thing, language stability in C is clearly an advantage.
Arguably, picking the current best supported C++ version and sticking
with that for the next 20 years is a better choice - and in some cases,
that is true. But a new C programmer educated and trained in C11 would
have little problem understanding and working with C90 code, while a new
C++ programmer trained only in C++14 would find C++98 code a different
language. There are pros and cons here.
 
For other types of embedded development, the power and flexibility of
modern C++ is essential - at the other end of the scale from these
long-term systems, there are embedded products that get 3 months of
development, three months of sales, and then they are obsolete.
 
 
> There are plenty of good C programmers around, and you sometimes want
> to cooperate with them. No, scratch that: you /frequently/ want to
> cooperate with them.
 
(Of course, there are plenty of /bad/ C programmers around too!)
 
> time learning C++!". C++ is, to me, a logical next step. If you're
> good with C, you'll be even better with C++, and nothing you've
> learned so far is wasted.
 
I am not sure that is true. C is a far simpler language than C++ - for
the same amount of time and effort, you can be an expert C programmer or
a mediocre C++ programmer. Which is best for the job? The skills
needed for good C programming and good C++ programming are highly
related, but not identical.
 
And while a good C++ program has many advantages over a good C program,
a /bad/ C program is, I think, easier to understand and fix than a /bad/
C++ program.
 
> "crippled" part. It's not derogatory. It's just how I see my own C
> programming: I know how I would have written the code in C++, but I
> have to translate it to less expressive C code.
 
"Crippled" implies that the language has changed from being a fully
working and useful language into something more limited and sub-optimal.
The rise of an alternative language, C++, that is often a better choice
than C does not mean that C is crippled. It merely means that C has
stayed still while C++ has moved on.
 
 
> C can, objectively, be seen as more or less a small subset of C++, and
> C++ is readily available for free to almost everybody. In that sense C
> is crippled.
 
No. EC++ was crippled, because they started with C++ and took out many
useful parts for no good reason. C is not crippled, because it is the
same as it always has been.
 
> tried to emulate C++ in C I would be as rude as the C programmers
> writing C++ code as if it was C -- but I cannot ignore the lessons C++
> taught me, about the merits of type safety and so on.
 
There is no single "correct" way to write C or C++ - and IMHO
well-written code in any language uses the language, the compiler and
other tools as "safely" as possible.
 
legalize+jeeves@mail.xmission.com (Richard): Jan 19 11:38PM

[Please do not mail me a copy of your followup]
 
Martijn Lievaart <m@rtij.nl.invlalid> spake the secret code
>older (extinct) microprocessors had rather slow indirect function calls,
>so that may also spark those 'no virtual functions' rants. In the end,
>profile, profile, profile.
 
In this case, I am talking about a particular discussion I had with
some game developers where they yelled out how virtual functions were
bad and I drilled down to find out the real problem which was keeping
your cache hot. Virtual functions and hot caches are not
incompatible, but if you blindly use virtual functions all over the
place without regards to how it affects your cache, then you can have
problems. They may think that they "solved" the problem by banishing
virtual functions, but when you banish virtual functions you're forced
to organize your code differently and it was the different
organization that gave them hot caches, not the banishment of virtual
functions.
 
Again, it comes down to measurement and understanding system performance
as a whole and not simplistically avoiding things like virtual functions,
std::vector or C++ for that matter. But hey, it's more "exciting" to
screech against virtual functions than it is to repeat the
time-honored advice of keeping your caches hot.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
scott@slp53.sl.home (Scott Lurndal): Jan 19 03:16PM

>foo.cpp:6:11: warning: using the result of an assignment as a
> condition without parentheses [-Wparentheses]
 
>I am not sure if that is what you asked for.
 
And on the lhs, g++ will warn that "statement has no effect".
"Öö Tiib" <ootiib@hot.ee>: Jan 19 10:37AM -0800

On Monday, 19 January 2015 17:16:54 UTC+2, Scott Lurndal wrote:
> > condition without parentheses [-Wparentheses]
 
> >I am not sure if that is what you asked for.
 
> And on the lhs, g++ will warn that "statement has no effect".
 
You mean cases when 'a == b;' is accidentally written instead of 'a = b;' or 'a != b;' is written instead
of 'a = !b;'?
That is [-Wunused-value] also turned on by -Wall.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jan 18 08:34PM -0500

Should the code below print 1 or -1? I think -1, but the standard library
implementations I tried printed 1; who is right and why?
 
Thanks in advance,
-Pavel
 
#include <iostream>
#include <sstream>
 
using namespace std;
 
int main(int, char*[]) {
const string s(1, 'A');
istringstream iss(s);
char c;
iss >> c;
cout << iss.rdbuf()->pubseekoff(0, ios_base::cur, ios_base::in) << endl;
return 0;
}
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)