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"

 
 
Nick Keighley
Guest
Posts: n/a
 
      10-20-2012
On Oct 18, 8:55*am, 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.


seriously? I know quite a few people who are C programmers. Most are
embedded but not all.

I can see the appeal. I know pretty much all of C. I only know a large
percentage of C++. I haven't got round to the new C++ standard. I
don't know every little corner of the standard library and I certainly
don't know boost! Do you write exception safe code?

Please don't mention template-meta-programming...
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      10-20-2012
On Oct 20, 12:24*pm, Stuart <(E-Mail Removed)> wrote:
> On 10/19/12 James Kuyper wrote:
> On 10/20/12 Juha Nieminen 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.

>
> Umm, my question (which started this whole sub-thread) was not meant to
> critisize C programmers. I rather think that every C programmer is
> already a C++ programmer in disguise, since (mostly) all he has to do is
> to rename the source file from .c to .cpp/.cc/.mm. He can't do that if
> the project at hand forbids this. I was more or less interested whether
> C programmers deliberately chose C over C++ or whether they had no other
> choice.


bizzare definition of "C++ programmer". Many of the people I classify
as "C programmers" *you'd* classify as "C++ programmers"!. Some of
these people were actually using a C++ compiler and sometimes weren't
aware they were using C++ (using true and false for instance); but
nevertheless they were C programmers. To be a C++ programmer I submit
you have to use a significant part of non-C C++.

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


I'm not sure I agree

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


I'm not sure I'd call Common Lisp "simple"... Scheme maybe.

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

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


I simply disagree

> > requiring many of even the
> > simplest tasks to have complex and error-prone implementations.


for instance?

> > It
> > often requires following strict coding conventions to avoid mistakes,


I'm not aware of these coding conventions

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


I'm more aware of the coding conventions required in C++ (RAII for
instance)

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

>
> > The typical arguments that C++ is so much larger and more complex
> > than C, and that it requires significantly more learning, ring quite
> > hollow to the experienced C++ programmer. 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. It may be relevant
> > if we were talking about what a newbie programmer should learn, but
> > it's completely irrelevant to me. I know how to use the language
> > efficiently, and when given the choice between C or C++, there's just
> > no choice to make, because it's obvious. I choose the one that allows
> > me to implement the task at hand more easily, ie. C++.

>
> Nicely put, almost textbook.
>
> There is another argument that could convince me to use C instead of
> C++: If the simplicity of the language C allowed it to be both compiled
> as well as interpreted, then I would favour C (AFAIK, Java's syntax was
> deliberately kept "simple" so that code can be added at run-time,
> something that would be real nightmare under C++). However, there is no
> such C interpreter (at least I don't know one).
>
> Just a side note: Apparently Apple thinks that C++ is so much more
> complicated than C that their Xcode IDE refuses to refactor ObjectiveC++
> code whereas it accepts ObjectiveC code just fine. Strange, but true.
>
> Regards,
> Stuart


 
Reply With Quote
 
 
 
 
Les Cargill
Guest
Posts: n/a
 
      10-20-2012
Juha Nieminen wrote:
> In comp.lang.c++ William Ahern <william@wilbur.25thandclement.com> wrote:
>> Reasonable people can disagree about the merits of C viz-a-viz C++. But
>> reasonable people cannot disagree that C is still very much in use in all
>> the same places that C++ is used, for both new and old code. It's not
>> relegated to device drivers and embedded work, by any stretch of the
>> imagination.

>
> It's just that in an environment where both C and C++ are equally
> viable options (which is most of the environments where you would
> want to use either one), most experienced C++ programmers can't think
> of any reason why they should limit themselves to C. Because, to be
> frank, that would be quite a serious limitation.
>


Unless you put some serious time on on non-C++ 'C', you will
think rather differently than someone who has. Path dependence
is path dependent.

> C++ might be big and have tons and tons of features, but once you become
> really experienced with it, it just becomes so much *esier* to do things
> with it than with C.


I really do not know about that. Just the general schism over string
types alone makes life much more difficult. The whole subject is
fraught with massive observer bias.

> 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. Which you do by replacing an stl::map() with
a bleeding-edge string table in a 'C' fashion

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

*no, I am not going to specify how that figure was arrived at...

What we do is settle on classes of solutions, and stay there.

--
Les Cargill


 
Reply With Quote
 
Les Cargill
Guest
Posts: n/a
 
      10-20-2012
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.

> 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?
The subject is sufficiently complex that you have to figure out how to
measure the thing being discussed - you can't constructively assert
superiority with out doing a lot of work, and that's pretty boring
work. It's actually both boring and terrifying.

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

> The typical arguments that C++ is so much larger and more complex
> than C, and that it requires significantly more learning, ring quite
> hollow to the experienced C++ programmer.


Because experienced programmer is experienced. The very basis for
determining whether the language features are improvements is
really complex and usually such discussions are simply people
exposing biases.

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

> It may be relevant
> if we were talking about what a newbie programmer should learn, but
> it's completely irrelevant to me. I know how to use the language
> efficiently, and when given the choice between C or C++, there's just
> no choice to make, because it's obvious. I choose the one that allows
> me to implement the task at hand more easily, ie. C++.
>


--
Les Cargill

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-20-2012
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, 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....

--
Ian Collins
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      10-20-2012
On 10/21/12 02:45, Nick Keighley wrote:
>> On 10/19/12 James Kuyper wrote:
>>
>>> In other words, a simple language helps writing simple programs (that
>>> are nevertheless very expressive.)

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

>
> I simply disagree
>
>>> requiring many of even the
>>> simplest tasks to have complex and error-prone implementations.

>
> for instance?


Almost anything that involves a dynamically sized set of data. One
operation I often have to perform is reading often very large lists of
string, number pairs into an associative array indexed by the string or
a set sorted by the number. Almost one liners in C++.

--
Ian Collins
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      10-20-2012
Op 20-Oct-12 15:45, Nick Keighley schreef:
> On Oct 20, 12:24 pm, Stuart <(E-Mail Removed)> wrote:
>> On 10/19/12 James Kuyper wrote:
>> On 10/20/12 Juha Nieminen 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.

>>
>> Umm, my question (which started this whole sub-thread) was not meant to
>> critisize C programmers. I rather think that every C programmer is
>> already a C++ programmer in disguise, since (mostly) all he has to do is
>> to rename the source file from .c to .cpp/.cc/.mm. He can't do that if
>> the project at hand forbids this. I was more or less interested whether
>> C programmers deliberately chose C over C++ or whether they had no other
>> choice.

>
> bizzare definition of "C++ programmer". Many of the people I classify
> as "C programmers" *you'd* classify as "C++ programmers"!. Some of
> these people were actually using a C++ compiler and sometimes weren't
> aware they were using C++ (using true and false for instance); but
> nevertheless they were C programmers. To be a C++ programmer I submit
> you have to use a significant part of non-C C++.


My experience is that people with a lot of experience with C coding
actually have a disadvantage when trying to become a good C++
programmers. Though the C way of doing things still work with C++
compilers it is far from idiomatic C++.

 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      10-20-2012
Op 20-Oct-12 22:09, Ian Collins schreef:
> 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, 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....


....and other alternate/exceptional execution flows.

 
Reply With Quote
 
Fritz Wuehler
Guest
Posts: n/a
 
      10-20-2012
Juha Nieminen <(E-Mail Removed)> wrote:

most of what you wrote is agreeable, snipped...

> Also, C++ does have some features that are not offered by other languages.


This is hard to believe. Would you be inclined to name a few? I'm not a
C/C++ guy so I'll have to check but I really find it difficult to believe C
or C++ could offer anything that isn't offered by other languages for a few
reasons:

C is not the oldest language, therefore it was based on ideas and languages
that came before. C++ is based on C and other ideas and languages that came
before. There have been many new languages since C++ and many many new ones
since C. Aside from "features" that are really nothing more than quirks or
bad design, are you really suggesting a language written 20 years ago based
on a language written 20 years or so before that has features other
languages don't offer? That would be interesting!

Are you being pedantic and suggesting C++ has features that aren't presented
exactly the same way in other languages, or are you suggesting C++ really
has features that have no equivalents in other languages, or ???

 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      10-20-2012
Op 20-Oct-12 22:41, Fritz Wuehler schreef:
> Juha Nieminen <(E-Mail Removed)> wrote:
>
> most of what you wrote is agreeable, snipped...
>
>> Also, C++ does have some features that are not offered by other languages.

>
> This is hard to believe. Would you be inclined to name a few? I'm not a
> C/C++ guy so I'll have to check but I really find it difficult to believe C
> or C++ could offer anything that isn't offered by other languages for a few
> reasons:
>
> C is not the oldest language, therefore it was based on ideas and languages
> that came before. C++ is based on C and other ideas and languages that came
> before. There have been many new languages since C++ and many many new ones
> since C. Aside from "features" that are really nothing more than quirks or
> bad design, are you really suggesting a language written 20 years ago based
> on a language written 20 years or so before that has features other
> languages don't offer? That would be interesting!
>
> Are you being pedantic and suggesting C++ has features that aren't presented
> exactly the same way in other languages, or are you suggesting C++ really
> has features that have no equivalents in other languages, or ???


I don't know every programing language in existence, but as far as know
there aren't that many programming languages that support RAII
(deterministic destructors) and templates like C++ does.

Also C++ has evolved significantly over the last 20 years. The C++
language I learned C++ 20 years ago is very different from C++ as we
know it today. 20 years ago C++ was little more than C with classes; no
templates, no standard library (or STL), no exceptions...etc.

One cannot consider programming language features in isolation; the
necessity/added-value of a feature and even if possibility of adding a
feature depends on the language as a whole. Reasons that other
programming languages do no support a certain features may be due to
that it doesn't fit in well with other parts of the language (e.g.
deterministic destructors), or that the language designer opted for a
much less powerful but simpler alternative (e.g. generics instead of
templates), or that the language designer doesn't believe that the
feature is a good idea (e.g. operator overloading), or even leave a
feature out entirely because other aspects of the language make the
feature unnecessary (e.g. a dynamically typed language has little use
for templates or generics).



 
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