Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

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

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

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

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


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.

--
Les Cargill
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      10-21-2012
On 10/21/12 20:51, Les Cargill wrote:
> Juha Nieminen wrote:
>> In comp.lang.c++ Les Cargill<(E-Mail Removed)> wrote:

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

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

--
Ian Collins
 
Reply With Quote
 
 
 
 
Rui Maciel
Guest
Posts: n/a
 
      10-21-2012
James Kuyper wrote:

> 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
 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      10-21-2012
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.


<snip/>
>> C++ also offers many tools (in both native syntax and in the form of
>> the standard library) that makes many, many tasks a lot easier and
>> simpler than in C.
>>

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


<snip/>
>> Why would it matter to me
>> in the least bit if the language is large and requires a lot of
>> learning? That's completely inconsequential to me.

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

 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      10-21-2012
Juha Nieminen wrote:

> 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
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      10-21-2012


"Juha Nieminen" <(E-Mail Removed)> wrote in message
news:k608ee$ke2$(E-Mail Removed)...
> In comp.lang.c++ Les Cargill <(E-Mail Removed)> wrote:
>> 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.


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.

--
bartc

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

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

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


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


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


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
 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      10-21-2012
Ian Collins wrote:
> On 10/21/12 20:11, Les Cargill wrote:
>> Ian Collins wrote:
>>> On 10/21/12 07:44, Les Cargill wrote:
>>>> Juha Nieminen wrote:
>>>>
>>>>> 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.
>>>
>>> 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.

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

>> But RAII is
>> much less a concern when you don't have exceptions...

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

>>> 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!
>>>
>>>>> C isn't that kind of language. In C the "simplicity" forces the
>>>>> programmer to write complex programs that need to constantly be
>>>>> careful
>>>>> about things that should normally be non-issues.
>>>>>
>>>>> This doesn't mean that C++ is a simple language in this regard.
>>>>> However, C++ is a lot *better* in this regard than C. Yes, there are
>>>>> coding conventions that need to be followed eg. because of memory
>>>>> management reasons, but those conventions are simpler and easier to
>>>>> follow, and much of the work is done automatically by the compiler.
>>>>
>>>> Not... really. Let's not confuse our preferences for facts, shall we?
>>>
>>> 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

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