«

On 10/18/12 22:17, jacob navia wrote:
>
> The language has grown SO complex that nobody knows ALL the subtleties
> of it. Most programmers know a small subset that they use (30-40%), and
> ignore the rest. Experts may know 60-70%, but nobody really understands
> it ALL.

You never seem to get the point that there is nothing wrong with cherry
picking language features. A project team should agree which features
they want to use and stick with them until they are happy to embrace
more. Maybe they never will, that fine, the choice is theirs. At least
they are able to make a choice.

Even you recognise some of the benefits C++ can offer by including C++
like extensions to your compiler.

You may call be biased, but I was a C programmer for over a decade
before I learned C++ and two decades later I still work on C as well as
C++ projects. But I really miss some C++ features when I'm working in
C, RAII more than anything else. I guess its much the same as missing
the 1st class menu when flying economy!

--
Ian Collins

On 10/18/2012 03:55 AM, Stuart wrote:
> On 10/18/12 James Kuyper wrote:
> [snip]
>> I'm primarily a C programmer, so I may be
>> missing out some elegant C++ way of doing that, but the following
>> inelegant (and untested) code should do the job:
> [snip]
>
> I'm intrigued. I have never ever met someone who described himself as a
> C programmer. May I ask what kind of business you are in? My guess is
> your line of work includes either device drivers, embedded devices,
> kernel code or something else that forces you to write C instead of C++.

I don't work in any of the areas you listed. I'm a scientific computer
programmer. My programs process data sent down from instruments mounted
on satellites (mainly geolocation and calibration of images). They run
24-7 in a production environment with no user interaction; they just
read and write files. The production system itself is controlled by a
GUI which interacts with the operators, but my programs themselves do not.

> In all these years I have never met someone who used C instead of C++
> unless he was forced to do so.

Our contract with our client imposes requirements on our delivered code.
Among other things, the permitted languages are C95, Fortan 77, Fortran
90, or Ada. So that part you got right.

I recently started work on an additional project covered by a different
contract with fewer restrictions, and most of the code is in C++. I've
found my extensive knowledge about C++ more useful than I expected, and
my lack of C++ experience less of a problem than I'd feared.
--
James Kuyper

jacob navia wrote:

> Le 18/10/12 09:55, Stuart a écrit :
>> On 10/18/12 James Kuyper wrote:
>> [snip]
>>> I'm primarily a C programmer, so I may be
>>> missing out some elegant C++ way of doing that, but the following
>>> inelegant (and untested) code should do the job:
>> [snip]
>>
>> I'm intrigued. I have never ever met someone who described himself as a
>> C programmer.
>
> C++ people think that their extremely complex language is the best of
> all worlds. They have so little consideration for other views that
> they really think, as you say:

I don't believe that anyone can really claim, at least with a straight face,
to know how everyone who ever learned to program in a specific programming
language thinks.


> > I have never met someone who used C instead of C++
> > unless he was forced to do so.
>
> I have never used C++ unless I was forced to.
>
> C++ is a mistake. It has produced a language that nobody understands,
> not even Stroustrup himself.

The C++ language is complex, but your claim that "nobody understands" it is
based on a definition of "understands" that is a bit distorted and
inflamatory.

Throughout the years, plenty of complex pieces of software were successfully
implemented in C++, to the point that it seemed that the entire software
industry was based on C++. That wouldn't have happened if no one understood
the C++ programming language. So, in this aspect, your claim that "nobody
understands" C++ is patently false.

But then, although that was what you actually said, that certainly wasn't
what you meant. You certainly referred to the difficulty of gaining
complete insight into how each and every tiny bit of the language works and
interacts with anything else. The C++ programming language is complex.
Yet, you failed to mention that the complexity issue isn't exclusive to C++,
nor it is a significant limitation.


> But let's come back to reality. I will not convince you that simplicity
> outperforms complexity in software engineering.
>
> So, be assured that C++ is the best invention since sliced bread.

You are the only person suggesting that claim.


Rui Maciel

jacob navia wrote:

> Le 18/10/12 10:23, Juha Nieminen a écrit :
>> In comp.lang.c++ jacob navia <> wrote:
>>> C++ is a mistake. It has produced a language that nobody understands,
>>> not even Stroustrup himself.
>>
>> To make such an inflammatory post on a C++ group you are either
>> incredibly stupid or the worst kind of troll. (And that's an inclusive
>> 'or'.)
>>
> To say in a C group (comp.lang.c)
>
> > I have never met someone who used C instead of C++
> > unless he was forced to do so.
>
> is NOT inflammatory, of course.
>
> I did NOT treat anyone of "stupid" or "troll" Mr Nieminen.

It is, nevertheless, provocative. You have to admit that.


> Just some facts to put this discussion in a less polemic tone:
>
> 1) Mr Stroustrup gave up on "concepts" after several YEARS of work. He
> could not (as he said) understand all the implications that the change
> could have, nor could the people in the standards committee so they just
> balked out.
>
> For me, in my stupid little mind, it means that nobody could really
> understand the consequences of a modification of the language and that
> the languagve has gotten too complex for humans to understand. You need
> a machine to understand c++

You are referring to a change which, although it was proposed and considered
by the standards committee, wasn't made a part of the language. That means
that you aren't really referring to C++'s complexity as it stands, you are
referring to the complexity of a specific proposal. Bolting on a formal
verification system on a programming language isn't a trivial thing to pull,
particularly on a metaprogramming system. Would you claim that nobody
understood the C programming language if no one succeeds in bolting on a
formal verification system to it?


> 2) Further proof that C++ is a language humans can't fully understand is
> the fact that the specifications for operator overloading (for instance)
> go for pages and pages of the C++ standard and require in the last
> resort a topological sort of all possible classes involved. This means
> that it can only be done in a moderately complex application by a
> machine (i.e. a compiler) that will do the sort and produce its result
> that can be (maybe) followed by humans in a super human effort but
> can't be done in a daily basis by the C++ programmers that can only
> GUESS that their code is right.
>
> 3) And yet another proof is that when somebody asks something in the
> C++ group the answer is in MOST cases
>
> "I compiled it with compiler XXX and the answer was YYY"
>
> and NOT
>
> "The correct answer should be YYY because the standard specifies ..." etc.

That is a silly argument to make. The C programming language wouldn't
suddenly become a language that nobody understands if comp.lang.c was
suddenly flooded by people who answered "I compiled it with compiler X and
the answer was Y".


> People give as a ROUTINE answer the answer the machine proposes them,
> not the answer they deduced since understanding a statement can be
> an impossible task.
>
> The language has grown SO complex that nobody knows ALL the subtleties
> of it. Most programmers know a small subset that they use (30-40%), and
> ignore the rest. Experts may know 60-70%, but nobody really understands
> it ALL.

That is irrelevant. Some C++ projects specifically state in their coding
guidelines that feature X and Y should not be used, which tend to influence
specialization. In addition, certainly you are aware that C++'s support for
metaprogramming was a fluke, and that no one is really required to fully
understand every obscure consequence of a fluke to be able to employ the
programming language efficiently. Would it be fair if people started to
make the same claim regarding C if a significant number of C programmers
weren't aware of Duff's device or every obscure alignment requirement
imposed by the standard?


> Is it necessary for humans to understand completely a machine language?

No, and the same applies to pretty much any technical field. For example,
for ages buildings have been built in spite of the science behind them being
far from fully understood.


Rui Maciel

Am 10/18/12 1:18 PM, schrieb James Kuyper:
> On 10/18/2012 03:55 AM, Stuart wrote:
>> On 10/18/12 James Kuyper wrote:
>> [snip]
>>> I'm primarily a C programmer, so I may be
>>> missing out some elegant C++ way of doing that, but the following
>>> inelegant (and untested) code should do the job:
>> [snip]
>>
>> I'm intrigued. I have never ever met someone who described himself as a
>> C programmer. May I ask what kind of business you are in? My guess is
>> your line of work includes either device drivers, embedded devices,
>> kernel code or something else that forces you to write C instead of C++.
>
> I don't work in any of the areas you listed. I'm a scientific computer
> programmer. My programs process data sent down from instruments mounted
> on satellites (mainly geolocation and calibration of images). They run
> 24-7 in a production environment with no user interaction; they just
> read and write files. The production system itself is controlled by a
> GUI which interacts with the operators, but my programs themselves do not.
>
>> In all these years I have never met someone who used C instead of C++
>> unless he was forced to do so.
>
> Our contract with our client imposes requirements on our delivered code.
> Among other things, the permitted languages are C95, Fortan 77, Fortran
> 90, or Ada. So that part you got right.


Then I would have chosen Ada without a moments hesitation. I fell in
love with that language right away, and I believe that Ada compilers and
C++ compilers are equally complicated. It's a pity that Ada did not gain
the popularity of C++ but that is probably due to the fact that Ada came
too late (I know that C++ emerged later than Ada, but by that time
probably too many people were using C already, and the transition from C
to C++ is more "natural" than the transition from C to Ada, I guess).


> I recently started work on an additional project covered by a different
> contract with fewer restrictions, and most of the code is in C++. I've
> found my extensive knowledge about C++ more useful than I expected, and
> my lack of C++ experience less of a problem than I'd feared.

When I started programming with C++ I did not want to learn too much,
especially not that nifty template stuff. My coding style in those days
can best be described as "C-ish": I wrote the usual procedural code, but
instead of messing around with char* pointers and strcpy, I used
std::string (I only realized much later that this is already a templated
class).

Later I started to write my own classes and was thrilled. OOP! My man,
this rocked.

On day I stumbled upon a loop that ran really slow: It iterated over the
pixels of an image. Since my image could be either 8bits or 16bits so I
had to provide a virtual getPixel method. This was particularly clumsy:
My algorithm had to invoke a virtual method million of times only to
discover that it actually invoked the _same_ method each time. It would
be much better if I could have two versions of the same algorithm for
two different data types, thus avoiding the million virtual method
invokations.

It turned out that all I had to do was to make it a template function.
Easy, peasy, japanesey.

That's how it all started with this template stuff. Ten years later I
was writing code like this

template<class t_BaseImpl, class t_CoClass = t_BaseImpl::CoClassType>
class HAirCushionSwitchHelper : public t_BaseImpl
{
...

even before I had my morning coffee.

Admittedly, I have not had the guts to delve deeper into template
metaprogramming, but one should never say never. That's what I like
about C++: There is always a new continent to discover, but only when
you need it.

Regards,
Stuart

Juha Nieminen <> writes:
> In comp.lang.c++ Richard Damon <> wrote:
>> If its size is not know at compile time, then its memory allocation must
>> be dynamic. (In C99, but not C++ except as an extension, it could also
>> be of storage type auto).
>
> I think you are confusing variable-length arrays (in C) with the keyword
> 'auto', which has absolutely nothing to do with that (in either language).

Richard didn't mention the "auto" *keyword*. I think his point is
that a VLA must have automatic storage duration ("storage type auto"
was not the best way to phrase that).

Which is true for *identifiers* defined as VLAs, but not for all VLAs:

int x = /* whatever */;
int y = /* whatever */;
typedef double vla[x][y];
vla *ptr = malloc(sizeof *ptr);
if (ptr == NULL) {
/* allocation failed */
}

This lets you allocate a VLA on the heap. It has the advantage that
you can easily use array notation to access elements of the VLA:

(*ptr)[i][j]

without having to manage arrays of pointers, and you can test
whether the allocation succeeded.

(You can't do this in C++, but the standard library provides ways to do
similar things.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 10/19/12 09:52, William Ahern wrote:
> In comp.lang.c Stuart<> wrote:
>> On 10/18/12 James Kuyper wrote:
>> [snip]
>>> I'm primarily a C programmer, so I may be
>>> missing out some elegant C++ way of doing that, but the following
>>> inelegant (and untested) code should do the job:
>> [snip]
>
>> I'm intrigued. I have never ever met someone who described himself as a C
>> programmer. May I ask what kind of business you are in? My guess is your
>> line of work includes either device drivers, embedded devices, kernel code
>> or something else that forces you to write C instead of C++. In all these
>> years I have never met someone who used C instead of C++ unless he was
>> forced to do so.
>
> Well, you have now. I've worked in several shops (both small and billion
> dollar companies) which were C only by choice. The consensus was that the
> cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.
> When you're writing high availability server software, the fewer moving
> parts the better.

That's one situation where the C++ subset of C + RAII can be an
excellent choice.

> C++ can be too big. You can certainly cherry pick features, but different
> people cherry pick different features. And you also need someone who
> understands _all_ the features to go through and grok those used and unused.

That is why it is important that choice of features is a team decision.
I have assisted a team who's chose to use just RAII and function
overloaded and another who jumped in boots and all with boost. Both
succeeded and both made the best choice for their projects and skill sets.

> Plus, there's linking, interoperability, etc, which is more of a pain. And
> C++'s strict typing can lead to code bloat and/or excessive casting.


I can't say I've seen either and I'm not sure how that could arise.
> There are lots of cool features in C++, but often those features are better
> implemented in other languages. It can be easier to use C + [insert other
> language], then just C++. So, depending on your perspective, C++'s winning
> features can seem middling to someone willing to use more than a single
> language.

Unless like me you happen to be a driver writer!

> I'm guessing that you come from a Windows background and/or graduated
> college in the past 3 or 4 years. That's usually how it goes, IME. C++
> didn't make waves in the Unix world until a few years ago, and then it took
> off with Google and Apple**, especially when they picked up their college
> recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly
> universities which dumped SUN--or never had the history to begin with. Which
> isn't a slight, just an observation about the peculiarities of C++ culture.

It's not my sector, but I know C++ and Motif was very popular in the
banking world back in the 90s. Maybe it still is.

--
Ian Collins

Stuart wrote in reply to James Kuyper:
[snip]
>> I'm intrigued. I have never ever met someone who described himself [James
>> Kuyper, whom I replied to at that time, not William Ahern] as a C
>> programmer. May I ask what kind of business you are in? My guess is your
>> line of work includes either device drivers, embedded devices, kernel code
>> or something else that forces you to write C instead of C++. In all these
>> years I have never met someone who used C instead of C++ unless he was
>> forced to do so.


Am 10/18/12 William Ahern wrote:
> Well, you have now. I've worked in several shops (both small and billion
> dollar companies) which were C only by choice. The consensus was that the
> cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work.
> When you're writing high availability server software, the fewer moving
> parts the better.
>
> C++ can be too big. You can certainly cherry pick features, but different
> people cherry pick different features. And you also need someone who
> understands _all_ the features to go through and grok those used and unused.

In all the shops I have worked so far this choice was always up to me.
To put it more correctly, whenever I felt that the established
programming techniques became insufficient due to the restricted set of
compiler features, I made a presentation that showed how much effort a
particaluar, hitherto unused compiler feature can save. And if you use
the right words, your boss can almost never disagree with you because
any new technique that saves anything must be good!

> Plus, there's linking, interoperability, etc, which is more of a pain. And
> C++'s strict typing can lead to code bloat and/or excessive casting.
>
> There are lots of cool features in C++, but often those features are better
> implemented in other languages.

Do you mind giving an example? I often find that I have the wish to use
another programming language because it has some library that does not
exist under C++ (I haven't found platform independent C++ GUI library
that satisfies my needs, for example), but that should not be an
argument against the programming language itself because one just had to
implement a similar library for C++. There should be nothing inherent to
GUI programming that makes this problem space incompatible with the C++
programming language, I think, although the qt people think that
reflection is a good thing for GUI programming. But that is a story for
another day...

Scripting can also be a good argument against C++. Although there are
efforts to provide C++ scripting environments, this is probably too
difficult a task for the open-source community (and the industry does
not seem to be bothered with such a thing). I have only ever seen BGB
who designed a language called BGBScript that resembles C and can be
either compiled and interpreted, but chances are little that his
language will become main-stream.

> It can be easier to use C + [insert other
> language], then just C++. So, depending on your perspective, C++'s winning
> features can seem middling to someone willing to use more than a single
> language.

Interesting point. However, I always considered the additional friction
that stems from making two programming languages interoperate too much
an effort, so I decided to stick to a programming language that can to
"everything". Maybe that is a wrong thing to do (the last company I
worked at decided to use C++ for the hardware communication layer and C#
for the GUI, but that never really took off).

> I'm guessing that you come from a Windows background and/or graduated
> college in the past 3 or 4 years. That's usually how it goes, IME. C++
> didn't make waves in the Unix world until a few years ago,

That always struck me as odd. After all, C++ was not invented by some
large company that wants to dictate what people should want (as it feels
when I use C# or Java) but by a single guy whom you can chat with in a
newsgroup. Almost grassroots, as one could say.

> and then it took
> off with Google and Apple**, especially when they picked up their college
> recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly
> universities which dumped SUN--or never had the history to begin with. Which
> isn't a slight, just an observation about the peculiarities of C++ culture.

Windows background, true, but not due to university. My hometown
university only offers a undergraduate course that is more or less a
introductory course for languages like Ada, C++ and Java. So one should
not be surprised to meet postdocs in computer science that don

I started to code in C++ ten years ago when I worked during semester
break at Fraunhofer institute. They used Borland's C++ compiler (*
sniff, remembering the good old times *). I had a look at some book that
showed how to write Win32 GUI apps with C and I found it awful. All
those gigantic switch statements, brrr ...
Admittedly, there may be some wrapper libraries for Win32 API that were
written in C, but I couldn't find a suitable one. Apparently C
programmers were supposed to use the Win32 API directly, I guess.

Regards,
Stuart

In comp.lang.c++ William Ahern <> wrote:
> There are lots of cool features in C++, but often those features are better
> implemented in other languages.

That sounds to me like the typical discussion where someone is trying to
define what makes humans different from animals, and each time he says
"humans can do this" someone argues "well, (some obscure species) can do
that too!"

Most of the "better" languages also have drawbacks. The drawbacks might
not always be related to the language itself (although in many cases there
are those too), but about the environment. For example, C# is in principle
better than C++ in many aspects, but trying to use it is quite limiting
because, in practice, you will be restricting yourself to programming
for Windows (or the Xbox 360.)

(Yes, I know that there exist C# implementations for other platforms too,
but they just tend to be way more limited then Microsoft's C#, and a
typical C# program written for Windows will likely not compile for those
other platforms because there's so much Windows-specific stuff in a
typical C# program. Also, there's the issue that C# programs are about
3 times slower than equivalent C++ programs...)

Java excels at portability, and gives a good challenge to C and C++ in
the programming language shootout (and in fact beats C and C++ 100-0
in situations where one just must allocate millions of tiny objects
dynamically and there's no way around it). However, on a more average
level it tends to be slower, more resource-consuming, and always requires
a runtime environment (which makes it unsuitable for some applications).
It also has some annoyances at the language level.

Also, C++ does have some features that are not offered by other languages.
They might offer something that resembles it in a limited manner, but is
not quite as useful. For example, garbage collection is often touted as
a better replacement for RAII, but people who say this do not understand
that RAII is useful for much more than just memory management. Some even
claim that "generics" (they cannot be called "templates" because that's
a curseword) are better than C++ templates, while not seeing how much
more powerful templates are to "generics". The vast majority of languages
out there do not support value-based objects; while this is not always
useful, in many situations it certainly is, as it allows for very
significant speed and memory usage optimizations (which is one of the
reasons why C++ tends to be so fast compared to those, when competently
used.)

> It can be easier to use C + [insert other
> language], then just C++.

Ironically, your typo there actually makes the sentence better.

In comp.lang.c++ Noob <root@127.0.0.1> wrote:
>> However, that's probably not what the OP meant because he explicitly
>> wanted to use an initializer list to initialize the array. Therefore
>> he probably didn't mean to imply that the size of the array is only
>> known at runtime.
>
> Right, except for the fact that he wrote:
>
> "I need to set dynamic values [...] where both the values and the number
> of values are only known at runtime."

Yes, so? I precisely said above that it's probably not what he meant
(because he wanted to use an initializer list.)