C/C++ question about dynamic "static struct"

[Ian Collins]

I simply disagree


for instance?

Almost anything that involves a dynamically sized set of data. One
operation I often have to perform is reading often very large lists of
string, number pairs into an associative array indexed by the string or
a set sorted by the number. Almost one liners in C++.

 

[Dombo]

Op 20-Oct-12 15:45, Nick Keighley schreef:

bizzare definition of "C++ programmer". Many of the people I classify
as "C programmers" *you'd* classify as "C++ programmers"!. Some of
these people were actually using a C++ compiler and sometimes weren't
aware they were using C++ (using true and false for instance); but
nevertheless they were C programmers. To be a C++ programmer I submit
you have to use a significant part of non-C C++.

My experience is that people with a lot of experience with C coding
actually have a disadvantage when trying to become a good C++
programmers. Though the C way of doing things still work with C++
compilers it is far from idiomatic C++.

 

[Dombo]

Op 20-Oct-12 22:09, Ian Collins schreef:

You can do and some embedded code I've worked on does the same in C++. C
simply can't do RAII, so C++ has a built in advantage when it comes to
memory (or any other resource) management. The ability to automatically
manage resources also removes the last excuse to use goto, but that's
another story!


Just compare code using automatic resource management with code that
does it by hand. Pay particular attention to the clean up code if the
nth allocation in a function fails....

....and other alternate/exceptional execution flows.

 

[Fritz Wuehler]

most of what you wrote is agreeable, snipped...

Also, C++ does have some features that are not offered by other languages.

This is hard to believe. Would you be inclined to name a few? I'm not a
C/C++ guy so I'll have to check but I really find it difficult to believe C
or C++ could offer anything that isn't offered by other languages for a few
reasons:

C is not the oldest language, therefore it was based on ideas and languages
that came before. C++ is based on C and other ideas and languages that came
before. There have been many new languages since C++ and many many new ones
since C. Aside from "features" that are really nothing more than quirks or
bad design, are you really suggesting a language written 20 years ago based
on a language written 20 years or so before that has features other
languages don't offer? That would be interesting!

Are you being pedantic and suggesting C++ has features that aren't presented
exactly the same way in other languages, or are you suggesting C++ really
has features that have no equivalents in other languages, or ???

 

[Dombo]

Op 20-Oct-12 22:41, Fritz Wuehler schreef:

most of what you wrote is agreeable, snipped...


This is hard to believe. Would you be inclined to name a few? I'm not a
C/C++ guy so I'll have to check but I really find it difficult to believe C
or C++ could offer anything that isn't offered by other languages for a few
reasons:

C is not the oldest language, therefore it was based on ideas and languages
that came before. C++ is based on C and other ideas and languages that came
before. There have been many new languages since C++ and many many new ones
since C. Aside from "features" that are really nothing more than quirks or
bad design, are you really suggesting a language written 20 years ago based
on a language written 20 years or so before that has features other
languages don't offer? That would be interesting!

Are you being pedantic and suggesting C++ has features that aren't presented
exactly the same way in other languages, or are you suggesting C++ really
has features that have no equivalents in other languages, or ???

I don't know every programing language in existence, but as far as know
there aren't that many programming languages that support RAII
(deterministic destructors) and templates like C++ does.

Also C++ has evolved significantly over the last 20 years. The C++
language I learned C++ 20 years ago is very different from C++ as we
know it today. 20 years ago C++ was little more than C with classes; no
templates, no standard library (or STL), no exceptions...etc.

One cannot consider programming language features in isolation; the
necessity/added-value of a feature and even if possibility of adding a
feature depends on the language as a whole. Reasons that other
programming languages do no support a certain features may be due to
that it doesn't fit in well with other parts of the language (e.g.
deterministic destructors), or that the language designer opted for a
much less powerful but simpler alternative (e.g. generics instead of
templates), or that the language designer doesn't believe that the
feature is a good idea (e.g. operator overloading), or even leave a
feature out entirely because other aspects of the language make the
feature unnecessary (e.g. a dynamically typed language has little use
for templates or generics).

 

[Juha Nieminen]

I simply disagree

You are entitled to. However, do you have an actual *argument* against
what I said, other than "I simply disagree" and "for instance?"

In things like Lisp, Haskell and Scheme, the simplicity of the language
usually translates to the code itself becoming simple and elegant. Often
you can express in a couple of lines what requires dozens of lines in C++
and hundreds of lines in C. And those two lines are not obfuscated beyond
comprehension, but (when you know the language) are clear, simple and
elegant.

There are several reasons for this, but one of the most important ones is
that the language doesn't burden the programmer with things like memory
management.

Many C advocates try to ride on this concept of "simplicity", but what
they are doing is a glaring fallacy of equivocation. They are (perhaps
deliberately) confusing the brevity of the language specification with
the concept of "simplicity" when talking about programming languages.

Just because the language specification is relatively short (and it's
relatively easy to make a compiler for it) doesn't make the language
*simple*. This is a different kind of "simplicity". A kind that does
*not* help the programmer, but on the contrary is a limitation.

 

[Juha Nieminen]

Almost all arguments from "category error" are themselves category
errors. So "mu". I've seen Oxford dons make massive piles of steaming
nonsense out of "category error".

And I have noticed that often when someone doesn't have any *actual*
good arguments, they instead go meta, criticizing someone for the
concepts or terminology they are using, rather than their actual
arguments.

C++ is much *worse* for memory management than is 'C'

Ok, you lost all credibility. I don't think it's necessary to go further.

 

[Les Cargill]

You can do and some embedded code I've worked on does the same in C++. C
simply can't do RAII,

Not in the specific manner Stoustrup used it, but it's
perfectly easy to achieve the same goal. But RAII is
much less a concern when you don't have exceptions... although
I have seen people do things with setjmp()/longjmp() that
were very very clever - including hooking hardware exceptions and
hitting longjmp() with it.

so C++ has a built in advantage when it comes to
memory (or any other resource) management. The ability to automatically
manage resources also removes the last excuse to use goto, but that's
another story!


Just compare code using automatic resource management with code that
does it by hand. Pay particular attention to the clean up code if the
nth allocation in a function fails....

Sorry, this really doesn't apply to any cases I've seen in a long
time that were not GUI programs - and I believe I stipulated to
"use something besides C++ for GUIs, please" upthread.

'Course, I'm the sort who would use a state machine to manage an
overly onerous memory allocation problem - and in C++ - so...

 

[Juha Nieminen]

I've seen C++ used to create complex solutions to simple problems.

And I have seen C++ used to create simple solutions to complex problems.
So what?

Just because a language *can* be used in a very sub-optimal manner, does
that mean the language is bad? C can certainly be used in a horribly
sub-optimal manner. Any language can.

The argument that there exist incompetent programmers is quite silly.

 

[Juha Nieminen]

Or you get an old version of STL that's buggy and there's an observed
problem that takes up to a *year* ( off and on - not continuous
pushing ) to resolve.

When C programmers have to resort to problems that might have been
relevant 20 years ago in order to make their case, I think that
demonstrates quite well that they don't have any *actual* argument.

Also, I once had a ... data structure that I built with a need
for associativity ( think arrays indexed by strings ) where it
was twice the code* and half the performance to use STL than
bash something out in 'C'. Oh, if STL had only had "foreach"
from the start....

"The standard library cannot be used for this", is a rather weak
argument for why the standard library is not useful. The standard
library does not offer *everything*. So what? What it does offer
is in practice very useful.

 

[Les Cargill]

You are entitled to. However, do you have an actual *argument* against
what I said, other than "I simply disagree" and "for instance?"

In things like Lisp, Haskell and Scheme, the simplicity of the language
usually translates to the code itself becoming simple and elegant. Often
you can express in a couple of lines what requires dozens of lines in C++
and hundreds of lines in C. And those two lines are not obfuscated beyond
comprehension, but (when you know the language) are clear, simple and
elegant.

There are several reasons for this, but one of the most important ones is
that the language doesn't burden the programmer with things like memory
management.

Many C advocates try to ride on this concept of "simplicity", but what
they are doing is a glaring fallacy of equivocation. They are (perhaps
deliberately) confusing the brevity of the language specification with
the concept of "simplicity" when talking about programming languages.

No, I think the "simplicity" of 'C' is more akin to exploiting
the representation of data itself. Knowing how stuff is laid out
in memory offers some measure of relief from some of the bureaucracy
of some systems.

Granted, Scheme/Lisp et al will always be more elegant because
functional notation always is.

There are times to build perfect Pythagorean castles in the air,
and there are times to solder wires to things. The trick is knowing
when.

Just because the language specification is relatively short (and it's
relatively easy to make a compiler for it) doesn't make the language
*simple*. This is a different kind of "simplicity". A kind that does
*not* help the programmer, but on the contrary is a limitation.

So they tell us. So they tell us.

 

[Juha Nieminen]

This is hard to believe. Would you be inclined to name a few?

By "other languages" I was referring to the ones popularly used.

For example RAII *is* offered by some other languages (eg. if I remember
correctly ADA might have had it), but those tend to be either obscure
languages that nobody uses, or have fallen almost completely out of usage
in practice (except in very narrow and specific industries, eg. with ADA.)

(And no, this was not an argument on whether RAII is better than automatic
GC. That was not the point.)

It's hard to classify if any language offers the same functionality as
C++ templates do (regardless of what you think about their syntax; I'm
talking purely about the functionality here.) There are certainly some
languages (especially some functional ones) which you might argue offer
the same functionality, although using a rather different approach. But
even then there often are radical differences.

 

[Juha Nieminen]

I can see the appeal. I know pretty much all of C. I only know a large
percentage of C++. I haven't got round to the new C++ standard. I
don't know every little corner of the standard library and I certainly
don't know boost! Do you write exception safe code?

That last question is really odd at the end of the paragraph that's
otherwise talking about something else entirely. Care to explain?

 

[Juha Nieminen]

No, I think the "simplicity" of 'C' is more akin to exploiting
the representation of data itself. Knowing how stuff is laid out
in memory offers some measure of relief from some of the bureaucracy
of some systems.

Having the know the exact layout of the data used in the program is a
really niche use case. Hardly something relevant to the average program.

Regardless, since we are comparing C to C++, and the argument is that
C is "simpler" (and therefore many people prefer to use it), what makes
to you think that it's not possible (or even harder) to know the exact
memory layout of the data in a C++ program?

If, for example, you need for some reason to define a struct in some
precise manner, there's nothing in C++ stopping you from doing that.
There's nothing that C can offer in this regard that's not possible
in C++.

(And before you argue "well, if you are restricting your C++ program
to what C already does, why use C++ at all?" the answer is: To make
the *rest* of the program, ie. the parts that do *not* need that kind
of low-level tinkering, much easier.)

 

[Juha Nieminen]

Not at all. It can be used anywhere a resource has to be managed. It
avoids the goto spaghetti often seen in C code to handle an allocation
failure in a block of allocations.

I have seen the exception-safety argument (ie. "RAII is mostly useful to
make code exception-safe, but without support for exceptions they are
not all that useful") quite many times, and I have always wondered where
it comes from.

RAII is most certainly very useful even if you didn't have exceptions.
It makes code much safer and simpler at the same time. The more complicated
the interactions between different modules and data containers, the more
that stuff is passed around, the more useful RAII becomes in order to keep
the program simple and safe.

 

[Les Cargill]

And I have noticed that often when someone doesn't have any *actual*
good arguments, they instead go meta, criticizing someone for the
concepts or terminology they are using, rather than their actual
arguments.

Yeah, that was a bit snarkier than it perhaps should have been.

I don't think the invocation of category errors in this sort of
discussion is likely to be productive. Different languages live in
semi-orthogonal domains, so there tends not to be a lot of
synergy. Good language systems allow for interfacing to
other language systems with a minimum of fuss.

Ok, you lost all credibility. I don't think it's necessary to go further.

I've built significant, non-embedded, production systems using only
'C' that used no dynamic allocation at all. It doesn't get any less
worse than that. It wasn't difficult. You can do that in C++ too, but
it's a lot less ... sensible.

It is possible that there is a bias error I missed, but memory leaks
were much less a problem when the state of the art was 'C', at
least within the things I saw. As a *cultural* artifact, C++
made things worse for a while. This being said, newer
languages are beginning to improve on that significantly.

it well could be that 'C' simply kept otherwise sensible people
from *doing* programming through barrier to entry. Ironic,
since it was shrinkwrap 'C' compilers that helped popularize it...

I have never understood why managing memory allocation manually was
considered to be so onerous. Perhaps it's a personal failing. And
limitation can be extremely important to the general creative process.

I suppose my main gripe about C++ is just how much harder it made it
to dynamically configure a running system. If all the cardinalities and
sizes have to be declared at instantiation of all the objects, you
have then to tear them all down and rebuild them when a message to
reconfigure comes through. This can be a serious liability.

 

[Ian Collins]

I've built significant, non-embedded, production systems using only
'C' that used no dynamic allocation at all. It doesn't get any less
worse than that. It wasn't difficult. You can do that in C++ too, but
it's a lot less ... sensible.

Why? It's not uncommon to have static embedded C++ applications.

I have never understood why managing memory allocation manually was
considered to be so onerous. Perhaps it's a personal failing. And
limitation can be extremely important to the general creative process.

It is also the cause of an awful lot of bugs....

I suppose my main gripe about C++ is just how much harder it made it
to dynamically configure a running system. If all the cardinalities and
sizes have to be declared at instantiation of all the objects, you
have then to tear them all down and rebuild them when a message to
reconfigure comes through. This can be a serious liability.

The difference to C here is?

 

[Rui Maciel]

I've seen C++ used to create complex solutions to simple problems. My
favorite example is use of the Singleton pattern to produce code with
precisely the same potential dangers as would occur if a global variable
was used, and much greater complexity. Because of course, global
variables are "evil", and use of a named "pattern" is "good".

I don't understand what you meant by that. The singleton design pattern and
global variables are two entirely different things. It is not uncommon o
declare singletons as global objects, and you cannot guarantee that an
object type has a single object declared throughout the entire project just
by declaring it a global object.


Rui Maciel

 

[Rui Maciel]

Almost all arguments from "category error" are themselves category
errors. So "mu". I've seen Oxford dons make massive piles of steaming
nonsense out of "category error".


No, the thing about lisp is that it is *interpretive*.


C++ is much *worse* for memory management than is 'C' - in that
the possibility of memory leaks goes up. Absent writing GUI code,
it's entirely possible to write entire deployable systems that use no
dynamic memory at all in 'C'. indeed, that's been the shop
standard most places I have worked.

That assertion is questionable, if not completely nonsense. After all, with
C++ it is quite possible to write code without a single explicit call to
new/delete, but it won't be simple to write equivalent C code without a
single call to malloc/free. And that's without even considering RAII.

To my eye, the solutions there are uglier, and a choice like Tcl
or Python makes C++ less interesting. Because interpreters provide
a much better suite of "furniture".

You are free to implement any solution which is, to your eye, prettier. The
main point is that with C++ you already have a set of standard solutions at
your disposal, which were already extensively tested and debugged.

Just... wow. It's a *huge* problem. I'm not "into languages"
to be into languages, I am into them to be able to operate on teams
that produce deployable systems that work without causing anybody
any problems.

A novice can really get 95% of everything they need to know
about 'C' in a matter of months, while being productive
under supervision.

The problem with that assertion is that you are misrepresenting C and C++.
While with C you are referring to essentially being exposed to the core
language, as C's standard library is pretty limited, with C++ you are
including everything plus the kitchen sink. Meanwhile, you failed to take
into account that C++ can be presented as an improper superset of C, which
means that if you are able to get a newbie to know 95% of everything they
need to know about C to be productive in a matter of months, then you can
also achieve the exact same thing with C++. Sure, some features won't be
covered, but you don't need to use every bell and whistle provided by C++ to
actually be productive.

I am not sure there is a collection
of ten people on the planet who , between them , know everything
there is to know about C++.

That is completely irrelevant. Who said you had to use every trick in the
book to be able to do anything with C++? It's quite possible to develop
software with C++ while completely avoiding any number of features.



Rui Maciel

 

[Rui Maciel]

And I have seen C++ used to create simple solutions to complex problems.
So what?

Just because a language *can* be used in a very sub-optimal manner, does
that mean the language is bad? C can certainly be used in a horribly
sub-optimal manner. Any language can.

The argument that there exist incompetent programmers is quite silly.

In addition, in some cases the incompetence lies in the people reading the
code and criticizing it for some reason. Design patterns sometimes appear
to be needlessly complicated solutions to simple problems because the people
reading the code don't understand what the real problems are and therefore
are not in a position to understand what represents an adequate solution.

More specifically, design patterns tend to be used to write code that may
sacrifice the appearance of simplicity with simplicity with regards to other
criteria, such as refactoring and extending. Take, for example, the visitor
pattern. It may appear completely nonsensical to essentially implement
member functions in separate classes. If someone who is clueless looks at
an implementation of a visitor pattern then they may criticize it for being
a complex solution to a simple problem, because if someone needs to
implement a new member function then all a person should do is implement a
new member function. Yet, the visitor pattern provides a way to add a new
operation to a class without having to modify the class itself, along with a
few other significant advantages such as handling these operations as
operators. To someone with a C backround, where functions are completely
decoupled from objects, this advantage might not be exactly obvious, but
just because someone isn't able to understand its purpose it doesn't mean it
is needlessly complex; it just means that they faile to see the point.


Rui Maciel