Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C/C++ question about dynamic "static struct"

Reply
Thread Tools

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

 
 
Rui Maciel
Guest
Posts: n/a
 
      10-22-2012
Tobias Müller wrote:

> Ian Collins <(E-Mail Removed)> wrote:
>> 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 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.


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


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


Rui Maciel
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      10-22-2012
Les Cargill wrote:

> Rui Maciel wrote:
>> Les Cargill wrote:
>>
>>> Juha Nieminen wrote:
>>>> In comp.lang.c++ Ian Collins <(E-Mail Removed)> wrote:
>>>>>> I'm sure that's quite normal thinking for anyone who would label
>>>>>> themselves a "C++ programmer". However, you should not be surprised
>>>>>> to find very different thinking among the people frequenting
>>>>>> comp.lang.c, where this message is also cross-posted. Anyone
>>>>>> bothering to monitor comp.lang.c (and there's a fair number of us)
>>>>>> can reasonably be expected to choose the simplicity of C over the
>>>>>> complexity of C++ in at least some circumstances. You might question
>>>>>> the validity of that choice, but you can't expect such questions to
>>>>>> go over very well in that newsgroup.
>>>>>
>>>>> A one who works with and enjoys both languages, the statement "choose
>>>>> the simplicity of C over the complexity of C++" is one I have trouble
>>>>> with. C is undoubtedly a simpler language, but the the solutions to
>>>>> many day to day problems are undoubtedly simpler in C++.
>>>>>
>>>>> So the choice is often "do I want the simple solution in a more
>>>>> complex language, or the more complex solution in a simple language?".
>>>>
>>>> That's also the problem I find with the "argument from simplicity",
>>>> as one could call it.
>>>>
>>>> When talking about C, making the simplicity argument is basically a
>>>> category error.
>>>
>>> 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".
>>>
>>>> The argument is trying to appeal to the notion that
>>>> simpler higher-level languages (such as Lisp) are generally considered
>>>> better than overly complex languages. In those languages it is often
>>>> so that the same thing can be expressed in a much simpler and more
>>>> brief manner, and the result is much "leaner and cleaner" code than
>>>> in overly complicated languages. (For example the language
>>>> specification of Lisp is relatively short, yet the language itself is
>>>> incredibly expressive and powerful.)
>>>>
>>>> In other words, a simple language helps writing simple programs (that
>>>> are nevertheless very expressive.)
>>>>
>>>
>>> No, the thing about lisp is that it is *interpretive*.
>>>
>>>> However, in the case of C the "simplicity" is not actually a factor
>>>> that helps writing simple programs. On the contrary, the "simplicity"
>>>> of the language is actually a limiting factor. Rather than help, it
>>>> impedes the writing of simple programs, requiring many of even the
>>>> simplest tasks to have complex and error-prone implementations. It
>>>> often requires following strict coding conventions to avoid mistakes,
>>>> coding conventions that are completely unnecessary in truly simple
>>>> languages. Truly simple languages allow the programmer to concentrate
>>>> purely on the task at hand, without having to pay any attention to such
>>>> trivial and inconsequential matters as memory management and such.
>>>
>>> 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.
>>
>>

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


<snip/>
>> with C++ you are
>> including everything plus the kitchen sink.

>
> That's exactly my point. <insert Stimpy and the shiny red button here>
>
>> 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.


Your direct observations lead you to believe that it is impossible to write
C++ code which is also 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.
>>
>>

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


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

>
> 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
 
Reply With Quote
 
 
 
 
Tobias Müller
Guest
Posts: n/a
 
      10-22-2012
Rui Maciel <(E-Mail Removed)> wrote:
> Tobias Müller wrote:
>
>> Ian Collins <(E-Mail Removed)> wrote:
>>> 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 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):
Rui Maciel <(E-Mail Removed)> wrote:
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++.


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


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
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
In comp.lang.c++ Les Cargill <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
Les Cargill <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
In comp.lang.c++ James Kuyper <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-22-2012
In comp.lang.c++ Les Cargill <(E-Mail Removed)> wrote:
>> 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...


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?

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


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.)
 
Reply With Quote
 
ptyxs
Guest
Posts: n/a
 
      10-22-2012
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



 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      10-22-2012
On 10/22/2012 04:13 AM, Juha Nieminen wrote:
> In comp.lang.c++ James Kuyper <(E-Mail Removed)> wrote:
>> 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.


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


So our experiences have been quit different. There's not much more
useful that can be said about that.
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      10-22-2012
Juha Nieminen wrote:
> In comp.lang.c++ Les Cargill <(E-Mail Removed)> wrote:
>> 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.
>


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.

--
Les Cargill
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Array question - How dynamic is dynamic? Ruby Student Ruby 4 04-09-2009 12:59 PM
Dynamic control on aspx page, dynamic location Chris Thunell ASP .Net 3 07-21-2004 04:52 PM
VPN between 2 Cisco routers (1 static, 1 dynamic) with access from stat --> dynamic over ISDN Hans-Peter Walter Cisco 3 01-21-2004 02:12 PM
Does Pix or cisco router support dynamic-to-dynamic IPSec VPN? c Cisco 2 01-13-2004 01:53 AM
Re: Dynamic Table with Dynamic LinkButtons Rick Glos ASP .Net 0 07-08-2003 01:09 PM



Advertisments