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

[BartC]

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.

I develop dynamic languages for my own use. Unusually, these have always had
a struct or 'record' data type, with the ability if necessary to precisely
define the type and offsets of the elements (even more than C has!), as well
as having just a bunch of dynamic elements when you don't care about how
they are stored.

And I use such structs all the time. Sometimes because it's necessary to
interface with something with a specific layout; sometimes just for the
pleasure of crafting a perfectly laid out, compact record type with no space
wasted (with bonus points if it fits into a power-of-two size).

I don't think it's a niche thing at all. If you rarely use it, then perhaps
you have less need for a language like C anyway.

 

[Rui Maciel]

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.

Just because you were able to use a language without allocating any memory,
it doesn't mean that some other language is suddenly plagued with memory
allocation problems. Your argument becomes even sillier when considering
that you are referring to a language which is an improper superset of the
language you used to pull that stunt, which means that you can also pull
that off with the language you tried to criticize.

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.

Again, that is a silly thing to say. Programmers cause memory leaks, not
the language. In addition, with C++'s RAII it is considerably easier to
take care of any memory allocation issue, while with C it is necessary to
explicitly track every allocation/deallocation to be able to avoid memory
leaks.

As a *cultural* artifact, C++
made things worse for a while.

Obviously, it hasn't. You may argue that programmers using the language may
have misused it, but blaming the tools while leaving out the workman is a
silly thing to do.

I suppose my main gripe about C++ is just how much harder it made it
to dynamically configure a running system.

You can't blame a language for any hypothetical problem caused by the way a
system was designed.


Rui Maciel

 

[James Kuyper]

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.

Why? They do exist, and appear to have generated a large fraction of all
of the code that gets written.
In any event, your summary of my argument dropped the key point - that
the greater complexity of C++ provides more temptations for incompetent
programmers to generate overly complex code than C does. Of course, that
doesn't prevent them from producing bad C code, but the bad C++ code
that I've seen has been much more complex to untangle than the bad C
code I've fixed.

 

[Öö Tiib]

Why? They do exist, and appear to have generated a large fraction of all
of the code that gets written.

Incompetent programmers tend to produce negative results. Fixing their work
would take more hours of competent programmers than undoing and rewriting it
from scratch; it is "negative result". Same happens in C, C++, Java or PHP. So
the argument *is* silly. Competent specialists of C are no way happier about
incompetent programmers in their team than others.

In any event, your summary of my argument dropped the key point - that
the greater complexity of C++ provides more temptations for incompetent
programmers to generate overly complex code than C does. Of course, that
doesn't prevent them from producing bad C code, but the bad C++ code
that I've seen has been much more complex to untangle than the bad C
code I've fixed.

If you take incompetent into team then that is future investment anyway. You
knowingly invest competent specialists time now in hope that after some months
he will gain competence and produce positive results.

The creater amount of features in C++ indeed gives more ways to do things
inefficiently and uglily but it also does provide more ways to do it simply,
efficiently and elegantly. C++ has more ways to separate modules. Not at
language level as yet but by availability of various open source C++ libraries.
Team of competent C++ programmers is therefore better armed to cooperate with
incompetent person, incompetent subcontractor or module provider.

If to come back to your initial global state versus global singleton argument
then competent have neither available. Incompetent can not therefore come and
screw someting up globally by messing up that global state.

 

[Les Cargill]

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.

Where is that median/average program, anyway? For those, I use
interpreters - Tcl and sometimes Python.

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++.

It's not "possible" so much as it is "likely". Don't get me wrong;
*yesterday*, I was working on about the third iteration of some C++
wrappers for very popular 'C' libraries. Very nice; makes the actual
invoking solution much more elegant. Two of them were
nothing more than a constructor and destructor apiece. One had exactly
one more method than that. Turns 50 lines of 'C' into one line;
a very easy-to-see improvement.

(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.)

You're kind of begging the question a bit. If all the services are
thoroughly bug free and never fail, then it's great. To badly
paraphrase Voltaire, "hell is other people's code*." The more of
it there is, the more bugs there are.

*and we are them other people, too.

There are all kinds of hubris we have to watch out for. Maintaining
a balance is a constant struggle.

 

[Les Cargill]

I'm sorry, but it isn't. RAII is one C++ feature that C can't do.

I respectfully submit that you haven't thought
that though. I won't bore you with the sea stories...
but it's been done...

What Stoustroup provided was an artifact that created a culture
that tried to solve these problems. He did a great job.

Not at all.

Ah! You're avoiding my carefully chosen weasel - "much less than".

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.

People were successfully avoiding that spaghetti decades ago
with much less powerful tools.

So write a state machine, with one allocation per state and do
*absolutely nothing else* until it terminates. It's the software
equivalent of "get the money up front." If you have
additional allocations later, just add states. Push successful states on
a stack, and unwind on failure. Bada boom, bada bing.

for extra credit, have the allocation requester extend the state
machine in an abstract way. Use the __FILE__ and __LINE__ macros
also in this stack, and write a dump routine. Presto! Asymptotically
full memory leak disclosure.

And then, to be a total creep, use a 'C' macro
to substitute your scheme for malloc()/free()....

I'd allocate the stack thingy very, very statically....

"But I don't want to write a state machine!" Well,
you're not all that concerned about managing complexity
then, are you?

And I want a pony, too.

I mean absolutely no offense, but comments like yours sound like
learned helplessness to me. Break those chains! Take control
of your destiny! Power to the proletariat!

Strike that last one. But really, the project I first
did that on was out of control and this helped stabilize things
*immensely*. Operation without instrumentation is like using
a credit card without reading the billing statements.

You obviously haven't looked at kernel and library code!

Heh. The One True Kernel, and Linus is its prophet?

Oh, I have. it's *a* way. May you never hear the words "We
want you to write a patch against the bridge code..." It's
good code, but very branchey - you end up following lots of chains.
*Generally*, that sort of activity is unnecessary.

 

[Les Cargill]

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.

Not *really*. See also ctors/dtors.

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.

C++ represents a middle ground, a suite of compromises. What I find
is that when you really do need a dynamic language, interpreters
generally create less rash than compiled languages. When you
don't need a lot of dynamic behavior, something like 'C' seems
to fit better.

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,

A questionable argument at best... can't describe the weariness
caused by having to trot "sprintf()" out in the middle
of a large C++ project...

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++.

That's not consistent with direct observation, I fear.

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.

That doesn't keep people from going to every bell and whistle
because they can, and dragging others into the muck with them

That is completely irrelevant.

Whu? Really? Okay then.

 

[Tobias Müller]

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.

Not if you have to work with existing code or in a team. And who does not?

Tobi

 

[Les Cargill]

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.

This was much, much more recent than that. People are
*still running* 20 year old STL implementations...

"So why don't you upgrade?" My very question. The answer
was interesting.

"The standard library cannot be used for this", is a rather weak
argument for why the standard library is not useful.

It's an explicit demonstration of the *dis*utility of it. Dunno
about you, but I don't get to point to that and say "abandon
hope", I have to go fix it.

The standard
library does not offer *everything*. So what? What it does offer
is in practice very useful.

It *can* be. What we're arguing about is whether or not
language features enable bad practice, and that's not
going to be settled in one thread.

 

[Jorgen Grahn]

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.

I've worked in those places too. Unlike you I believe they are
misguided, but I agree they exist and aren't unusual.

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.

I get the feeling (which may be incorrect) that you justify discarding
C++ by trying to associate it with Microsoft, and anti-Unix nonsense
in general. Since I'm pro-Unix myself that annoys me.

There are /different/ C++ cultures, just like there are different C
cultures. For me C++ fits very well into Unix programming[1]. It's
just like Unix programming in C, only with better tools such as the
standard containers, RAII and so on. I don't know what they do in the
Windows world ... seems to be most have spent many years down the
Java/.NET route until very recently.

/Jorgen

[1] One perhaps surprising reason is the Unix APIs are C API. That way
I'm not tied to someone's antiquated ideas about how an
object-oriented interface should work. Sure, C APIs can feel
primitive at times -- but at least a decent number of people know
how do design them properly!

 

[Ian Collins]

I respectfully submit that you haven't thought
that though. I won't bore you with the sea stories...
but it's been done...

I certainly have thought it through. Please provide an example of RAII
in C.

 

[Ian Collins]

Not *really*. See also ctors/dtors.

What have they got to do with C++ being worse than C for memory
management? Come on, no more sideshows, provide a real example.

 

[Ian Collins]

Not if you have to work with existing code or in a team. And who does not?

If you work in a team on a new project, the team agrees which features
to use. If you work on existing code, you get a free education...

 

[Tobias Müller]

If you work in a team on a new project, the team agrees which features to use.

But as a C++ programmer I would never agree on using only the C subset of
C++.
The complexity of C++ makes it more difficult to agree on a common subset
of features, because the level of knowledge may vary more.

If you work on existing code, you get a free education...

And it raises the possibility to make things even worse because you're not
understanding what you're reading.

Tobi

 

[Greg Martin]

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.

I've worked in those places too. Unlike you I believe they are
misguided, but I agree they exist and aren't unusual.

What seems to be the real irony here is that it isn't 1992, though I'm
getting a decided deja vu, but 2012 when this conversation should be
taking place between C++ zealots and C# adherents (or maybe Java,
Python, Ruby, erlang programmers et al).

I have worked on large scale projects in both C++ and C and prefer C
however misguided you may feel that makes me. On the other hand there
are projects for which I prefer to use other languages. C++ isn't on my
goto list, pun intended.

Horse for courses I guess. I'm quite fond of erlang for instance though
I don't believe you should learn it as I'm sure you can accomplish what
you need to do in C++, however, there are a whole lot of things it does
very well and with a fraction of the effort required by C++. Still, I
don't suppose the sky will fall in on comp.lang.c++ any more then it has
on comp.lang.c.

 

[Öö Tiib]

But as a C++ programmer I would never agree on using only the C subset of
C++.
The complexity of C++ makes it more difficult to agree on a common subset
of features, because the level of knowledge may vary more.

Lets look on meta-information that novice has to study to participate in team?
C++ coding standard is relatively long document. Everything else however
is several times as long and as crucial. How to set up working environment,what tools and frameworks and exactly what versions are used, where and how to put unit tests, how to use repositories, how to Doxygen-document the work, how
to use review boards and what and how to tell or not to tell in issue
trackers etc. IOW defining the development process is lot more complex problem
than specifying subset of C++ language used.

That information is what a team has to agree up for new project too.
Lot of it is just loaned with small adjustments from other projects where
team members previously participated. The small fraction about what they
disagree they just vote on and done.

And it raises the possibility to make things even worse because you're not
understanding what you're reading.

Modern software development can not be overly simple. What difference it
does make if there is 200 000 lines of C code or 100 000 lines of C++ code?
It takes time to learn it. Same is with that little pile of wiki pages and
other documentation. Did not understand? Then your submission will not pass
the review and on worst case it will be removed from repository.

 

[Ian Collins]

But as a C++ programmer I would never agree on using only the C subset of
C++.

You shouldn't have to.

The complexity of C++ makes it more difficult to agree on a common subset
of features, because the level of knowledge may vary more.

That is why a new team should discuss and agree which aspects of the
language they will use before starting a project. If the team is are
new to C++, they should get some outside help early on. One team I
managed made the call after they had completed a training course,
another after we discussed the benefits of various features to their
project.

 

[Les Cargill]

I certainly have thought it through. Please provide an example of RAII
in C.

So we're talking RAII as modulo exceptions - unless longjmp() is alos an
exception...

So you *haven't* thought about it, then? It's not exactly rocket
surgery. I am just enumerating my assumptions in responding to your
post, not *accusing* you of anything.

Essentially replace malloc()/free() with something that tracks
allocation and provides instrumentation about the state of the heap.
This is much simpler than it sounds...

Given all the rash about it, I am surprised 'C' doesn't offer this
natively, and that there were never commercial products of the same
stripe.

There's this:
http://www.duckware.com/bugfreec/chapter5.html

Very slanted towards some variant of Windows style, but
it should give you the general idea.

 

[Öö Tiib]

There's this:
http://www.duckware.com/bugfreec/chapter5.html

That is not RAII idiom. That is plan for safer memory manager. RAII is
actually very simple.

RAII means that all resources allocated are always bound to objects that own
them. Either the object frees the resource (with explicit code) during its
duration, transfers the ownership of resource (with explicit code) to some
other object with some other duration or it frees it (automatically, no code)
at end of its own duration. So no resource can leak (no memory, network socket
or file handle).

RAII works on fact that in C++ certain code (a destructor) is ran automatically
when object's duration ends. This is not case with C and so can not be
done with C.

 

[Rui Maciel]

Not if you have to work with existing code or in a team. And who does not?

If you work as a team and the team is told not to use feature X or Y, you,
as a member of the team, don't use feature X or Y. At least at work. That
was precisely my point.


Rui Maciel