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"

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

>>
>> I simply disagree

>
> You are entitled to. However, do you have an actual *argument* against
> what I said, other than "I simply disagree" and "for instance?"
>
> In things like Lisp, Haskell and Scheme, the simplicity of the language
> usually translates to the code itself becoming simple and elegant. Often
> you can express in a couple of lines what requires dozens of lines in C++
> and hundreds of lines in C. And those two lines are not obfuscated beyond
> comprehension, but (when you know the language) are clear, simple and
> elegant.
>
> There are several reasons for this, but one of the most important ones is
> that the language doesn't burden the programmer with things like memory
> management.
>
> Many C advocates try to ride on this concept of "simplicity", but what
> they are doing is a glaring fallacy of equivocation. They are (perhaps
> deliberately) confusing the brevity of the language specification with
> the concept of "simplicity" when talking about programming languages.
>


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.

Granted, Scheme/Lisp et al will always be more elegant because
functional notation always is.

There are times to build perfect Pythagorean castles in the air,
and there are times to solder wires to things. The trick is knowing
when.

> Just because the language specification is relatively short (and it's
> relatively easy to make a compiler for it) doesn't make the language
> *simple*. This is a different kind of "simplicity". A kind that does
> *not* help the programmer, but on the contrary is a limitation.
>


So they tell us. So they tell us.

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


By "other languages" I was referring to the ones popularly used.

For example RAII *is* offered by some other languages (eg. if I remember
correctly ADA might have had it), but those tend to be either obscure
languages that nobody uses, or have fallen almost completely out of usage
in practice (except in very narrow and specific industries, eg. with ADA.)

(And no, this was not an argument on whether RAII is better than automatic
GC. That was not the point.)

It's hard to classify if any language offers the same functionality as
C++ templates do (regardless of what you think about their syntax; I'm
talking purely about the functionality here.) There are certainly some
languages (especially some functional ones) which you might argue offer
the same functionality, although using a rather different approach. But
even then there often are radical differences.
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      10-21-2012
In comp.lang.c++ Nick Keighley <(E-Mail Removed)> wrote:
> 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?


That last question is really odd at the end of the paragraph that's
otherwise talking about something else entirely. Care to explain?
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-21-2012
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.

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

(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.)
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      10-21-2012
In comp.lang.c++ Ian Collins <(E-Mail Removed)> wrote:
>> But RAII is
>> much less a concern when you don't have exceptions...

>
> Not at all. 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.


I have seen the exception-safety argument (ie. "RAII is mostly useful to
make code exception-safe, but without support for exceptions they are
not all that useful") quite many times, and I have always wondered where
it comes from.

RAII is most certainly very useful even if you didn't have exceptions.
It makes code much safer and simpler at the same time. The more complicated
the interactions between different modules and data containers, the more
that stuff is passed around, the more useful RAII becomes in order to keep
the program simple and safe.
 
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:
>>> 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
 
 
 
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