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

[Rui Maciel]

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

The point I made with the reference to C++'s C subset was that:
- If C is considered good for memory management, then C++, as it includes a
subset of C, is also good for memory management when limited to that subset.
- If we add the remaining C++ features to C++'s C subset, the C++
programming language doesn't become worse for memory management. It
actually improves significantly, considering the addition of RAII.

Therefore, C++ is patently not worse than C with regards to memory
management.

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

It isn't that complex as you make it out to be. I know of a company in the
telecom industry which explicitly banned the use of exceptions and the STL
in one of their C++ projects, the later in favour of a set of custom memory
pools. That policy was in the project's coding guidelines, and everyone who
was added to the project was briefed about what was kosher and what was
taboo. There was nothing difficult about that.

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

You won't be reading idioms which were explicitly banned from a project.


Rui Maciel

 

[Rui Maciel]

Not *really*. See also ctors/dtors.

I don't understand what you were trying to say. Are you saying that the use
of constructors and destructors forces someone to explicitly call
new/delete?

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

Your direct observations lead you to believe that it is impossible to write
C++ code which is also C?

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

That's not the programming language's fault.

Whu? Really? Okay then.

Yes, really. There is no magical proficiency barrier nor any legal
impediment that bars programmers from developing applications if their
expertise level is below a certain level. As it's the case with any
technical field, excellent is nice to have, good is great, but good enough
is nevertheless good.


Rui Maciel

 

[Tobias Müller]

The point I made with the reference to C++'s C subset was that:
- If C is considered good for memory management, then C++, as it includes a
subset of C, is also good for memory management when limited to that subset.
- If we add the remaining C++ features to C++'s C subset, the C++
programming language doesn't become worse for memory management. It
actually improves significantly, considering the addition of RAII.

Therefore, C++ is patently not worse than C with regards to memory
management.

I was actually referring to the following (sorry for the bad quoting):

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

It isn't that complex as you make it out to be. I know of a company in the
telecom industry which explicitly banned the use of exceptions and the STL
in one of their C++ projects, the later in favour of a set of custom memory
pools. That policy was in the project's coding guidelines, and everyone who
was added to the project was briefed about what was kosher and what was
taboo. There was nothing difficult about that.

We do something similar at work. I can live with it, but I still think we
would do better if we would just use what's already there.

If I could, I would use every single feature of C++ in my code, but I can
also see the downside of that

Tobi

 

[Juha Nieminen]

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

You are confusing RAII with gargabe collection.

RAII is not the same thing as GC, and RAII is useful for a lot of other
things besides memory management.

Besides, what you are talking about above is *not* something that the
standard C programming language offers, so you can hardly argue that C
offers RAII.

 

[Juha Nieminen]

When you
don't need a lot of dynamic behavior, something like 'C' seems
to fit better.

There seems to be a really common misconception among many C advocates
that the only thing that the additional features offered by C++ are good
for is for managing dynamically allocated memory. This couldn't be farther
from the truth.

RAII is useful for things other than managing memory. For example, it can
be used to more easily close file handles and release mutex locks, making
the code simpler, safer and less error-prone, requiring less coding
conventions that exist solely to avoid those errors.

The very support for classes is in itself a big advantage over the raw
structs of C, even if you don't make any dynamic memory allocation at all.
It makes it easier to design your program modularly, to have compile-time
checks, and to make syntax simpler. Inheritance can also be useful even
when you don't need dynamic memory allocation.

Templates are a big one. Not only do they make many things simpler, they
can also make them more efficient. (For example, just compare the speed
of std::sort() compared to qsort(). The speed advantage of the former
comes thanks to the fact that it's a template function. Also, the former
is much easier to use than the latter.) And that's only scratching the
surface.

 

[Juha Nieminen]

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.

My experience makes me disagree with the the last part. I would say that
the limiting "simplicity" of C causes many incompetent programmers to
create horrible code (much of which is caused *because* C is so archaic.)

Many C advocates argue that the "simplicity" of the language somehow
induces people to make straightforward, clear, simple and efficient
implementations. That's not what I see at all. Instead, what I see
quite often is really complicated code with tons of implied coding
conventions (that exist solely to address things like memory management
issues), and which is quite frankly horribly designed. Just take almost
any C project out there and study its source code. You'll easily find
400+ LOC functions (with little to no comments), that use lots of
repetition and/or are really obfuscated, oftentimes riddled with gotos,
and so on and so forth. They often also suffer from inefficiency because
the programmer did a "straightforward" job at implementing the task at
hand.

I'm not saying that *every* C program out there is like that. I'm saying
that quite a significant portion of them are. There's nothing in C that
would somehow induce or encourage people to make good code.

 

[Juha Nieminen]

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

And this affects me how, exactly? Why should *I* care? Why should I choose
C over C++ if some people are still running 20 year old STL implementations?

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.

I don't understand that at all. Since the standard library does not
offer a solution for every single problem in existence, it's not
useful? That's like one of the craziest arguments I have ever heard,
even from a C advocate (and that's saying quite a lot; believe me,
I have seen quite crazy stuff.)

 

[ptyxs]

Le 21/10/2012 19:54, Les Cargill a écrit :
To badly

paraphrase Voltaire, "hell is other people's code*." The more of
it there is, the more bugs there are.

You probably meant 'to paraphrase Jean-Paul Sartre'...
Voltaire has nothing to do with that sentence...
Ptyxs

 

[James Kuyper]

My experience makes me disagree with the the last part. I would say that
the limiting "simplicity" of C causes many incompetent programmers to
create horrible code (much of which is caused *because* C is so archaic.

I've seen incompetent C programmers produce horrible code, and I've seen
incompetent C++ programmers produce horrible code; except for the
comments I've already made about the matter (see below), I haven't
notice much difference between the two different types of horribleness.

From my previous message:
So our experiences have been quit different. There's not much more
useful that can be said about that.

 

[Les Cargill]

You are confusing RAII with gargabe collection.

It's not actually garbage collection, either...

RAII is not the same thing as GC, and RAII is useful for a lot of other
things besides memory management.

Besides, what you are talking about above is *not* something that the
standard C programming language offers, so you can hardly argue that C
offers RAII.

Fair enough; I'm not sure what you were driving at then. It's fully
possible for 'C' programs to leave no widowed
resources, memory or otherwise. It's not even that difficult.

 

[Jorgen Grahn]

The point I made with the reference to C++'s C subset was that:
- If C is considered good for memory management, then C++, as it includes a
subset of C, is also good for memory management when limited to that subset.
- If we add the remaining C++ features to C++'s C subset, the C++
programming language doesn't become worse for memory management. It
actually improves significantly, considering the addition of RAII.

Therefore, C++ is patently not worse than C with regards to memory
management.


It isn't that complex as you make it out to be. I know of a company in the
telecom industry which explicitly banned the use of exceptions and the STL
in one of their C++ projects, the later in favour of a set of custom memory
pools. That policy was in the project's coding guidelines, and everyone who
was added to the project was briefed about what was kosher and what was
taboo. There was nothing difficult about that.

Well ... I think I might prefer using C to working in C++ without the
standard library. Unless its replacement was *really* good and
included drop-in replacements for things like iterators and algorithms.
And containers.

Weird guidelines aside, I have to partly agree with T.M. above -- it
/is/ harder to agree about C++. One guy wants it to be C, another
wants it to be Smalltalk, a third wants it to be 1980s C++, I want it
to be modern C++ ...

It's worth the effort, though.

What's so bad about not understanding everything? You go to the guy
who wrote it and ask him to explain. If he can't, you might want to
rewrite it. Not any different from not immediately understanding other
things in the project, like an interface, an algorithm, or a
requirement.

You won't be reading idioms which were explicitly banned from a project.

And you won't be reading many things which were not. I've never seen
multiple inheritance -- not because it has been banned, but because
it's so rarely useful! I've never seen deep template meta-
programming, because I don't work with people who are into that stuff.
And so on.

/Jorgen

 

[Öö Tiib]

Well ... I think I might prefer using C to working in C++ without the
standard library. Unless its replacement was *really* good and
included drop-in replacements for things like iterators and algorithms.
And containers.

You should try QT then. That framework really has choosen to have everything
of its own. Only thing that I do not see as very reasonable is that QString
is internally UTF-16 not UTF-8. Perhaps it is because Symbian and Windows (favorite OSs of Nokia) also favor UTF-16. Rest of it is quite well made and
also the development tools are quite nice.

Weird guidelines aside, I have to partly agree with T.M. above -- it
/is/ harder to agree about C++. One guy wants it to be C, another
wants it to be Smalltalk, a third wants it to be 1980s C++, I want it
to be modern C++ ...

It's worth the effort, though.

That is anyway difficult but must be done when specialists of so very
different background have to coooperate. Usually there should be one
lead developer - architect type per team and others should be supporting
and assisting members. Several disagreeing leaders has disasterous result
independent of goal and tools.

And you won't be reading many things which were not. I've never seen
multiple inheritance -- not because it has been banned, but because
it's so rarely useful! I've never seen deep template meta-
programming, because I don't work with people who are into that stuff.
And so on.

Every week I find something that i have never seen before. Past week example:

class Power
{
private:
// construct with factory methods
Power( std::string const& typeCode );
public:
// factory method
static Power fromValueAndUnitText( std::string const& text )
{
if ( text.size() < 2 )
{
// both value and unit can't fit
return false; //<--- i was here like WTF WTF WTF
}
// ...
// etc.
}
// ...
// etc.
};

Compiled without any warnings. I did not even know before that 'false'
converts so silently to 'std::string const&' on the compiler used in
that project.

 

[Stuart]

On 10/23/12 Öö Tiib wrote:
[snip]

Every week I find something that i have never seen before. Past week example:

class Power
{
private:
// construct with factory methods
Power( std::string const& typeCode );
public:
// factory method
static Power fromValueAndUnitText( std::string const& text )
{
if ( text.size() < 2 )
{
// both value and unit can't fit
return false; //<--- i was here like WTF WTF WTF
}
// ...
// etc.
}
// ...
// etc.
};

Compiled without any warnings. I did not even know before that 'false'
converts so silently to 'std::string const&' on the compiler used in
that project.

That's what I hate about C++, too. My favourite programming language,
Ada, would never allow such a thing to happen. It's a pity that implicit
conversions cannot be turned off using a pragma/compiler switch.

Regards,
Stuart

 

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

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 don't quite get your point here. It's obviously not "C should have
died some time after 1992".

(For what it's worth, if I had a time machine I'd go back to 1992 and
tell people to stay off C++ for a few more years until the standard
library was in place, and templates widely understood. I have a
feeling many bad practices and much bad reputation came in that time
frame.)

I have worked on large scale projects in both C++ and C and prefer C
however misguided you may feel that makes me. ....
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++

I just stated that I prefer C++ to C, not that C++ is better than all
other languages at everything!

/Jorgen

 

[Jorgen Grahn]

On 10/23/12 Öö Tiib wrote:
[snip]

Every week I find something that i have never seen before. Past
week example:

class Power
{
private:
// construct with factory methods
Power( std::string const& typeCode );
public:
// factory method
static Power fromValueAndUnitText( std::string const& text )
{
if ( text.size() < 2 )
{
// both value and unit can't fit
return false; //<--- i was here like WTF WTF WTF
}
// ...
// etc.
}
// ...
// etc.
};

Compiled without any warnings. I did not even know before that 'false'
converts so silently to 'std::string const&' on the compiler used in
that project.

Ugh. And I can't even get gcc to warn about it, when I apply all my
favorite warning options. I didn't expect that!

That's what I hate about C++, too. My favourite programming language,
Ada, would never allow such a thing to happen. It's a pity that implicit
conversions cannot be turned off using a pragma/compiler switch.

It's not something you come across very often. Or at least I don't ...
In this case the first error is not to make Power:ower(const string&)
'explicit' -- so the "conversion" is a two step one.

I wouldn't mind a flag to warn about non-'explicit' constructors, and
like others have pointed out in the past, it would have been better if
the keyword had been 'implicit' instead and done the reverse job.

/Jorgen

 

[Dombo]

Op 23-Oct-12 17:44, Jorgen Grahn schreef:

I don't quite get your point here. It's obviously not "C should have
died some time after 1992".

(For what it's worth, if I had a time machine I'd go back to 1992 and
tell people to stay off C++ for a few more years until the standard
library was in place, and templates widely understood. I have a
feeling many bad practices and much bad reputation came in that time
frame.)

It would probably also have prevented many C++ libraries from
implementing their own string and container classes. This is one thing I
dislike about C++.

 

[google]

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

So provide an example in standard C. It looks like all your piss and wind
is an attempt to cover up the fact that you can't.

RAII can be used in the context of any resource (hence its name!), not just
memory.

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.

Which was my original point, thank you.

 

[Stuart]

On 23-Oct-12 Jorgen Grahn wrote:
[snip]

It would probably also have prevented many C++ libraries from
implementing their own string and container classes. This is one thing I
dislike about C++.

+1.

I took an immediate dislike to qt because it seemed as if they had to
reinvent the wheel not only once but many times. Later I realized that
they wanted to have a copy-on-write semantics for their strings, which
could not be achieved with std::string at that time.

Now that std::string supports copy-on-write, too, noone on the qt team
seems inclined to remove the superfluous qtString class.

Even Microsoft still uses CObject as base class for all classes of their
MFC library, even though the whole purpose of this class was to provide
run-time type information.

I guess that is just the way large projects are.

Regards,
Stuart

 

[Dombo]

Op 24-Oct-12 12:01, Stuart schreef:

On 23-Oct-12 Jorgen Grahn wrote:
[snip]

It would probably also have prevented many C++ libraries from
implementing their own string and container classes. This is one thing I
dislike about C++.

+1.

I took an immediate dislike to qt because it seemed as if they had to
reinvent the wheel not only once but many times. Later I realized that
they wanted to have a copy-on-write semantics for their strings, which
could not be achieved with std::string at that time.

Now that std::string supports copy-on-write, too, noone on the qt team
seems inclined to remove the superfluous qtString class.

Even Microsoft still uses CObject as base class for all classes of their
MFC library, even though the whole purpose of this class was to provide
run-time type information.

Though there were valid reasons at the time for libraries to provide
their own string and container classes, it is a shame many
C++programmers still have to deal with this unfortunate legacy.

The main thing I hate is that when you use multiple libraries each with
their own string and container classes (and naming conventions,
idioms...etc), you have to write code to convert between various
classes. This is a waste of both programmer- and execution time.

 

[gwowen]

Le 21/10/2012 19:54, Les Cargill a écrit :
To badly> paraphrase Voltaire, "hell is other people's code*." The more of

You probably meant 'to paraphrase Jean-Paul Sartre'...
Voltaire has nothing to do with that sentence...
Ptyxs

Les was too busy correcting University Dons about category mistakes...