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"

 
 
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
 
Í÷ Tiib
Guest
Posts: n/a
 
      10-21-2012
On Sunday, 21 October 2012 14:43:53 UTC+3, James Kuyper wrote:
> 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.


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.


 
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
 
Les Cargill
Guest
Posts: n/a
 
      10-21-2012
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.

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


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.

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


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.


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.

> 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


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

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


--
Les Cargill
 
Reply With Quote
 
Tobias M├╝ller
Guest
Posts: n/a
 
      10-21-2012
Rui Maciel <(E-Mail Removed)> wrote:.
[...]
> 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
 
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:
>>> Just the standard library alone makes life so much
>>> easier (no matter if you are just making a quick 50-line test program
>>> or a large 50k-line serious project.)

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


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.

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


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.

--
Les Cargill
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-21-2012
On Thu, 2012-10-18, William Ahern wrote:
> In comp.lang.c Stuart <(E-Mail Removed)> wrote:
>> 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!

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
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