Why C++ is vastly superior to C:
     http://warp.povusers.org/programming/cplusplus_superior_to_c.html

"In conclusion, the reason why C is so vastly inferior to C++ as
described in this article can be summarized with one single sentence:
C has no support for RAII nor templates, while C++ does. That's two
of the most important features that make C++ by far the superior
language."

Lynn

"Lynn McGuire" <lmc@winsim.com> wrote in message 
news:iqremk$ltg$1@dont-email.me...
> Why C++ is vastly superior to C:
>     http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."

the main thing is the object oriented approach, i guess. Also many improved 
version of functions 

"Lynn McGuire" <lmc@winsim.com>

> Why C++ is vastly superior to C:
>     http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."

Quite so. Another "most important" feature was parting with "locals at block 
start", but it got into C99 in the mantime.  (too bad that real-world C is 
still at C90, a decade+ after the last revision, and massive projects still 
stick to that old known bug generator. :( )

On 16 touko, 18:08, Lynn McGuire <l...@winsim.com> wrote:
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features

You can live without templates, it's the least important feature
of C++ and people constantly over/misuse it. Most important feature
is class programming: instances, encapsulation and inheritance,
the OOP basics.

On 16/05/2011 17:29, Krice wrote:
> On 16 touko, 18:08, Lynn McGuire<l...@winsim.com>  wrote:
>> "In conclusion, the reason why C is so vastly inferior to C++ as
>> described in this article can be summarized with one single sentence:
>> C has no support for RAII nor templates, while C++ does. That's two
>> of the most important features
>
> You can live without templates, it's the least important feature
> of C++ and people constantly over/misuse it. Most important feature
> is class programming: instances, encapsulation and inheritance,
> the OOP basics.

I disagree; generic programming is just as important as object oriented 
programming.

/Leigh

Krice <paulkp@mbnet.fi> wrote:
> On 16 touko, 18:08, Lynn McGuire <l...@winsim.com> wrote:
>> "In conclusion, the reason why C is so vastly inferior to C++ as
>> described in this article can be summarized with one single sentence:
>> C has no support for RAII nor templates, while C++ does. That's two
>> of the most important features
> 
> You can live without templates, it's the least important feature
> of C++ and people constantly over/misuse it. Most important feature
> is class programming: instances, encapsulation and inheritance,
> the OOP basics.

  I disagree.

  Encapsulation and instantiation are extremely important, yes, but you
can achieve that to a certain degree in C as well. Access rights might
not be enforced by the language (except on the compilation unit level),
but you can achieve this to a certain degree by agreement (iow. "don't
touch anything inside this struct"). Yes, this is not perfect, but it's
not catastrophical either. This is not the main reason why C is inferior
to C++.

  Inheritance is useful in some situations, but it's far less useful than
was thought at the height of the OOP craze in the 90's. It definitely has
its uses, but it has its shortcomings as well. It is an important feature,
but I would certainly not rank it higher than RAII and templates.

  As for templates, I fully disagree: A C++ without templates would be
almost as horrible as C is. (RAII would still make it by far superior,
but the lack of templates would be a huge setback nevertheless.)

  If you can live without templates, how would you implement the last
challenge in the article (iow. making the example Matrix class generic,
to support any numerical type, including those which do not behave like
basic types)?

  On the same note, how would you make generic data containers and
algorithms which are as efficient as possible? (Note their prominent
absence in standard C; there's a reason for that.) Other programming
languages manage by other means, but they often suffer from poorer
efficiency (especially in the memory consumption department, sometimes
also in the speed one).

Lynn McGuire <lmc@winsim.com> wrote:
> Why C++ is vastly superior to C:
>     http://warp.povusers.org/programming/cplusplus_superior_to_c.html

  I'm glad I'm not writing those articles just for myself... :)

On 5/16/2011 11:29 AM, Krice wrote:
> On 16 touko, 18:08, Lynn McGuire<l...@winsim.com>  wrote:
>> "In conclusion, the reason why C is so vastly inferior to C++ as
>> described in this article can be summarized with one single sentence:
>> C has no support for RAII nor templates, while C++ does. That's two
>> of the most important features
>
> You can live without templates, it's the least important feature
> of C++ and people constantly over/misuse it. Most important feature
> is class programming: instances, encapsulation and inheritance,
> the OOP basics.

I could not live without the Standard Template Library.

Lynn

On May 16, 7:37=A0pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 16/05/2011 17:29, Krice wrote:
>
> > On 16 touko, 18:08, Lynn McGuire<l...@winsim.com> =A0wrote:
> >> "In conclusion, the reason why C is so vastly inferior to C++ as
> >> described in this article can be summarized with one single sentence:
> >> C has no support for RAII nor templates, while C++ does. That's two
> >> of the most important features
>
> > You can live without templates, it's the least important feature
> > of C++ and people constantly over/misuse it. Most important feature
> > is class programming: instances, encapsulation and inheritance,
> > the OOP basics.
>
> I disagree; generic programming is just as important as object oriented
> programming.

+1.

Encapsulation can be done well in C. Just like the FILE* in C library.
You know nothing about it but the functions ("methods") with what you
can manipulate one. Similarly abstract interfaces and polymorphism can
be implemented in C with function pointers. There is some semantic
overhead but that can be reduced with macros. It is easy to write
small quick programs in pure C.

C++ however scales well. Templates in interface simplify integration
of your code with a library by huge margin. The big legacy C++
libraries have gradually increased presence of templates in their
interface. In boost and in Loki the templates are sometimes overused
but that is because the authors were curious and like to explore the
possibilities.

RAII is great way to reduce the need for garbage collection. Being
careful you create no garbage. The usual garbage collection takes care
of least important resource ... the memory. I have started to hate
Windows lately because some of the garbage collected crap has left
files open and so i can't delete those without closing all the
applications. Also the applications start back up slowly like snails.

On Mon, 16 May 2011 09:29:07 -0700, Krice wrote:

> You can live without templates, it's the least important feature
> of C++ and people constantly over/misuse it. Most important feature
> is class programming: instances, encapsulation and inheritance,
> the OOP basics.

Maybe for you. OTOH, if performance matters, templates are essential.
And if performance doesn't matter, higher-level languages offer the OOP
features with less hassle. IOW, if you don't need templates, you probably
don't need C++ either.

On 16 touko, 20:36, Lynn McGuire <l...@winsim.com> wrote:
> I could not live without the Standard Template Library.

Mostly because core C++ doesn't have something like std::string
or vector. If I need to write a template (beside using STL)
I know there is something wrong with the class hierarchy. It's
like using cast, you know it's a workaround to a design error.

On May 16, 10:53=A0am, Nobody <nob...@nowhere.com> wrote:
> On Mon, 16 May 2011 09:29:07 -0700, Krice wrote:
> > You can live without templates, it's the least important feature
> > of C++ and people constantly over/misuse it. Most important feature
> > is class programming: instances, encapsulation and inheritance,
> > the OOP basics.
>
> Maybe for you. OTOH, if performance matters, templates are essential.

I want to emphasize this. Templates are nice for code reuse, but
several posters ignored IMHO the most important aspect of their
utility. Templates allow generic code and code reuse without runtime
overhead. For too many people, and for some people with legitimate
concerns, there is almost a knee-jerk fear of runtime overhead, and
thus they would rather roll their own, every time, instead of use a
standard library or well tested, well optimized, library solution,
because of the overhead that using a non-template library would
impose.

Take C's sort. The comparator function is a function pointer, and the
last I heard is that most compilers simply will not expand that
inline, as opposed to C++ various sort functions which can be expanded
inline.

"Krice" <paulkp@mbnet.fi>
> On 16 touko, 20:36, Lynn McGuire <l...@winsim.com> wrote:
>> I could not live without the Standard Template Library.
>
> Mostly because core C++ doesn't have something like std::string
> or vector.

String could very well be a simple class, but how do you create a good 
vector without templates? Do you suggest to go back to only have the 
"Object-based" polymorphic array? Even java failed miserably on that point, 
if you recall the hype raving that templates are not good and would never 
make it into a cool language of theirs.  Finally generics were incorporated 
around 1.5 -- mainly to cover the mass problems with collections. :-)

> If I need to write a template (beside using STL)
> I know there is something wrong with the class hierarchy.

The most ubiquitous problem with class hierarchy is thet you don't need one 
in the first place.
Sure, having hierarchy is great for some particular cases, I both used and 
wrote such, but it is in minority by far.

> It's like using cast, you know it's a workaround to a design error.

I don't see any likeness. Hierarchy is good for runtime polymorphism, while 
templates cover the common case where the type is fixed at compile time.

On May 16, 12:25=A0pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Lynn McGuire <l...@winsim.com> wrote:
> > Why C++ is vastly superior to C:
> > =A0 =A0http://warp.povusers.org/programming/cplusplus_superior_to_c.htm=
l
>
> =A0 I'm glad I'm not writing those articles just for myself... :)

Also from the conclusion:
"The example I described in this lengthy article is but just one of
the reasons why C is so vastly inferior to C++."

The "but just one" part is not common usage. You could
use "but one of ..." or "just one of ..."  I think the latter
would be good.  I think I'd cut the vastly word also -- "so
inferior" pretty much covers it.

Krice wrote:

> Mostly because core C++ doesn't have something like std::string
> or vector. 

Why would anyone extend the base language to incorporate something which 
is easily implemented (and, better yet, extendable) through other basic 
language constructs?


> If I need to write a template (beside using STL)
> I know there is something wrong with the class hierarchy. 

Do you know how I can tell you aren't a good programmer?


Rui Maciel

Balog Pal wrote:

> Quite so. Another "most important" feature was parting with "locals at
> block start", but it got into C99 in the mantime.  (too bad that
> real-world C is still at C90, a decade+ after the last revision, and
> massive projects still stick to that old known bug generator. :( )

What do you mean by "real-world C is still at C90"?


Rui Maciel

On 05/17/11 08:21 AM, Rui Maciel wrote:
> Balog Pal wrote:
>
>> Quite so. Another "most important" feature was parting with "locals at
>> block start", but it got into C99 in the mantime.  (too bad that
>> real-world C is still at C90, a decade+ after the last revision, and
>> massive projects still stick to that old known bug generator. :( )
>
> What do you mean by "real-world C is still at C90"?

C99 compilers are by no means universal.  A lot of embedded (the 
majority of C projects) projects are still stuck with C90 tools.

-- 
Ian Collins

Krice <paulkp@mbnet.fi> wrote:
> If I need to write a template (beside using STL)
> I know there is something wrong with the class hierarchy. It's
> like using cast, you know it's a workaround to a design error.

  What happens when the STL is not enough? There are myriads of different
data containers out there, and the STL only offers about 5 of them.

  Why is it a design error to make your libraries generic and reusable?
That sounds to me like the exact opposite.

On 05/17/11 03:08 AM, Lynn McGuire wrote:
> Why C++ is vastly superior to C:
>       http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."

I normally just use RAII as the reason.  Everything else else can be 
kludged in C, but not RAII.

-- 
Ian Collins

On 16 touko, 23:11, Rui Maciel <rui.mac...@gmail.com> wrote:
> Do you know how I can tell you aren't a good programmer?

I'm the first person in the world who wrote a roguelike with zero
bugs.
A thing like that didn't even exist before I made that possible.
I'm not good, I'm the best.

Ian Collins <ian-news@hotmail.com> wrote:
> I normally just use RAII as the reason.  Everything else else can be 
> kludged in C, but not RAII.

  It's quite difficult to kludge any kind of generic data containers in C
(which is probably the reason why the standard C library does not offer
any such containers). You could achieve something similar with preprocessor
macros, but it would be quite limited, and definitely less safe (in big
part because of the lack of RAII, constructors, destructors, etc).

  You could perhaps make some more or less generic containers for basic
types and structs which only contain basic types (but not pointers) with
preprocessor macros, but immediately when you need more resource management
than that (such as a struct that as pointers pointing to dynamically
allocated memory or other such resources) it becomes complicated. For that
same reason it's complicated to make the containers nested. (Assigning
a container object would not be the same as assigning a basic type.)

  It's so much simpler with C++ templates. Just write any amount of
nested containers you want, no problem.

std::deque<std::list<std::vector<std::set<std::string> > > > container;

On 05/17/11 09:16 AM, Juha Nieminen wrote:
> Ian Collins<ian-news@hotmail.com>  wrote:
>> I normally just use RAII as the reason.  Everything else else can be
>> kludged in C, but not RAII.
>
>    It's quite difficult to kludge any kind of generic data containers in C
> (which is probably the reason why the standard C library does not offer
> any such containers). You could achieve something similar with preprocessor
> macros, but it would be quite limited, and definitely less safe (in big
> part because of the lack of RAII, constructors, destructors, etc).

I think you are spot on with why C lacks standard containers.  But it 
does have a limited set of generic algorithms.

>    You could perhaps make some more or less generic containers for basic
> types and structs which only contain basic types (but not pointers) with
> preprocessor macros, but immediately when you need more resource management
> than that (such as a struct that as pointers pointing to dynamically
> allocated memory or other such resources) it becomes complicated. For that
> same reason it's complicated to make the containers nested. (Assigning
> a container object would not be the same as assigning a basic type.)

If you want an idea how complicated it is, have a look at the C 
containers library Jacob Navia has been developing 
(http://code.google.com/p/ccl/).

>    It's so much simpler with C++ templates. Just write any amount of
> nested containers you want, no problem.
>
> std::deque<std::list<std::vector<std::set<std::string>  >  >  >  container;

I'm not saying it's not a lot easier to do generic containers or 
algorithms with templates.  I'm saying it's impossible to do RAII in C.

I've often been asked by teams I've managed or coached why they should 
look at using C++ rather than C and my response normally something along 
the lines of "what's an automatic, simple means of preventing resource 
leaks worth to you?"  Then we get onto the other stuff!  One (DSP) team 
was happy just to use C++ as "C with RAII (and function overloading)".

-- 
Ian Collins

On 5/16/2011 4:35 PM, Ian Collins wrote:
> On 05/17/11 09:16 AM, Juha Nieminen wrote:
>> Ian Collins<ian-news@hotmail.com> wrote:
>>> I normally just use RAII as the reason. Everything else else can be
>>> kludged in C, but not RAII.
>>
>> It's quite difficult to kludge any kind of generic data containers in C
>> (which is probably the reason why the standard C library does not offer
>> any such containers). You could achieve something similar with preprocessor
>> macros, but it would be quite limited, and definitely less safe (in big
>> part because of the lack of RAII, constructors, destructors, etc).
>
> I think you are spot on with why C lacks standard containers. But it does have a limited set of generic algorithms.
>
>> You could perhaps make some more or less generic containers for basic
>> types and structs which only contain basic types (but not pointers) with
>> preprocessor macros, but immediately when you need more resource management
>> than that (such as a struct that as pointers pointing to dynamically
>> allocated memory or other such resources) it becomes complicated. For that
>> same reason it's complicated to make the containers nested. (Assigning
>> a container object would not be the same as assigning a basic type.)
>
> If you want an idea how complicated it is, have a look at the C containers library Jacob Navia has been developing
> (http://code.google.com/p/ccl/).
>
>> It's so much simpler with C++ templates. Just write any amount of
>> nested containers you want, no problem.
>>
>> std::deque<std::list<std::vector<std::set<std::string> > > > container;
>
> I'm not saying it's not a lot easier to do generic containers or algorithms with templates. I'm saying it's impossible to do RAII in C.
>
> I've often been asked by teams I've managed or coached why they should look at using C++ rather than C and my response normally
> something along the lines of "what's an automatic, simple means of preventing resource leaks worth to you?" Then we get onto the
> other stuff! One (DSP) team was happy just to use C++ as "C with RAII (and function overloading)".

True.  And better code syntax error detection than C ever
thought of.

Lynn

Joshua Maurice <joshuamaurice@gmail.com> writes:
>Take C's sort. The comparator function is a function pointer,
>and the last I heard is that most compilers simply will not
>expand that inline, as opposed to C++ various sort functions
>which can be expanded inline.

  According to

http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php

  C++ is not much faster than C (the median value actually is
  a little bit slower than C if I understand the table right),
  and according to

http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png

  , C++ has lost half of its �market share� in relation to C
  since 2003.

  However, C++ is much more complicated and large than C.
  Programmers have to learn exception-safe programming, the
  rule of the three, references, K�nig-lookup, soon rvalue
  references ... up to the point where, AFAIK, the recent
  draft of the language specification has more than 1000
  pages, not including the C spec it is based one. 

  When the market share continues to decline, C++ will become
  a legacy language of the 90s.

Ian Collins <ian-news@hotmail.com> writes:
>I normally just use RAII as the reason.  Everything else else can be 
>kludged in C, but not RAII.

  RAII helps to release resources even in the case of exceptions.
  But C does not have exceptions. So RAII is not needed for this.

  RAII helps to do one thing �alloc()� at block entry and another
  thing �release()� at block exit. This can be done in C using:

if( a = alloc() ){ rest(); release( a ); }.

Ian Collins <ian-news@hotmail.com> wrote:
> I'm not saying it's not a lot easier to do generic containers or 
> algorithms with templates.  I'm saying it's impossible to do RAII in C.

> I've often been asked by teams I've managed or coached why they should 
> look at using C++ rather than C and my response normally something along 
> the lines of "what's an automatic, simple means of preventing resource 
> leaks worth to you?"  Then we get onto the other stuff!  One (DSP) team 
> was happy just to use C++ as "C with RAII (and function overloading)".

"Resource Acquisition is Initialization". The primary benefit from RAII is
ordering resource initializations so that you don't end up with an
innumerable number of failure combinations, and limiting shared ownership of
resources, preferable in a strongly hierarchical arrangement. It's not in
automatic destruction of automatic storage objects, which is comparatively
more useful in C++ than C because in C++ the exit from a routine could be
involutary given exceptions.

Proper ordering of resource mangement in C also gets you the majority of
these benefits, a result not of language features but of good programming
habits. Comparing poor resource management in C with good resource
management in C++ is comparing apples to oranges. If programmers were so
inept at tracking memory anyhow, they'd be best in a GCd environment. If
they feel the impulse to allocate dynamic strings randomly where ever it
suits them, then they're begging for leaks, and really should be using a GCd
language, whether in C or C++. If they properly order allocation of these
resources, then the gap between C and C++ becomes quite small; maybe not
small enough, but perhaps for other considerations to move to the forefront.

[I'll refrain from commenting on the obscene nested containers example as
I'm sure it made you cringe as well.]

On 05/17/11 10:58 AM, Stefan Ram wrote:
> Joshua Maurice<joshuamaurice@gmail.com>  writes:
>> Take C's sort. The comparator function is a function pointer,
>> and the last I heard is that most compilers simply will not
>> expand that inline, as opposed to C++ various sort functions
>> which can be expanded inline.
>
>    According to
>
> http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
>
>    C++ is not much faster than C (the median value actually is
>    a little bit slower than C if I understand the table right),
>    and according to

That, as ever, depends on what you are doing.

>    However, C++ is much more complicated and large than C.
>    Programmers have to learn exception-safe programming, the
>    rule of the three, references, K�nig-lookup, soon rvalue
>    references ...

No, they don't.  They may have to if they are supporting legacy code 
that uses every feature under the sun (which tends to be written by 
novices keen to use them!).  For new projects, they can choose a subset 
they are happy with.

>    up to the point where, AFAIK, the recent
>    draft of the language specification has more than 1000
>    pages, not including the C spec it is based one.

The complexity of any given problem is constant.  Whether that 
complexity is hidden in a language or exposed user code is a choice. 
Most of the new features will remove complexity from user code.

-- 
Ian Collins

On 05/17/11 11:07 AM, Stefan Ram wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>> I normally just use RAII as the reason.  Everything else else can be
>> kludged in C, but not RAII.
>
>    RAII helps to release resources even in the case of exceptions.
>    But C does not have exceptions. So RAII is not needed for this.

It also enables early return (whether that's considered good practice is 
another debate!), removing the need for those awful gotos so often seen 
in C code.

>    RAII helps to do one thing �alloc()� at block entry and another
>    thing �release()� at block exit. This can be done in C using:
>
> if( a = alloc() ){ rest(); release( a ); }.

It can't be done automatically in C.

-- 
Ian Collins

"Stefan Ram" <ram@zedat.fu-berlin.de>
>  C++ is not much faster than C (the median value actually is
>  a little bit slower than C if I understand the table right),
>  and according to
>
> http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
>
>  , C++ has lost half of its �market share� in relation to C
>  since 2003.

Market share? The png's title says "Community index".

Ian Collins <ian-news@hotmail.com> writes:
>>C++ is not much faster than C (the median value actually is
>>a little bit slower than C if I understand the table right),
>>and according to
>That, as ever, depends on what you are doing.

  I agree. Still a benchmark using several different 
  programs gives at least a vague hint.

>>However, C++ is much more complicated and large than C.
>>Programmers have to learn exception-safe programming, the
>>rule of the three, references, K�nig-lookup, soon rvalue
>>references ...
>No, they don't.  They may have to if they are supporting legacy code 

  There are more �maintainence programmer hours� 
  (as I recently read, but - sorry - I forget where) 
  than there are �build-from-scratch programmer hours�
  paid in the world today.

  However, as many programmers only use a subset of C++'s features,
  often that legacy code will indeed not use every feature.
  But a programmer might not know /which/ features his next
  maintainance project has chosen to use, so he might feel
  the need to be prepared for every possible features.

  One needs to write exception-safe code even if one never
  �uses� (that is, throws or catches) exceptions, because called
  library functions might throw exception. One might never define
  overloaded function names, but still needs to know, what's
  wrong with �( ::std::cos( 0 ))�.

On May 16, 3:58=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >Take C's sort. The comparator function is a function pointer,
> >and the last I heard is that most compilers simply will not
> >expand that inline, as opposed to C++ various sort functions
> >which can be expanded inline.
>
> =A0 According to
>
> http://shootout.alioth.debian.org/u32/which-programming-languages-are...
>
> =A0 C++ is not much faster than C (the median value actually is
> =A0 a little bit slower than C if I understand the table right),

I would have assumed that we both knew:

1- Such measures are less than reliable. Specifically, to take a quote
from that link "No. Which programming language implementations have
the fastest benchmark programs?".

2- I did not make any claim that programs written in C++ are faster
than programs written in C. I made the claim that in C++ you can have
reusable code, such as containers, without overhead, and you cannot in
C (short of evil preprocessor hackery).

> =A0 and according to
>
> http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
>
> =A0 , C++ has lost half of its market share in relation to C
> =A0 since 2003.
>
> =A0 However, C++ is much more complicated and large than C.
> =A0 Programmers have to learn exception-safe programming, the
> =A0 rule of the three, references, K nig-lookup, soon rvalue
> =A0 references ... up to the point where, AFAIK, the recent
> =A0 draft of the language specification has more than 1000
> =A0 pages, not including the C spec it is based one.
>
> =A0 When the market share continues to decline, C++ will become
> =A0 a legacy language of the 90s.

That is an interesting proposition. However, I want to be clear that
in this thread I have not made any sort of claim that programming in C+
+ is faster, better, results in faster code, in better code, or
whatever.

PS: I may hold those beliefs, but I haven't made those claims in this
thread. :)

On 05/17/11 11:09 AM, William Ahern wrote:
> Ian Collins<ian-news@hotmail.com>  wrote:
>> I'm not saying it's not a lot easier to do generic containers or
>> algorithms with templates.  I'm saying it's impossible to do RAII in C.
>
>> I've often been asked by teams I've managed or coached why they should
>> look at using C++ rather than C and my response normally something along
>> the lines of "what's an automatic, simple means of preventing resource
>> leaks worth to you?"  Then we get onto the other stuff!  One (DSP) team
>> was happy just to use C++ as "C with RAII (and function overloading)".
>
> "Resource Acquisition is Initialization". The primary benefit from RAII is
> ordering resource initializations so that you don't end up with an
> innumerable number of failure combinations, and limiting shared ownership of
> resources, preferable in a strongly hierarchical arrangement. It's not in
> automatic destruction of automatic storage objects, which is comparatively
> more useful in C++ than C because in C++ the exit from a routine could be
> involutary given exceptions.

The presence or lack of exceptions does indeed play a big part in the 
importance of RAII in C++.  But even in their absence, automatic clean 
up does lead to cleaner code and more importantly, greater code reuse. 
By extending RAII into smart pointers, another class of dynamic resource 
management is abstracted away from the user - ownership.

> Proper ordering of resource mangement in C also gets you the majority of
> these benefits, a result not of language features but of good programming
> habits. Comparing poor resource management in C with good resource
> management in C++ is comparing apples to oranges. If programmers were so
> inept at tracking memory anyhow, they'd be best in a GCd environment. If
> they feel the impulse to allocate dynamic strings randomly where ever it
> suits them, then they're begging for leaks, and really should be using a GCd
> language, whether in C or C++. If they properly order allocation of these
> resources, then the gap between C and C++ becomes quite small; maybe not
> small enough, but perhaps for other considerations to move to the forefront.

Yes good practice can also handle these issues, but at the cost of more 
code, more reviews and ultimately, more chance of a hapless maintenance 
programmer inadvertently messing the whole thin up.

Don't forget memory isn't the only dynamic resource that has to be 
managed, so GC only goes part of the way.  Which is one reason most 
(all?)  GC'd languages end up with some form of finalise construct where 
all the code that sits under a goto in C ends up!

> [I'll refrain from commenting on the obscene nested containers example as
> I'm sure it made you cringe as well.]

It did!

-- 
Ian Collins

On May 16, 4:37=A0pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 05/17/11 11:09 AM, William Ahern wrote:
> > [I'll refrain from commenting on the obscene nested containers example =
as
> > I'm sure it made you cringe as well.]
>
> It did!

It's not so obscene if you de-trivialize it - that is make it look
like proper code. Imagine a class that you want as a value of a
std::map, and that value type itself contains a std::vector. Surely
this is a rather common situation. It is for me at least. I wouldn't
write such a typedef. Instead, I would use named types to make clear
the abstractions in use. Ex:

  #include <map>
  #include <string>
  #include <vector>
  using namespace std;
  struct Foo
  { string something;
    string something_else;
    vector<int> and_something_else;
  };
  int main()
  { map<string, Foo> x;
  }

Stefan Ram wrote:

> http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
> 
> , C++ has lost half of its »market share« in relation to C
> since 2003.

I've took a quick peek on how they compiled their data and I don't see how 
it is possible to extract any meaningful result from that index.  
According to the site[1], their test ammounts to nothing more than running 
search queries on programming languages on half dozen sites picked up 
almost at random from a specific site.  To give an example, according to 
their search criteria, they base their evaluation on what programming 
language has a larger market share than some other language on the number 
of search results they get from youtube and facebook.  You take your own 
conclusions from that.


Rui Maciel

[1] http://www.tiobe.com/content/paperinfo/tpci/tpci_definition.htm

Balog Pal wrote:

> Market share? The png's title says "Community index".


And from the description of their accounting method it should read "web 
noise".


Rui Maciel

Krice wrote:

> On 16 touko, 23:11, Rui Maciel <rui.mac...@gmail.com> wrote:
>> Do you know how I can tell you aren't a good programmer?
> 
> I'm the first person in the world who wrote a roguelike with zero
> bugs.
> A thing like that didn't even exist before I made that possible.
> I'm not good, I'm the best.

And the most humble too, to boot.


Rui Maciel

Rui Maciel wrote:

> Stefan Ram wrote:
> 
>> http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
>> 
>> , C++ has lost half of its »market share« in relation to C
>> since 2003.
> 
> I've took a quick peek on how they compiled their data and I don't see
> how it is possible to extract any meaningful result from that index.
> According to the site[1], their test ammounts to nothing more than
> running search queries on programming languages on half dozen sites
> picked up
> almost at random from a specific site.  To give an example, according to
> their search criteria, they base their evaluation on what programming
> language has a larger market share than some other language on the
> number
> of search results they get from youtube and facebook.  You take your own
> conclusions from that.
> 
> 
> Rui Maciel
> 
> [1] http://www.tiobe.com/content/paperinfo/tpci/tpci_definition.htm

As an attempt at an objective evaluation, we can check sourceforge's 
project trove and count the number of projects associated with a given 
programmng language.  We have:

Java	46,457 http://sourceforge.net/softwaremap/?&fq[]=trove%3A198
C++	37,078 http://sourceforge.net/softwaremap/?&fq[]=trove%3A165
PHP	30,193 http://sourceforge.net/softwaremap/?&fq[]=trove%3A183
C	28,204 http://sourceforge.net/softwaremap/?&fq[]=trove%3A164
C#	13,593 http://sourceforge.net/softwaremap/?&fq[]=trove%3A271
Python	13,460 http://sourceforge.net/softwaremap/?&fq[]=trove%3A178
etc etc etc...


Rui Maciel

[1] https://github.com/languages

Rui Maciel <rui.maciel@gmail.com> writes:
>And from the description of their accounting method it should
>read "web noise".

  The curves, however, agree with what I observe elsewhere:

  The rise of Ruby in 2006, the rise of objective C in recent
  years due to products of a certain manufacturer, a gradual
  decline of Perl and so on. Certain, the data /is/ noisy,
  but it cannot be all noise. I would apply some moving
  average filter to the curves to make them more smooth.

  Here is another view from another source:

http://www.google.com/trends?q=C+programming%2CC%2B%2B+programming

  . What do these curves mean? Random noise plus a systematic bias?

Rui Maciel <rui.maciel@gmail.com> writes:
>As an attempt at an objective evaluation, we can check sourceforge's 

  TIOBE at least does not claim that their evaluations was �objective�!
  (Ok, you wrote �an attempt�.)

>project trove and count the number of projects associated with a given 
>programmng language.  We have:

  Still, it is reasonable and helpful to look at the number of
  Sourceforge projects as another source.

On Mon, 16 May 2011 22:58:28 +0000, Stefan Ram wrote:

>   According to
> 
> http://shootout.alioth.debian.org/...
> 
>   C++ is not much faster than C

Actually, it says:

> Which programming languages are fastest?
> 
> No. Which programming language implementations have the fastest
> benchmark programs?

You won't notice the difference between C and C++ until you start looking
at non-trivial programs.

At the lowest level, there isn't really much difference between C and C++.
Some early C++ compilers were little more than preprocessors which
translated C++ to C in a fairly direct manner.

But the abstraction involved in writing a non-trivial program in C tends
to require performance compromises which can often be avoided in C++ by
the use of templates.

>   and according to
> 
> http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
> 
>   , C++ has lost half of its »market share« in relation to C
>   since 2003.

Aside from the fact that those numbers have about as much rigour as
reading tea leaves, that doesn't really surprise me.

At one time, the software development market was split mostly between C
and C++, with "all other languages combined" coming in third place. Since
then, several other languages (e.g. Java, C#) have managed to obtain
critical mass in application development, other programming models (e.g.
web applications) have taken a significant slice of the market, and
computers have gotten faster, meaning that it's more realistic to trade
some amount of efficiency for other factors (reliability, portability,
development cost).

>   However, C++ is much more complicated and large than C.

I don't think you'll find any disagreement there.

>   When the market share continues to decline, C++ will become
>   a legacy language of the 90s.

It won't become a "legacy" language until it stops being a sensible choice
for new code in any context, which will only happen when something else
fills its current niche. That niche will get smaller, due to increasing
hardware performance making software efficiency less critical, but it
isn't going to go away.

You can see the trade-offs at work in the enterprise arena, where Java has
made huge inroads. The increased robustness (from bounds checking, safe
pointers, checked exceptions etc) and reduced development costs (from
having all of C++'s complicated aspects eliminated) more than outweight
the efficiency penalties. When you're writing software for a single
customer, buying faster hardware is cheaper than hiring more programmers
and/or more-experienced programmers.

Conversely, the trade-offs work the other way for game development, where
you're looking to sell tens of millions of copies at tens of dollars per
copy, and want the best possible performance on whatever hardware the user
has.

On Mon, 16 May 2011 23:07:11 +0000, Stefan Ram wrote:

> Ian Collins <ian-news@hotmail.com> writes:
>>I normally just use RAII as the reason.  Everything else else can be 
>>kludged in C, but not RAII.
> 
>   RAII helps to release resources even in the case of exceptions.
>   But C does not have exceptions. So RAII is not needed for this.

C does, however, have (early-) return, break/continue/goto, and longjmp().
All of which create headaches for resource management, i.e. either needing
to add many nearly-identical copies of any clean-up code or just foregoing
the use of any of the above mechanisms.

The basic OOP concepts of objects and classes (with virtual methods) can
be implemented easily enough in C (look at a C GUI toolkit such as Xt or
GTK), but RAII is the point at which you have to decide whether to go to
C++ or go without.

On May 17, 12:07=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Ian Collins <ian-n...@hotmail.com> writes:
> >I normally just use RAII as the reason. =A0Everything else else can be
> >kludged in C, but not RAII.
>
> =A0 RAII helps to release resources even in the case of exceptions.
> =A0 But C does not have exceptions. So RAII is not needed for this.
>
> =A0 RAII helps to do one thing =BBalloc()=AB at block entry and another
> =A0 thing =BBrelease()=AB at block exit. This can be done in C using:
>
> if( a =3D alloc() ){ rest(); release( a ); }.

True, but that idiom doesn't scale terribly elegantly.  To follow the
example given in the article, if you're making a linked list of
dynamically allocated object, and the system runs out of memory on n-
th object then you need to make sure the previous n-1 objects are
correctly deallocated at the error.  In C, that's definitely possible,
but its quite unpleasant - not least because your unwinding code will
likely need to be close to the creation code, which makes your code
harder to read. Also, assuming you're in a function you need some
means to communicate that error up the call-chain, which will usually
mean overloading a special value of an integer return type [which the
calling program will forget to check anyway :)] or setting a global
errno [ditto, and non-reentrant/thread-safe to boot].

RAII and exceptions lets the programmer program the common path
(resources are abundant), and gives automatic error propagation for
failure cases (using a higher level abstraction - which can be handled
at the appropriate logical level).

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>  the rise of objective C in recent
>  years due to products of a certain manufacturer

  You forget that you can write your iPhone programs in Objective C++,
which means that you can write most of it in C++ and only what you must
in C (ie. those parts which need to interact with the Cocoa Touch 
library). You can use full-fledged pure C++ libraries in your program.
(And in fact, if your program is OpenGL ES based rather than Cocoa Touch
based, you can skip writing any Objective C almost completely.)

William Ahern <william@wilbur.25thandclement.com> wrote:
> Proper ordering of resource mangement in C also gets you the majority of
> these benefits, a result not of language features but of good programming
> habits. Comparing poor resource management in C with good resource
> management in C++ is comparing apples to oranges. If programmers were so
> inept at tracking memory anyhow, they'd be best in a GCd environment. If
> they feel the impulse to allocate dynamic strings randomly where ever it
> suits them, then they're begging for leaks, and really should be using a GCd
> language, whether in C or C++. If they properly order allocation of these
> resources, then the gap between C and C++ becomes quite small; maybe not
> small enough, but perhaps for other considerations to move to the forefront.

  You can achieve something similar to C++'s RAII in C within one single
function if you carefully follow certain coding conventions (which, as 
said, are completely unnecessary in C++). The problem is that it's not
at all uncommon that resource handling spans beyond the scope of one
single function.

  In C++ you mostly don't have to worry. Basically, if you never use 
'new' nor pointers in your own code, you are usually on safe grounds, even 
if you are dealing with dynamically allocated memory, and even if you are 
passing objects handling this memory around at will.

  The simplest example is a function returning resources that it allocated 
itself. This immediately breaks encapsulation in C, as it transfers the 
burden of freeing that resource to the caller. Of course you can do this 
in C++ as well, but that would generally be a mistake, as the language 
offers the tools to retain the encapsulation even when the resource 
allocation outlives the function where it was done. Just as a simple 
example:

std::string gimmeTheString()
{
    std::string line;
    std::getline(std::cin, line);
    // Or any other dynamic string building routine you can imagine.

    return line;
}

  Encapsulation is preserved because the calling code doesn't need to 
worry about how the dynamically allocated string will be deleted. When the 
return value goes out of scope, it will be done automatically.

  The lack of RAII in C causes resource management responsibility 
trasferral, and thus breaking encapsulation. The above function equivalent 
in C would require the calling code to be careful about the returned 
string.

  And that was just one of the simplest cases where resource allocation 
can outlive the scope where the allocation was done. It can get 
significantly more complex than that, with deeply nested shared containers 
and other such situations which do happen in practice. The set of 
programming conventions you need for safe code in C++ is significantly 
smaller than the set of programming conventions necessary in C. The more 
complicated the situation, the larger the difference.

  That is one of the main reasons why I would consider it nightmarish if I 
had to develop a large and complex project in C.

  RAII becomes even more important in generic programming. If you want a 
function or class to support more than one data type (regardless of 
whether only one such type will be used at a time in the entire program, 
or whether the same code could be used with several different types within 
the same program), automatic resource management becomes quite essential. 
Basic (non-pointer) types don't need any resource management because they 
can be handled by-value. Structs and classes may need them because they 
may be encapsulating allocated resources within them. However, in C++ you 
don't have to take this into account in your generic code, which is what 
makes it so great.

> [I'll refrain from commenting on the obscene nested containers example as
> I'm sure it made you cringe as well.]

  It was just a one-liner demonstration. It was not intended to be an 
actual real-life example.

  In real code you can, however, end up with deeply nested containers, 
even if more indirectly. Typically you will have a class that has data 
containers as members, and instances of this class may be used in a 
container (which itself might be a member of another class, and so on). 
This isn't even a rare happenstance.

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>  RAII helps to release resources even in the case of exceptions.
>  But C does not have exceptions. So RAII is not needed for this.

  Besides what others responded, I'll like to comment that I have not 
previously heard the argument that "RAII is only needed because of 
exceptions". (Ok, you are not exactly saying that, but it sounds like it.)

  RAII would certainly be exactly as useful even without exceptions. In 
fact, in many compilers you can compile a C++ program without any support 
for exceptions by using a compiler option (naturally it requires that your 
code has no explicit throws). That wouldn't diminish the importance of
RAII in the least bit.

Stefan Ram wrote:

> Rui Maciel <rui.maciel@gmail.com> writes:
>>And from the description of their accounting method it should
>>read "web noise".
> 
>   The curves, however, agree with what I observe elsewhere:
> 
>   The rise of Ruby in 2006, the rise of objective C in recent
>   years due to products of a certain manufacturer, a gradual
>   decline of Perl and so on. Certain, the data /is/ noisy,
>   but it cannot be all noise. I would apply some moving
>   average filter to the curves to make them more smooth.
> 
>   Here is another view from another source:
> 
> http://www.google.com/trends?q=C+programming%2CC%2B%2B+programming
> 
>   . What do these curves mean? Random noise plus a systematic bias?

If you take the time to learn how google trends works[1] you will realize 
that it only measures google search queries and the frequency that the 
topic is covered in google news stories.  So, knowing that, when you run 
some tests you quickly find out that the results are meaningless in terms 
of any attempt to evaluate market share[2].


Rui Maciel


[1] http://www.google.com/intl/en/trends/about.html
[2] 
http://www.google.com/trends?q=Java%2C+C%2B%2B%2C+C%2C+ruby%2C+C%23&ctab=0&geo=all&date=all&sort=0

On May 16, 12:37=A0pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 16/05/2011 17:29, Krice wrote:
>
> > On 16 touko, 18:08, Lynn McGuire<l...@winsim.com> =A0wrote:
> >> "In conclusion, the reason why C is so vastly inferior to C++ as
> >> described in this article can be summarized with one single sentence:
> >> C has no support for RAII nor templates, while C++ does. That's two
> >> of the most important features
>
> > You can live without templates, it's the least important feature
> > of C++ and people constantly over/misuse it. Most important feature
> > is class programming: instances, encapsulation and inheritance,
> > the OOP basics.
>
> I disagree; generic programming is just as important as object oriented
> programming.

Agreed. Generic programming is at least as important and much more
unique to C++ (relative to C) than OOP. Although, I would say that
the C++ automatic constructor/destructor paradigm (which was a C++
innovation as far as I know?) is also extremely valuable. Function
overloading was also a major advance over traditional C.

KHD

gwowen <gwowen@gmail.com> writes:
>example given in the article, if you're making a linked list of
>dynamically allocated object, and the system runs out of memory on n-
>th object then you need to make sure the previous n-1 objects are
>correctly deallocated at the error.  In C, that's definitely possible,
>but its quite unpleasant - not least because your unwinding code will
>likely need to be close to the creation code, which makes your code
>harder to read.

  I think that the unwinding code /should/ be close to the
  creation code, /because/ that will make the whole code
  easier to read. So, in C,

/* Enlarge a list by appending n new entries to it, all of which just 
contain a dummy null pointer for the purpose of this example. 

When it is detected that a new entry cannot be append anymore
(for example due to lack of memory), the entries appended so far
will be removed and the function will return a nonzero value. */

int enlarge_list( list_t * const list, int const n /* precond: i > -1   */ )
{ int result = 1; int i;          /* result == 0 means success          */
  for( i = 0; i < n; ++i )        /* append n new entries to the list   */
  if( list_push( list, 0 ))       /* appends a null pointer to the list */
  break;                          /* break on error to push a new entry */
  if( i < n )list_pop( list, i ); /* clean up by removing all appended  */
  else result = 0;                /* or else set the value for success  */
  return error; }

  (untested.)

Juha Nieminen <nospam@thanks.invalid> writes:
>std::string gimmeTheString()
>{
>    std::string line;
>    std::getline(std::cin, line);
>    // Or any other dynamic string building routine you can imagine.
>
>    return line;
>}
>
>  Encapsulation is preserved because the calling code doesn't need to 
>worry about how the dynamically allocated string will be deleted. When the 
>return value goes out of scope, it will be done automatically.

  This seems to be due to the string being passed by value,
  so that it will be copied?

  But wouldn't it be more efficient to pass such a possibly
  large object by a pointer or reference, which also saves
  time for allocation and deallocation? And when doing so,
  will it still be true that one does not have to worry?

Stefan Ram wrote:

> Juha Nieminen <nospam@thanks.invalid> writes:
>>std::string gimmeTheString()
>>{
>>    std::string line;
>>    std::getline(std::cin, line);
>>    // Or any other dynamic string building routine you can imagine.
>>
>>    return line;
>>}
>>
>>  Encapsulation is preserved because the calling code doesn't need to
>>worry about how the dynamically allocated string will be deleted. When the
>>return value goes out of scope, it will be done automatically.
> 
>   This seems to be due to the string being passed by value,
>   so that it will be copied?
> 
>   But wouldn't it be more efficient to pass such a possibly
>   large object by a pointer or reference, which also saves
>   time for allocation and deallocation? And when doing so,
>   will it still be true that one does not have to worry?

A good std::string implementation _will_ be in terms of a reference/pointer 
for large strings. That's the fantastic thing about it: you don't need to 
bother about those internal details like refcounting. Also return of large 
objects can be implemented with reference semantics.

I suggest you get familiar with the C++ programming language by using it in 
practice. It seems you do not yet 'get' it. You will see that once you 
master RAII you will never want to go back to old-fashioned C.

In article <value-20110517152445@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>Juha Nieminen <nospam@thanks.invalid> writes:
>>std::string gimmeTheString()
>>{
>>    std::string line;
>>    std::getline(std::cin, line);
>>    // Or any other dynamic string building routine you can imagine.
>>
>>    return line;
>>}
>>
>>  Encapsulation is preserved because the calling code doesn't need to 
>>worry about how the dynamically allocated string will be deleted. When the 
>>return value goes out of scope, it will be done automatically.
>
>  This seems to be due to the string being passed by value,
>  so that it will be copied?

No it won't.  Not with any decent compiler.

>  But wouldn't it be more efficient to pass such a possibly
>  large object by a pointer or reference, which also saves
>  time for allocation and deallocation? And when doing so,
>  will it still be true that one does not have to worry?

No, it may even lead to less efficient code in fact.  You need to do a
bit of basic research on the subject.

Measure first, then if you can demonstrate that the natural simple and
elegant way to write the code is too slow, then jump through
hoops. don't do premature optimization... especially when what you
propose could well turn out to be premature pessimization.

Yannick

On 2011-05-17 09:43:00 -0400, Paul Brettschneider said:

> 
> A good std::string implementation _will_ be in terms of a reference/pointer
> for large strings.

i.e. a reference-counted string? No, there was only one commercial 
implementation that did that, and now it's explicitly prohibited 
because of the complications that it introduces in multi-threaded code.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

On May 17, 9:59=A0am, Pete Becker <p...@versatilecoding.com> wrote:
> On 2011-05-17 09:43:00 -0400, Paul Brettschneider said:
>
>
>
> > A good std::string implementation _will_ be in terms of a reference/poi=
nter
> > for large strings.
>
> i.e. a reference-counted string? No, there was only one commercial
> implementation that did that, and now it's explicitly prohibited
> because of the complications that it introduces in multi-threaded code.

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

Reference counted strings (or more generally flyweight patterns
of various kinds) are very useful tools. Just because they don't
interact well with a badly broken model of concurrency is not a
reason to abandon them entirely. You simply don't use said model
of concurrency (yes, believe it or not their are other superior,
for most uses, models) or don't use flyweights together with it.

KHD

Keith H Duggar <duggar@alum.mit.edu> wrote:
> Function
> overloading was also a major advance over traditional C.

  Function overloading is especially important in generic programming.
In fact, many of the things that C++ adds compared to C are valuable
(if not even mandatory) for generic programming.

On May 17, 10:09=A0am, Keith H Duggar <dug...@alum.mit.edu> wrote:
> On May 17, 9:59=A0am, Pete Becker <p...@versatilecoding.com> wrote:
>
> > On 2011-05-17 09:43:00 -0400, Paul Brettschneider said:
>
> > > A good std::string implementation _will_ be in terms of a reference/p=
ointer
> > > for large strings.
>
> > i.e. a reference-counted string? No, there was only one commercial
> > implementation that did that, and now it's explicitly prohibited
> > because of the complications that it introduces in multi-threaded code.
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
>
> Reference counted strings (or more generally flyweight patterns
> of various kinds) are very useful tools. Just because they don't
> interact well with a badly broken model of concurrency is not a
> reason to abandon them entirely. You simply don't use said model
> of concurrency (yes, believe it or not their are other superior,
> for most uses, models) or don't use flyweights together with it.

Oh, I see that you were probably referring specifically and only
to std::string? If so, then my comments probably don't apply. It
certainly might be a good idea for std::string to be as thread
compatible as possible (given the industries unhealthy addiction
to threads).

KHD

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>  This seems to be due to the string being passed by value,
>  so that it will be copied?

  That's not the point. It doesn't matter if the string is returned by
value, or via a reference/pointer given to the function as parameter:
Encapsulation is still maintained and freeing the resource is not
transferred to the calling code.

>  But wouldn't it be more efficient to pass such a possibly
>  large object by a pointer or reference, which also saves
>  time for allocation and deallocation? And when doing so,
>  will it still be true that one does not have to worry?

  In this particular case most compilers will use return value optimization,
which means that the function constructs the return value right on the
caller's stack rather than on its own. Thus the copying will be averted.
(A copy might be triggered in the calling code, depending on the situation
and how the function is being called, but that's another issue.)

  If large containers are being passed by value a lot in the program,
you could implement a copy-on-write wrapper around them. The nice thing
is that the exact method by which the copying is done is inconsequential
in the code that uses it.

Pete Becker wrote:

> On 2011-05-17 09:43:00 -0400, Paul Brettschneider said:
> 
>> 
>> A good std::string implementation _will_ be in terms of a
>> reference/pointer for large strings.
> 
> i.e. a reference-counted string? No, there was only one commercial
> implementation that did that, and now it's explicitly prohibited
> because of the complications that it introduces in multi-threaded code.

Or a unique_ptr kind of thing with move semantics. In any case I would not 
expect a good implementation to copy a long string just for returning it 
from a function. That would be for me a much more serious drawback than 
subpar performance under multi-threaded conditions.

On May 17, 2:17=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> I think that the unwinding code /should/ be close to the
> creation code, /because/ that will make the whole code
> easier to read.

So, enlarge_list returns an error status .. and its caller checks it
and ... then what?

Either the caller must then have its *own* error unwinding code, near
every call site, and it *must* have a return type suitable for
returning the error status of every function it calls, and ... its
elephants all the way down ... and for list_pop() to work, every
container must know exactly how to deallocate its own contained type.

And even then, the list_pop() function needs to know how to safely
deallocate the object types stored in list_t (evening assuming you can
usefully define a single list_t type). That's fine if its int's, less
fine for almost anything else, so say goodbye to lists of list_t's,
etc, etc...

Yes, you *can* fake all these things in C.  You can do them in machine
code too. That doesn't make it a good idea.

gwowen <gwowen@gmail.com> writes:
>So, enlarge_list returns an error status .. and its caller checks it
>and ... then what?

  There can not be a general answer to this. It is the callers
  decision.

>Either the caller must then have its *own* error unwinding code, near
>every call site, and it *must* have a return type suitable for
>returning the error status of every function it calls,

  Well, the details depend on what the caller is intended to do.

  In the code below, for example, return values of functions
  called are coalesced into an own return value. For example,
  to read, sort and print a list using

http://mij.oltrelinux.com/devel/simclist/ 
  
  (this code was not completely tested, it still might
  contain bugs, but one can get the idea):

#include <stdio.h>                   /* scanf, printf */
#include <stdlib.h>                  /* EXIT_SUCCESS  */
#include "simclist-1.4.3/simclist.h" /* list_...      */

int appendvalue( list_t * const list, int *looping )
{ int value;
  if( 1 != scanf( "%d", &value ))return 1;
  if( value >= 0 )
  { if( list_append( list, &value )< 0 )return 2; }
  else *looping = 0; 
  return 0; }

int read( list_t * const list )
{ int looping = 1; while( looping )
  { if( appendvalue( list, &looping ))return 1; }
  return 0; }

int sort( list_t * const list )
{ if( list_attributes_comparator( list, list_comparator_int32_t ))return 1;
  else if( list_sort( list, -1 ))return 2;
  else return 0; }

int print( list_t * const list )
{ if( list_iterator_start( list )<= 0 )
  return 1;
  { while( list_iterator_hasnext( list ))
    { void * next = list_iterator_next( list );
      if( next )
      { if( printf( "%d\n", *( int * )next )< 0 )return 2; }
      else break; }
    if( !list_iterator_stop( list ))return 3; }
  return 0; }

int main2( list_t * const list )
{ if( !list_attributes_copy( list, list_meter_int32_t, 1 ))
  { if( read( list ))return 1;
    else if( sort( list ))return 2;
    { printf("Sorted values:\n");
      if( print( list ))return 3; }}
  return 0; }

int main1( list_t * const list )
{ int result;
  if( list_init( list ))result = 1; 
  else
  { if( main2( list ))result = 2;
    list_destroy( list ); }
  return result; }

int main( void )
{ list_t list;
  return main1( &list )? EXIT_FAILURE : EXIT_SUCCESS; }

"Pete Becker" <pete@versatilecoding.com>
>> A good std::string implementation _will_ be in terms of a 
>> reference/pointer
>> for large strings.
>
> i.e. a reference-counted string? No, there was only one commercial 
> implementation that did that, and now it's explicitly prohibited because 
> of the complications that it introduces in multi-threaded code.

But that applies only to std::string, and caused by its broken public 
interface. A normal string class that is designed to be a stirng, and tuned 
for natural use cases of a string -- instead of ignoring those, but try to 
play a generic container is free to have COW or any other tech. 

"Keith H Duggar" <duggar@alum.mit.edu>
>> > A good std::string implementation _will_ be in terms of a 
>> > reference/pointer
>> > for large strings.
>
>> i.e. a reference-counted string? No, there was only one commercial
>> implementation that did that, and now it's explicitly prohibited
>> because of the complications that it introduces in multi-threaded code.

>http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

>Reference counted strings (or more generally flyweight patterns
>of various kinds) are very useful tools. Just because they don't
>interact well with a badly broken model of concurrency is not a

IIRC the problem was more tied to ignoring 'don't leak your internals' 
principle (especially in innocent-looking functions like operator[] const) 
than concurrency itself.

On May 16, 3:58=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >Take C's sort. The comparator function is a function pointer,
> >and the last I heard is that most compilers simply will not
> >expand that inline, as opposed to C++ various sort functions
> >which can be expanded inline.
>
> =A0 According to
>
> http://shootout.alioth.debian.org/u32/which-programming-languages-are...
>
> =A0 C++ is not much faster than C (the median value actually is
> =A0 a little bit slower than C if I understand the table right),
-snip-


When you're just comparing 2 language implementations the Help page
suggests that you compare them side-by-side

http://shootout.alioth.debian.org/u32/cpp.php

http://shootout.alioth.debian.org/u64/c.php


Also

http://shootout.alioth.debian.org/u64q/c.php

http://shootout.alioth.debian.org/u32q/c.php

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> http://mij.oltrelinux.com/devel/simclist/ 

  For curiosity I examined how that implementation handles the list
elements.

  Overhead (each element of the list makes two allocations rather than one,
one allocation for the node and another for the user data; also comparison
is done via indirect function calls via function pointers, making them
significantly slower than direct element comparisons) and lack of
type safety (everything is handled through void pointers, making it
impossible for the compiler to catch accidental mistakes in types) is to
be expected from a "generic" C implementation.

  (I have always found it quite ironic that C hackers accuse C++ of
introducing needless overhead, when it's usually the exact opposite,
with C having the needless overhead when compared to the equivalent
C++ implementation, especially when talking about generic containers.)

  The most striking problem, however, is summarized by these lines of
code in the library:

        size_t datalen = l->attrs.meter(data);
        lent->data = (struct list_entry_s *)malloc(datalen);
        memcpy(lent->data, data, datalen);

and:

            if (s->data != NULL) free(s->data);

  The library assumes that it can just make a raw bitwise copy of the
element when it needs to create a new node, and simply free the element
when it removes a node. Well, guess if you can make eg. a list of lists
with this (or, for that matter, have as list element a struct that manages
some resource which needs to be release when the struct instantiation is
destroyed).

  Sure, you could add yet another pair of function pointers to the
list_attributes_s struct (ironically adding yet more overhead that a C++
implementation would not require) for copying and destroying the list
elements. Or the coder who is using the list could make sure that the
elements are being finalized before they are removed from the list
(something that is easily error-prone in complicated programs). However,
I think this is a good representation of the natural kind of thinking in C.
Even in code that's supposed to have high encapsulation, encapsulation is
still being broken.

  And btw, there's an error in the webpage. It says:

  "sorting is always O(n logn), without worst case"

  Seeing that it uses quicksort, that's just not true. (Randomizing the
pivot does not make the worst case scenario any better than with vanilla
quicksort.)

On May 17, 3:26=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Rui Maciel <rui.mac...@gmail.com> writes:
> >As an attempt at an objective evaluation, we can check sourceforge's
>
> =A0 TIOBE at least does not claim that their evaluations was =BBobjective=
=AB!
> =A0 (Ok, you wrote =BBan attempt=AB.)
>
> >project trove and count the number of projects associated with a given
> >programmng language. =A0We have:
>
> =A0 Still, it is reasonable and helpful to look at the number of
> =A0 Sourceforge projects as another source.

On that level better take stackoverflow questions. There are about 26k
questions tagged C, 64k questions tagged C++ and 7k tagged both.

On May 17, 8:12=A0pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
> On May 17, 3:26=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> > Rui Maciel <rui.mac...@gmail.com> writes:
> > >As an attempt at an objective evaluation, we can check sourceforge's
>
> > =A0 TIOBE at least does not claim that their evaluations was =BBobjecti=
ve=AB!
> > =A0 (Ok, you wrote =BBan attempt=AB.)
>
> > >project trove and count the number of projects associated with a given
> > >programmng language. =A0We have:
>
> > =A0 Still, it is reasonable and helpful to look at the number of
> > =A0 Sourceforge projects as another source.
>
> On that level better take stackoverflow questions. There are about 26k
> questions tagged C, 64k questions tagged C++ and 7k tagged both.

The beauty of C is the elegance of its simplicity. It is a very simple
language and can be learned in a day. Yet it allows one to build
complex
programs with optimal performance.

The beauty of C++ on the other hand is its extensive support in the
language itself, its libraries and idioms to address the scalability
issues in large programs. There are solid, well described mechanisms
like user defined types, polymorphism, namespaces, exceptions,
templates, RAII, STL, function overloading, etc, etc, for problems
that can be solved by user code in C. The strength of the C solutions
will vary with the programmer, the C++ equivalents are well defined.

Of course there are more questions about C++ then about C, the C++
language is much larger because it addresses many software
development issues that C doesn't. The investment of learning C++
probably only pays of when you use it in mid to large scale software
projects, that also need its C style performance characteristics. If
you happen to know C++ quite well, it is great for small programs
too :-)

Gert-Jan

Öö Tiib wrote:

> On that level better take stackoverflow questions. There are about 26k
> questions tagged C, 64k questions tagged C++ and 7k tagged both.

As C++ tends to be much more complex and as C tends to be "tamed" after 
getting the hang of it's core language, naturally there is a tendency for 
forum dedicated to C++ to end up generating more traffic than the C 
counterpart.  Therefore, the traffic generated by these languages on a 
specific forum may not be that correlated with their market share.


Rui Maciel

Ian Collins wrote:

> On 05/17/11 08:21 AM, Rui Maciel wrote:
>> Balog Pal wrote:
>>
>>> Quite so. Another "most important" feature was parting with "locals at
>>> block start", but it got into C99 in the mantime.  (too bad that
>>> real-world C is still at C90, a decade+ after the last revision, and
>>> massive projects still stick to that old known bug generator. :( )
>>
>> What do you mean by "real-world C is still at C90"?
> 
> C99 compilers are by no means universal.  A lot of embedded (the
> majority of C projects) projects are still stuck with C90 tools.
> 

You have a point.


Rui Maciel

> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."

In the old days, C++ codes were first converted to C by preprocessor! ;)

-- 
   @~@   Might, Courage, Vision, SINCERITY.
  / v \  Simplicity is Beauty! May the Force and farces be with you!
/( _ )\ (x86_64 Ubuntu 9.10)  Linux 2.6.38.6
   ^ ^   15:34:01 up 6 days 9:06 0 users load average: 1.15 1.13 1.14
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

On May 18, 12:38=A0am, Man-wai Chang <toylet.toy...@gmail.com> wrote:
> In the old days, C++ codes were first converted to C by preprocessor! ;)

No. Cfront did full semantic analysis. It is a compiler.

On May 18, 2:10=A0am, Rui Maciel <rui.mac...@gmail.com> wrote:
> =D6=F6 Tiib wrote:
> > On that level better take stackoverflow questions. There are about 26k
> > questions tagged C, 64k questions tagged C++ and 7k tagged both.
>
> As C++ tends to be much more complex and as C tends to be "tamed" after
> getting the hang of it's core language, naturally there is a tendency for
> forum dedicated to C++ to end up generating more traffic than the C
> counterpart. =A0Therefore, the traffic generated by these languages on a
> specific forum may not be that correlated with their market share.

Most of the questions there are not about language (some always are
indeed lazy student homework questions) but practical questions about
operating systems, network services, libraries, algorithms,
frameworks, protocols or tools. People usually try to solve everyday
practical problems. For language itself they have manual or couple. I
think people tag with language they use so to not get some Python or
Visual Basic code example (or link) as response.

Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl> wrote:
> The beauty of C is the elegance of its simplicity. It is a very simple
> language and can be learned in a day.

  You can't be serious.

  The brevity of the language specification does not equate to the
simplicity of the language, and C is a prime example of this.

  The simplicity of the language is measured by how complicated it is
to implement a given task with the language, not how long the the language
specification is. If that were the measurement, then brainfuck would be
much simpler than C. It certainly isn't.

  In the case of C, its "simplicity" actually becomes a limiting factor,
not a beneficial one. The language offers no tools that would help writing
simple programs. Even small tasks can become overly complicated, 
especially if dynamic memory management and data structures other than
basic arrays are involved.

  As for "learning C in a day", you are quite a joker. There are people
who don't fully understand things like pointer arithmetic even after a
year of coding in C.

On 5/18/2011 11:37 AM, Juha Nieminen wrote:
> Gert-Jan de Vos<gert-jan.de.vos@onsneteindhoven.nl>  wrote:
>> The beauty of C is the elegance of its simplicity. It is a very simple
>> language and can be learned in a day.
>
>    You can't be serious.
>
>    The brevity of the language specification does not equate to the
> simplicity of the language, and C is a prime example of this.
>
>    The simplicity of the language is measured by how complicated it is
> to implement a given task with the language, not how long the the language
> specification is. If that were the measurement, then brainfuck would be
> much simpler than C. It certainly isn't.
>
>    In the case of C, its "simplicity" actually becomes a limiting factor,
> not a beneficial one. The language offers no tools that would help writing
> simple programs. Even small tasks can become overly complicated,
> especially if dynamic memory management and data structures other than
> basic arrays are involved.
>
>    As for "learning C in a day", you are quite a joker. There are people
> who don't fully understand things like pointer arithmetic even after a
> year of coding in C.

No joke.  I have known several C programmers who did not get
the concept of pointers even after several years.  Needless
to say, they were not great programmers.

Lynn

Le 16/05/11 17:08, Lynn McGuire a �crit :
> Why C++ is vastly superior to C:
> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."
>
> Lynn

Of course C++ is vastly superior than C.

We are in comp.lang.c++. Nobody will say otherwise.

:-)

jacob navia <jacob@spamsink.net> writes:
> Of course C++ is vastly superior than C.
>
> We are in comp.lang.c++. Nobody will say otherwise.

Hm, well there's always Paul... :]

-miles

-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lynn McGuire wrote:

> Why C++ is vastly superior to C:
>      http://warp.povusers.org/programming/cplusplus_superior_to_c.html
> 
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."


Even after 5 years of programming, I still seldom use inheritance. However, 
I've coded lots of templates. The only use of inheritance by me until now is 
in GUI programming, where everything can be represented in a class hierarchy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3VDH4ACgkQZ1Turg5KUCnQmgCfba51u5iSDZyoKjvHAQfUU+j5
L0IAmgMJak4VzIdcOOoW5x1HY8fVz9Kl
=q5Il
-----END PGP SIGNATURE-----

On 18 touko, 20:55, jacob navia <ja...@spamsink.net> wrote:
> Of course C++ is vastly superior than C.

The best proof is that C people say they can do everything
that C++ does in C. It tells that they need and love C++
features so much that they try to replicate them in C.

In article <ir0u80$hce$1@dont-email.me>, Lynn McGuire  <lmc@winsim.com> wrote:
>On 5/18/2011 11:37 AM, Juha Nieminen wrote:
>> Gert-Jan de Vos<gert-jan.de.vos@onsneteindhoven.nl>  wrote:
>>> The beauty of C is the elegance of its simplicity. It is a very simple
>>> language and can be learned in a day.
>>
>>    You can't be serious.
>>
>>    The brevity of the language specification does not equate to the
>> simplicity of the language, and C is a prime example of this.
>>
>>    The simplicity of the language is measured by how complicated it is
>> to implement a given task with the language, not how long the the language
>> specification is. If that were the measurement, then brainfuck would be
>> much simpler than C. It certainly isn't.
>>
>>    In the case of C, its "simplicity" actually becomes a limiting factor,
>> not a beneficial one. The language offers no tools that would help writing
>> simple programs. Even small tasks can become overly complicated,
>> especially if dynamic memory management and data structures other than
>> basic arrays are involved.
>>
>>    As for "learning C in a day", you are quite a joker. There are people
>> who don't fully understand things like pointer arithmetic even after a
>> year of coding in C.
>
>No joke.  I have known several C programmers who did not get
>the concept of pointers even after several years.  Needless
>to say, they were not great programmers.

Yup, I was once asked to look at a bug that was traced to receiving
the value of a pointer sent through a TCP socket from a different
device! Then you go and talk to the programmer and instead of
apologising and immediately noticing that he forgot to serialise the
data, he looks at you all confused with no understanding of why it is
a problem!

On May 20, 10:46=A0am, Krice <pau...@mbnet.fi> wrote:
> On 18 touko, 20:55, jacob navia <ja...@spamsink.net> wrote:
>
> > Of course C++ is vastly superior than C.
>
> The best proof is that C people say they can do everything
> that C++ does in C.

The converse is also true ... and considerably more straightforward.

Michael Tsang wrote:

> Even after 5 years of programming, I still seldom use inheritance.
> However, I've coded lots of templates. The only use of inheritance by me
> until now is in GUI programming, where everything can be represented in
> a class hierarchy.

Are you familiar with basic OO design patterns?


Rui Maciel

Krice wrote:

> You can live without templates,

But your quality of life would suffer greatly as a result.

> it's the least important feature

I disagree. In the set of mostly touted C++ features, I think exceptions 
are the least important.

Lynn McGuire wrote:
> On 5/16/2011 11:29 AM, Krice wrote:
>> On 16 touko, 18:08, Lynn McGuire<l...@winsim.com>  wrote:
>>> "In conclusion, the reason why C is so vastly inferior to C++ as
>>> described in this article can be summarized with one single
>>> sentence: C has no support for RAII nor templates, while C++ does.
>>> That's two of the most important features
>>
>> You can live without templates, it's the least important feature
>> of C++ and people constantly over/misuse it. Most important feature
>> is class programming: instances, encapsulation and inheritance,
>> the OOP basics.
>
> I could not live without the Standard Template Library.

I can't live with it. 

Rui Maciel wrote:
> Krice wrote:
>
>> Mostly because core C++ doesn't have something like std::string
>> or vector.
>
> Why would anyone extend the base language to incorporate something
> which is easily implemented (and, better yet, extendable) through
> other basic language constructs?
>

In attempt to achieve greater interoperability amongst programmers? 

Joshua Maurice wrote:

> I want to emphasize this. Templates are nice for code reuse, but
> several posters ignored IMHO the most important aspect of their
> utility. Templates allow generic code and code reuse without runtime
> overhead.

The trade-off (there always is one) being Template Code Bloat (TCB).

Stefan Ram wrote:

> http://www.tiobe.com/content/paperinfo/tpci/images/tpci_trends.png
>
>  , C++ has lost half of its �market share� in relation to C
>  since 2003.
>

Surely because of C#. Where Java couldn't really dent C++, C# (combined 
with .Net) is coming on strong. (I find C# rather useless though because 
programs written in it can be so easily reverse-engineered". Download 
Reflector and the details of the code in all its glory are revealed). 

Ian Collins wrote:
> On 05/17/11 10:58 AM, Stefan Ram wrote:

>>    However, C++ is much more complicated and large than C.
>>    Programmers have to learn exception-safe programming, the
>>    rule of the three, references, K�nig-lookup, soon rvalue
>>    references ...
>
> No, they don't.  They may have to if they are supporting legacy code
> that uses every feature under the sun (which tends to be written by
> novices keen to use them!).  For new projects, they can choose a
> subset they are happy with.

Not really. The idioms have evolved for very good reasons. Not knowing 
how to write exception-safe code, for example, is indeed to not know how 
to program in C++, for writing unreliable software is not really doing 
much of anything but playing.

>
>>    up to the point where, AFAIK, the recent
>>    draft of the language specification has more than 1000
>>    pages, not including the C spec it is based one.
>
> The complexity of any given problem is constant.  Whether that
> complexity is hidden in a language or exposed user code is a choice.
> Most of the new features will remove complexity from user code.

Two things (there surely are more, and will be more, but just off the top 
of my head) that I appreciate from the new features and have helped me 
are:

1. 'auto': I now have for_each, yay!
2. That namespace-within-a-class-hierarchy-thing. Yay! No more virtual 
derivation to get around the diamond inheritance problem.

Rui Maciel wrote:

> As an attempt at an objective evaluation, we can check sourceforge's
> project trove and count the number of projects associated with a given
> programmng language.  We have:
>
> Java 46,457 http://sourceforge.net/softwaremap/?&fq[]=trove%3A198
> C++ 37,078 http://sourceforge.net/softwaremap/?&fq[]=trove%3A165
> PHP 30,193 http://sourceforge.net/softwaremap/?&fq[]=trove%3A183
> C 28,204 http://sourceforge.net/softwaremap/?&fq[]=trove%3A164
> C# 13,593 http://sourceforge.net/softwaremap/?&fq[]=trove%3A271
> Python 13,460 http://sourceforge.net/softwaremap/?&fq[]=trove%3A178
> etc etc etc...
>

How many are new? How many are active? How many users? What are the 
trends in the last year or 2? (All rhetorical questions). Your attempt at 
objectivity seems rather lame. 

Gert-Jan de Vos wrote:

> The beauty of C is the elegance of its simplicity. It is a very simple
> language and can be learned in a day. Yet it allows one to build
> complex
> programs with optimal performance.

"beauty", "elegance" in the same sentence as "C" is surely oxymoronic.

>
> The beauty of C++

Similarly, on "beauty and C++": "A face only a mother could love", for 
sure. (I wouldn't go as far as to call it butt-ugly though).

> The investment of learning C++
> probably only pays of when you use it in mid to large scale software
> projects, that also need its C style performance characteristics.

"probably" may be the key word in that sentence. I noted in another post 
that I find C# defficient because of its ease-of-reverse-engineering 
"flaw".

> If
> you happen to know C++ quite well, it is great for small programs
> too :-)
>

I had been using C# for the past few weeks and was going to actually 
write a useful program in it, but in the end I wrote-off what I was doing 
with it as an investigation into the language and am now back to writing 
that same program in C++. So I'm one of those you mention in your 
sentence above that will even do the "quick hacks" in C++ because I 
already know it well. 

Juha Nieminen wrote:

>  The simplicity of the language is measured by how complicated it is
> to implement a given task with the language, not how long the the
> language specification is. If that were the measurement, then
> brainfuck would be much simpler than C. It certainly isn't.

It is neither. It is both and more. If a language is simple to implement, 
i.e., write a compiler for, then that is indeed a measure of 
"simplicity". Another equally valid (perhaps to a different group) 
measure of simplicity is "simplicity of usage".

>
>  In the case of C, its "simplicity" actually becomes a limiting
> factor, not a beneficial one. The language offers no tools that would
> help writing simple programs. Even small tasks can become overly
> complicated, especially if dynamic memory management and data
> structures other than basic arrays are involved.

The assumption is though that after years of use, one's toolbox will be 
chock-full of useful tools, idioms, etc. Indeed, I forego many of the C++ 
"built-in" offerings for ones that I craft myself. The focus on 
large-scale development and million-line programs is way over-done. Using 
the heavy-lifting equipment on small jobs is many times a burden.

Nobody wrote:
> On Mon, 16 May 2011 22:58:28 +0000, Stefan Ram wrote:
>
>>   According to
>>
>> http://shootout.alioth.debian.org/...
>>
>>   C++ is not much faster than C
>
> Actually, it says:
>
>> Which programming languages are fastest?
>>
>> No. Which programming language implementations have the fastest
>> benchmark programs?
>
> You won't notice the difference between C and C++ until you start
> looking at non-trivial programs.

And I'll add that one won't notice until one starts thinking in terms of 
higher-level abstraction(s) and not solely in terms of bits and bytes. 
C++ will ween one away from the bits-n-bytes and on to bigger and better 
things.

Keith H Duggar wrote:

> [...] I would say that
> the C++ automatic constructor/destructor paradigm (which was a C++
> innovation as far as I know?) is also extremely valuable.

Innovation? Looks like a quite nice and convenient side-effect. 

Keith H Duggar wrote:
> On May 17, 9:59 am, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2011-05-17 09:43:00 -0400, Paul Brettschneider said:
>>
>>
>>
>>> A good std::string implementation _will_ be in terms of a
>>> reference/pointer for large strings.
>>
>> i.e. a reference-counted string? No, there was only one commercial
>> implementation that did that, and now it's explicitly prohibited
>> because of the complications that it introduces in multi-threaded
>> code.
>
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
>
> Reference counted strings (or more generally flyweight patterns
> of various kinds) are very useful tools. Just because they don't
> interact well with a badly broken model of concurrency is not a
> reason to abandon them entirely. You simply don't use said model
> of concurrency (yes, believe it or not their are other superior,
> for most uses, models) or don't use flyweights together with it.
>

Immutable strings and reference counting works out quite nicely, e.g. 

Nobody wrote:
> On Mon, 16 May 2011 23:07:11 +0000, Stefan Ram wrote:
>
>> Ian Collins <ian-news@hotmail.com> writes:
>>> I normally just use RAII as the reason.  Everything else else can be
>>> kludged in C, but not RAII.
>>
>>   RAII helps to release resources even in the case of exceptions.
>>   But C does not have exceptions. So RAII is not needed for this.
>
> C does, however, have (early-) return, break/continue/goto, and
> longjmp(). All of which create headaches for resource management,
> i.e. either needing to add many nearly-identical copies of any
> clean-up code or just foregoing the use of any of the above
> mechanisms.
>
> The basic OOP concepts of objects and classes (with virtual methods)
> can be implemented easily enough in C (look at a C GUI toolkit such
> as Xt or GTK), but RAII is the point at which you have to decide
> whether to go to C++ or go without.

That seems like a juxtaposed statement, for it is C++ exceptions that 
instigate the NEED for the RAII idiom. Without exceptions, RAII is merely 
a convenience (still nice, but not important/necessary). 

Juha Nieminen wrote:
> Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>  RAII helps to release resources even in the case of exceptions.
>>  But C does not have exceptions. So RAII is not needed for this.
>
>  Besides what others responded, I'll like to comment that I have not
> previously heard the argument that "RAII is only needed because of
> exceptions". (Ok, you are not exactly saying that, but it sounds like
> it.)
>
>  RAII would certainly be exactly as useful even without exceptions. In
> fact, in many compilers you can compile a C++ program without any
> support for exceptions by using a compiler option (naturally it
> requires that your code has no explicit throws). That wouldn't
> diminish the importance of RAII in the least bit.

It indeed would diminish all of it's importance because the idiom becomes 
just a convenience and not a necessity. 

jacob navia wrote:
> Le 16/05/11 17:08, Lynn McGuire a �crit :
>> Why C++ is vastly superior to C:
>> http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>>
>> "In conclusion, the reason why C is so vastly inferior to C++ as
>> described in this article can be summarized with one single sentence:
>> C has no support for RAII nor templates, while C++ does. That's two
>> of the most important features that make C++ by far the superior
>> language."
>>
>> Lynn
>
> Of course C++ is vastly superior than C.
>
> We are in comp.lang.c++. Nobody will say otherwise.
>
> :-)

Your point being that people who live in houses with conveniences like 
indoor plumbing and electricity simply don't understand how simple living 
in caves is so much better? Even though most of these people used to be 
cave-dwellers? ;-) 

On May 20, 9:43=A0pm, "MikeP" <mp011...@some.org> wrote:
> Joshua Maurice wrote:
> > I want to emphasize this. Templates are nice for code reuse, but
> > several posters ignored IMHO the most important aspect of their
> > utility. Templates allow generic code and code reuse without runtime
> > overhead.
>
> The trade-off (there always is one) being Template Code Bloat (TCB).

I laughed when I saw your acronym. I assume that was just made up on
the spot.

The point is, C++ programmers can choose between "The C way"(tm) and
templates. C people are stuck with one side of the tradeoff. I don't
think you're disagreeing, but I'm just being contrarian to your
contrarian.

On Sat, 21 May 2011 01:14:09 -0500, MikeP wrote:

>> The basic OOP concepts of objects and classes (with virtual methods)
>> can be implemented easily enough in C (look at a C GUI toolkit such
>> as Xt or GTK), but RAII is the point at which you have to decide
>> whether to go to C++ or go without.
> 
> That seems like a juxtaposed statement, for it is C++ exceptions that 
> instigate the NEED for the RAII idiom.

C exceptions (i.e. longjmp) also require it.

> Without exceptions, RAII is merely a convenience (still nice, but not
> important/necessary). 

I suppose it depends upon whether legibility is important/necessary or
merely a convenience. The contortions required to get by without it can be
pretty ugly. Similarly, one could ask whether high-level languages are
important/necessary, or merely a convenience.

On May 20, 11:14=A0pm, "MikeP" <mp011...@some.org> wrote:
> That seems like a juxtaposed statement, for it is C++ exceptions that
> instigate the NEED for the RAII idiom. Without exceptions, RAII is merely
> a convenience (still nice, but not important/necessary).

That's a matter of opinion.

The first thing that Bjarne Stroustrup added to C to make C++ was
destructors, more or less. In his own words in this forum, it predated
all the other cool things, like templates, virtual, exceptions, by
years. I agree with Bjarne that the thing I miss the most when I'm
forced to do C, or maintain C-like C++ code, is destructors.

The utility of destructors is not mere syntactic sugar like a ranged-
based for loop ala Java and C++0x or even the virtual keyword.
Implicit calling of functions when objects leave scope is incredibly
"powerful" and useful. It greatly reduces a whole class of programming
errors. It does this IMHO in two main ways. First it helps the
programmer not forget to add a free-resource call to a deinit call
(now also usually a destructor), and helps the programmer not forget a
free-resource call (now also usually a destructor) on an exit path in
a function.

Second, it helps foster a certain kind of programming paradigm where
the coder ensures that all resources have an owner at all times. Most
of the time, that is except for the occasional no-throw block or no-
throw operation which transfers ownership or allocates a resource, you
can unwind the stack at any time and you will not leak resources -
required with exceptions, but still useful otherwise. When all
resources have a clearly identified owner (and thus destruction
condition), and the ownership graph in large part has all of its roots
in stack objects, leaks become much rarer, especially with the
idiomatic usage.

I'm not sure what this example is worth, but here it is.

In my little make replacement that I wrote and play around with in my
spare time, I have a grand total of 13 actual "delete"s (and no frees,
etc.). 11149 lines of code, for whatever that silly measurement is
worth.

Once I get C++0x std::function, take off 2. If I had a
std::auto_array, take off 2 more. (Dealing with C interfaces.) Another
2 for dealing with other misc C interfaces. If I had a
std::vector<T*>, std::set<T*>, std::map<---, T*> that owned its
contained pointers, scratch another 4. The last 3 are some hacky
stuffs that I'm doing with "delete this;". (Speaking of that, I should
refactor that to be more sane. Not sure what I was thinking.)

All of the deletes appear in destructors, or they are early deletes
that a later delete in a destructor would catch anyway. I have a /
tolerable/ measure of certainty that my code is leak free, at least
much better than I would have if it was C-style.

MikeP <mp011011@some.org> wrote:
> Juha Nieminen wrote:
> 
>>  The simplicity of the language is measured by how complicated it is
>> to implement a given task with the language, not how long the the
>> language specification is. If that were the measurement, then
>> brainfuck would be much simpler than C. It certainly isn't.
> 
> It is neither. It is both and more. If a language is simple to implement, 
> i.e., write a compiler for, then that is indeed a measure of 
> "simplicity". Another equally valid (perhaps to a different group) 
> measure of simplicity is "simplicity of usage".

  The point is that C advocates try to ride on the concept of language
simplicity. With other languages simplicity means not only that the
language specification is relatively short, but also that writing
programs is simple and straightforward (because, among other things,
the programmer is not burdened by memory management and other similar
issues). The simplicity of the language directly correlates to how much
you have to write in order to implement a given task, and how much of
what you write is directly related to the task itself (rather than to
ancillary things like memory management). Also, how easy it is to
understand the code.

  C advocates commit a fallacy of equivocation here. They pretend that
the brevity of the language specification equates to simplicity. That's
not what is meant by simplicity when talking about programming languages.
If you need to write 200 lines of code for something that can be done in
20 lines of (clear and easy-to-understand) code in another language, that's
not "simplicity". That's the exact opposite.

  In C the brevity of the language specification actually becomes a
hindrance because of the lack of standard tools for common tasks. This
burdens the programmer with useless work that must be repeated over and
over.

  I'm not saying C++ is a "simple" language. However, it is, by this
definition, *simpler* than C.

>>  In the case of C, its "simplicity" actually becomes a limiting
>> factor, not a beneficial one. The language offers no tools that would
>> help writing simple programs. Even small tasks can become overly
>> complicated, especially if dynamic memory management and data
>> structures other than basic arrays are involved.
> 
> The assumption is though that after years of use, one's toolbox will be 
> chock-full of useful tools, idioms, etc.

  There are, of course two problems with that:

1) It's not standard, and hence if you need to do a project somewhere where
you don't have your toolset, you'll have to start from scratch. Also, it
doesn't help others to understand your code if they haven't used the same
toolset.

2) Most generic tools you could write in C are harder and less safe to
use (compared to most other languages, including C++). Typically the
more generic the library, the less efficiency, type safety and usability.

> Indeed, I forego many of the C++ 
> "built-in" offerings for ones that I craft myself.

  If you use your own tool instead of a standard tool even in situations
where the standard tool would be perfectly suited, that's not very smart.

MikeP <mp011011@some.org> wrote:
> Joshua Maurice wrote:
> 
>> I want to emphasize this. Templates are nice for code reuse, but
>> several posters ignored IMHO the most important aspect of their
>> utility. Templates allow generic code and code reuse without runtime
>> overhead.
> 
> The trade-off (there always is one) being Template Code Bloat (TCB).

  What's that, exactly?

MikeP <mp011011@some.org> wrote:
> That seems like a juxtaposed statement, for it is C++ exceptions that 
> instigate the NEED for the RAII idiom. Without exceptions, RAII is merely 
> a convenience (still nice, but not important/necessary). 

  I don't understand where this notion is coming from.

  Even if exceptions were disabled (in many compilers you can disable them
so that they will never be thrown) it would still be a nightmare to develop
a large project without RAII.

  I would say the opposite of you: RAII is essential. The fact that it
allows making code exception-safe is a nice side-effect, but not the main
point.

MikeP wrote:

> Your point being that people who live in houses with conveniences like
> indoor plumbing and electricity simply don't understand how simple
> living in caves is so much better? Even though most of these people used
> to be cave-dwellers? ;-)

I don't believe that the differences between C++ and C are equivalent to 
the differences between a house with indoor plumbing and electricity and a 
cave.  I see it more as the difference between a house fully stocked with 
a hefty set of conveniences and features such as home automation, HVAC and 
even HAL from 2001: A Space Odyssey, and the exact same house with barely 
any furniture and stripped of any of those bells and wistles.  Both are 
good houses, you can live confortably in any of those but in some cases 
you don't have those gadgets helping you/constantly getting on your way.


Rui Maciel

MikeP wrote:

> How many are new? How many are active? How many users? What are the
> trends in the last year or 2? (All rhetorical questions). 

If you really wish to know that then all you have to do is put in the leg 
work and check it for yourself.  Why did you failed to do that and instead 
opted to simply whine?


> Your attempt at objectivity seems rather lame.

You can whine about anything you wish, really.  The fact is, I've 
criticized an attempt at evaluating the market share of a set of languages 
and, to complement that, I've provided a more objective, quantitative way 
to evaluate that.  You, on the other hand, threw a set of questions to 
which, as a demonstration on how relevant you think they are, you don't 
even want to get the answer to and, based on that silly permisse, went 
forward to bitch about how "lame" this source of data was.  

So, if you really want to discuss how "lame" a source of data is then at 
the very least provide any data which you believe is better than this.  
Until that, tone down your "lame" posts.


Rui Maciel

MikeP wrote:

> In attempt to achieve greater interoperability amongst programmers?

Why do you believe that using std::string hinders "interoperability 
amongst programmers"?


Rui Maciel

Rui Maciel wrote:
> MikeP wrote:
>
>> In attempt to achieve greater interoperability amongst programmers?
>
> Why do you believe that using std::string hinders "interoperability
> amongst programmers"?
>

Just the opposite. Maybe I misunderstood the other post. 

Juha Nieminen wrote:
> MikeP <mp011011@some.org> wrote:
>> Juha Nieminen wrote:
>>
>>>  The simplicity of the language is measured by how complicated it is
>>> to implement a given task with the language, not how long the the
>>> language specification is. If that were the measurement, then
>>> brainfuck would be much simpler than C. It certainly isn't.
>>
>> It is neither. It is both and more. If a language is simple to
>> implement, i.e., write a compiler for, then that is indeed a measure
>> of "simplicity". Another equally valid (perhaps to a different group)
>> measure of simplicity is "simplicity of usage".

>  I'm not saying C++ is a "simple" language. However, it is, by this
> definition, *simpler* than C.
>

I was just noting the obvious: that "simplicity" requires more context to 
be meaningful and that it is subjective. I only posted because you used 
such absolute wording ("simplicity means...") when it can mean different 
things to different people.


>>>  In the case of C, its "simplicity" actually becomes a limiting
>>> factor, not a beneficial one. The language offers no tools that
>>> would help writing simple programs. Even small tasks can become
>>> overly complicated, especially if dynamic memory management and data
>>> structures other than basic arrays are involved.
>>
>> The assumption is though that after years of use, one's toolbox will
>> be chock-full of useful tools, idioms, etc.
>
>  There are, of course two problems with that:
>
> 1) It's not standard, and hence if you need to do a project somewhere
> where you don't have your toolset, you'll have to start from scratch.
> Also, it doesn't help others to understand your code if they haven't
> used the same toolset.

That's only a problem for that scenario, not a problem in general.

>
> 2) Most generic tools you could write in C are harder and less safe to
> use (compared to most other languages, including C++). Typically the
> more generic the library, the less efficiency, type safety and
> usability.

Agreed. But that is just another day in the life of a C programmer, and 
that is the way it used to be done way back in the 18th century. :-)

>
>> Indeed, I forego many of the C++
>> "built-in" offerings for ones that I craft myself.
>
>  If you use your own tool instead of a standard tool even in
> situations where the standard tool would be perfectly suited, that's
> not very smart.

Opinions vary. I note that you are an "in the paint" kind of guy: 
"standards this... standards that". To each their own is what I say. 

Rui Maciel wrote:
> MikeP wrote:
>
>> How many are new? How many are active? How many users? What are the
>> trends in the last year or 2? (All rhetorical questions).
>
> If you really wish to know that then all you have to do is put in the
> leg work and check it for yourself.  Why did you failed to do that
> and instead opted to simply whine?

Look up the word 'rhetorical'.

>
>
>> Your attempt at objectivity seems rather lame.
>
> You can whine about anything you wish, really.  The fact is, I've
> criticized an attempt at evaluating the market share of a set of
> languages and, to complement that, I've provided a more objective,
> quantitative way to evaluate that.

I noted that the attempt was a lame one and posted a few RHETORICAL 
questions to get you to think about why I said it was a lame attempt.

>  You, on the other hand, threw a
> set of questions to which, as a demonstration on how relevant you
> think they are, you don't even want to get the answer to and, based
> on that silly permisse, went forward to bitch about how "lame" this
> source of data was.

I didn't suggest that the source of the data was lame, but rather that 
the poster's suggestion that what he posted was somehow meaningful and 
indicative as it stands is simply not true.

>
> So, if you really want to discuss how "lame" a source of data is then
> at the very least provide any data which you believe is better than
> this. Until that, tone down your "lame" posts.
>

A bit sensitive are ya? 

Joshua Maurice wrote:
> On May 20, 9:43 pm, "MikeP" <mp011...@some.org> wrote:
>> Joshua Maurice wrote:
>>> I want to emphasize this. Templates are nice for code reuse, but
>>> several posters ignored IMHO the most important aspect of their
>>> utility. Templates allow generic code and code reuse without runtime
>>> overhead.
>>
>> The trade-off (there always is one) being Template Code Bloat (TCB).
>
> I laughed when I saw your acronym. I assume that was just made up on
> the spot.
>

I've used it in source code before to document stuff. It's a relevant 
issue so it probably needs an acronym.

> The point is, C++ programmers can choose between "The C way"(tm) and
> templates. C people are stuck with one side of the tradeoff. I don't
> think you're disagreeing, but I'm just being contrarian to your
> contrarian.

I was just pointing out that nothing is free. Usually in coding there is 
a space-time tradeoff and that's exactly what you get with templates vs. 
void*. 

Juha Nieminen wrote:
> MikeP <mp011011@some.org> wrote:
>> Joshua Maurice wrote:
>>
>>> I want to emphasize this. Templates are nice for code reuse, but
>>> several posters ignored IMHO the most important aspect of their
>>> utility. Templates allow generic code and code reuse without runtime
>>> overhead.
>>
>> The trade-off (there always is one) being Template Code Bloat (TCB).
>
>  What's that, exactly?

Type "template code bloat" or "C++ template code bloat" into your 
favorite internet search engine and you'll get a long listing. 

Nobody wrote:
> On Sat, 21 May 2011 01:14:09 -0500, MikeP wrote:
>
>>> The basic OOP concepts of objects and classes (with virtual methods)
>>> can be implemented easily enough in C (look at a C GUI toolkit such
>>> as Xt or GTK), but RAII is the point at which you have to decide
>>> whether to go to C++ or go without.
>>
>> That seems like a juxtaposed statement, for it is C++ exceptions that
>> instigate the NEED for the RAII idiom.
>
> C exceptions (i.e. longjmp) also require it.
>
>> Without exceptions, RAII is merely a convenience (still nice, but not
>> important/necessary).
>
> I suppose it depends upon whether legibility is important/necessary or
> merely a convenience. The contortions required to get by without it
> can be pretty ugly. Similarly, one could ask whether high-level
> languages are important/necessary, or merely a convenience.

I think it depends on how creative one is. 

Joshua Maurice wrote:
> On May 20, 11:14 pm, "MikeP" <mp011...@some.org> wrote:
>> That seems like a juxtaposed statement, for it is C++ exceptions that
>> instigate the NEED for the RAII idiom. Without exceptions, RAII is
>> merely a convenience (still nice, but not important/necessary).
>
> That's a matter of opinion.
>
> The first thing that Bjarne Stroustrup added to C to make C++ was
> destructors, more or less. In his own words in this forum, it predated
> all the other cool things, like templates, virtual, exceptions, by
> years. I agree with Bjarne that the thing I miss the most when I'm
> forced to do C, or maintain C-like C++ code, is destructors.
>
> The utility of destructors is not mere syntactic sugar like a ranged-
> based for loop ala Java and C++0x or even the virtual keyword.
> Implicit calling of functions when objects leave scope is incredibly
> "powerful" and useful. It greatly reduces a whole class of programming
> errors. It does this IMHO in two main ways. First it helps the
> programmer not forget to add a free-resource call to a deinit call
> (now also usually a destructor), and helps the programmer not forget a
> free-resource call (now also usually a destructor) on an exit path in
> a function.
>
> Second, it helps foster a certain kind of programming paradigm where
> the coder ensures that all resources have an owner at all times. Most
> of the time, that is except for the occasional no-throw block or no-
> throw operation which transfers ownership or allocates a resource, you
> can unwind the stack at any time and you will not leak resources -
> required with exceptions, but still useful otherwise. When all
> resources have a clearly identified owner (and thus destruction
> condition), and the ownership graph in large part has all of its roots
> in stack objects, leaks become much rarer, especially with the
> idiomatic usage.
>

RAII is an idiom that is built upon the mechanisms that allow 
user-defined types to behave somewhat like built-in types. A trace class 
can use the same mechanisms but there are no resources to speak of in 
that scenario.  RAII has become such a clouding concept to the 
underpinnings. It seems like there is some terminology conspicuously 
absent in between the mechanisms and the high level idiom RAII (and of 
course the trace scenario is a sibling implementation of the pattern that 
RAII is based on). 

Juha Nieminen wrote:
> MikeP <mp011011@some.org> wrote:
>> That seems like a juxtaposed statement, for it is C++ exceptions that
>> instigate the NEED for the RAII idiom. Without exceptions, RAII is
>> merely a convenience (still nice, but not important/necessary).
>
>  I don't understand where this notion is coming from.
>
>  Even if exceptions were disabled (in many compilers you can disable
> them so that they will never be thrown) it would still be a nightmare
> to develop a large project without RAII.
>

But not impossible. And creativity counts. Do/undo and keep functions 
short (the C way) and then you're out of the realm of "nightmare". (Not 
that I'm suggesting one do it that way).

>  I would say the opposite of you: RAII is essential. The fact that it
> allows making code exception-safe is a nice side-effect, but not the
> main point.

The scoped lifetime of classes on the stack is nifty, yes. I think the 
RAII idiom necessarily brings in the exception stuff though. It's the 
best way to do it, but not the only way (unless you turn on the exception 
switch on the compiler). Constructors and operators need exceptions, 
exceptions necessitate RAII... it's a chain reaction of which there are 
at least a few of in the design of C++. It's a steep learning curve at 
first (and maybe even longer than just at first). Once one knows the 
idioms though, it's not too bad.

I'm rambling, I better go to bed. 

Rui Maciel wrote:
> MikeP wrote:
>
>> Your point being that people who live in houses with conveniences
>> like indoor plumbing and electricity simply don't understand how
>> simple living in caves is so much better? Even though most of these
>> people used to be cave-dwellers? ;-)
>
> I don't believe that the differences between C++ and C are equivalent
> to the differences between a house with indoor plumbing and
> electricity and a cave.  I see it more as the difference between a
> house fully stocked with a hefty set of conveniences and features
> such as home automation, HVAC and even HAL from 2001: A Space
> Odyssey, and the exact same house with barely any furniture and
> stripped of any of those bells and wistles.  Both are good houses,
> you can live confortably in any of those but in some cases you don't
> have those gadgets helping you/constantly getting on your way.
>
>

OK, the caves would probably be assembly language. C is more like a 
fishing shack where you have to bring wood in from outside to burn in 
that big iron thing in the middle of the room to get warm and C++ more 
like a nice "modern" (1970-ish) house (which, of course, started life as 
a fishing shack but got remodeled and added-on to over the years as 
people started to retire from their city jobs and moved to their place in 
the country), but not as extravagant as you say. You are talking about D 
(!). ;-)

"MikeP" <mp011011@some.org> writes:
>Keith H Duggar wrote:
>>[...] I would say that
>>the C++ automatic constructor/destructor paradigm (which was a C++
>>innovation as far as I know?) is also extremely valuable.
>Innovation? Looks like a quite nice and convenient side-effect. 

  Anyways, that's the history of template-based
  metaprogramming (which is a side-effect of templates and
  was shown by Erwin Unruh in 1994).

"MikeP" <mp011011@some.org> writes:
>RAII has become such a clouding concept to the underpinnings.

  Why is it �clouding�?

>It seems like there is some terminology conspicuously absent
>in between the mechanisms and the high level idiom RAII

  If terminology is missing for something that already exists,
  the terminology can be introduced. Would you mind to suggest
  some of this terminology?

"MikeP" <mp011011@some.org>
>>> The trade-off (there always is one) being Template Code Bloat (TCB).
>>
>>  What's that, exactly?
>
> Type "template code bloat" or "C++ template code bloat" into your favorite 
> internet search engine and you'll get a long listing.

Type in bullshit at the same place to get an even longer list... Care to 
explain your own assertion, especially what bloat is created compared to 
what alternative executing the same task?

Or you're just creating flood to have more posts i this thread than the rest 
together?

Op 21-May-11 16:08, MikeP schreef:
> Juha Nieminen wrote:
>> MikeP<mp011011@some.org>  wrote:
>>> That seems like a juxtaposed statement, for it is C++ exceptions that
>>> instigate the NEED for the RAII idiom. Without exceptions, RAII is
>>> merely a convenience (still nice, but not important/necessary).
>>
>>   I don't understand where this notion is coming from.
>>
>>   Even if exceptions were disabled (in many compilers you can disable
>> them so that they will never be thrown) it would still be a nightmare
>> to develop a large project without RAII.
>>
>
> But not impossible. And creativity counts. Do/undo and keep functions
> short (the C way) and then you're out of the realm of "nightmare". (Not
> that I'm suggesting one do it that way).
>
>>   I would say the opposite of you: RAII is essential. The fact that it
>> allows making code exception-safe is a nice side-effect, but not the
>> main point.
>
> The scoped lifetime of classes on the stack is nifty, yes. I think the
> RAII idiom necessarily brings in the exception stuff though. It's the
> best way to do it, but not the only way (unless you turn on the exception
> switch on the compiler). Constructors and operators need exceptions,
> exceptions necessitate RAII... it's a chain reaction of which there are
> at least a few of in the design of C++.

Several C++ compilers I have used in the early nineties didn't support 
exceptions at all, yet they did support constructors and destructors. 
In those days classes often had an initialize method or a method to 
check if the object was successfully constructed; not particularly 
elegant but at the end of the day it did get the job done.

There certainly is a strong synergy between exceptions and RAII in C++, 
the C++ language would have been a lot worse without one or the other. 
But without exceptions RAII would be still useful, whereas exceptions 
would be useless in C++ without RAII (unless something like a 'finally' 
clause were added to the language).

On Sat, 21 May 2011 08:20:10 +0000, Juha Nieminen wrote:

>   The point is that C advocates try to ride on the concept of language
> simplicity. With other languages simplicity means not only that the
> language specification is relatively short, but also that writing
> programs is simple and straightforward (because, among other things,
> the programmer is not burdened by memory management and other similar
> issues). The simplicity of the language directly correlates to how much
> you have to write in order to implement a given task, and how much of
> what you write is directly related to the task itself (rather than to
> ancillary things like memory management). Also, how easy it is to
> understand the code.

For the kind of task that C was designed for, and is best suited for,
there's a strong correlation between simplicity of implementation and
simplicity of usage.

When you need to know and/or control the details of what's going under the
hood, having the implementation do too much for you can make it harder to
use rather than easier. E.g. if you're likely to adjust your code based
upon the resulting assembly language, having a fairly direct
correspondence between source code and assembler is an advantage.

In terms of understanding the code, the ability of C++ to "hide" code in
constructors and overloaded operators can be seen as an impediment to
legibility. The C++ perspective is that you don't need to know the
details; you just trust that the implementation behaves correctly. In
situations where C is the correct choice, the details often matter.

On May 21, 1:30=A0am, "MikeP" <mp011...@some.org> wrote:
> Keith H Duggar wrote:
> > [...] I would say that
> > the C++ automatic constructor/destructor paradigm (which was a C++
> > innovation as far as I know?) is also extremely valuable.
>
> Innovation? Looks like a quite nice and convenient side-effect.

Side-effect of what? Which languages do you know of that
had automatic deterministic destructors prior to C++?

KHD

Nobody <nobody@nowhere.com> wrote:
> In terms of understanding the code, the ability of C++ to "hide" code in
> constructors and overloaded operators can be seen as an impediment to
> legibility. The C++ perspective is that you don't need to know the
> details; you just trust that the implementation behaves correctly. In
> situations where C is the correct choice, the details often matter.

  That argument makes no sense. Constructors and overloaded operators
are just functions. C supports functions as well. Functions whose source
code might not be available at all. I don't understand your argument.

Op 21-May-11 20:43, Juha Nieminen schreef:
> Nobody<nobody@nowhere.com>  wrote:
>> In terms of understanding the code, the ability of C++ to "hide" code in
>> constructors and overloaded operators can be seen as an impediment to
>> legibility. The C++ perspective is that you don't need to know the
>> details; you just trust that the implementation behaves correctly. In
>> situations where C is the correct choice, the details often matter.
>
>    That argument makes no sense. Constructors and overloaded operators
> are just functions. C supports functions as well. Functions whose source
> code might not be available at all. I don't understand your argument.

The difference is that C if you want some thing to happen you must 
explicitly write code for it; what you see is what you get. In C++ lots 
of things can happen because of an innocently looking statement or even 
when there is no code at all (destructors); you may very well get more 
than that you see.

"Dombo" <dombo@disposable.invalid>
> The difference is that C if you want some thing to happen you must 
> explicitly write code for it; what you see is what you get. In C++ lots of 
> things can happen because of an innocently looking statement or even when 
> there is no code at all (destructors); you may very well get more than 
> that you see.

Is there any real difference?  C was created as a "portable assembler". You 
lost the "what you see" attribute right with that step.

By design certainly, that was the point -- you write code using abstract 
types like int, short, pointers, "arrays", and the approppriate assembly 
code is generated for the platform.

Can you tell what machine instructions you will get from a C source? For 
some level, yes: if you know the semantics.

But the very same is true for C++. 

Balog Pal wrote:

> "Dombo" <dombo@disposable.invalid>
>> The difference is that C if you want some thing to happen you must
>> explicitly write code for it; what you see is what you get. In C++ lots
>> of things can happen because of an innocently looking statement or even
>> when there is no code at all (destructors); you may very well get more
>> than that you see.
> 
> Is there any real difference? 

I think it does make a real difference. Well, I don't know C; but I see a 
difference between a language where you have to be explicit about the things 
that happen at a particular point of the control flow (from the above, C is 
supposedly such a language) and a language where many things are left 
implicit (i.e., what happens at this point of flow has been specified at 
some remote location in the code).

In C++, destructors and exceptions are the two things that carry a load of 
implicitness with them. That it makes a real difference is illustrated by 
the need of people getting used to it. If it was "just the same", old habits 
should carry over and work just fine. The difficulty of learning to aquire 
the habit of writing code that fares well in the presence of possible 
exceptions goes to show that the difference is real.

> C was created as a "portable assembler".
> You lost the "what you see" attribute right with that step.
> 
> By design certainly, that was the point -- you write code using abstract
> types like int, short, pointers, "arrays", and the approppriate assembly
> code is generated for the platform.
> 
> Can you tell what machine instructions you will get from a C source? For
> some level, yes: if you know the semantics.
> 
> But the very same is true for C++.

True, but the claimed difference was not that you can see the assembly code 
through the C code. The difference was that you have to be explicit about 
what should happen: if you don't issue the command here (at this point in 
code), it won't happen now (when control flow passes through this point in 
code). I don't know whether that description holds for C, but surely it does 
not for C++.


Best,

Kai-Uwe Bux

p.s.: Note that I am not saying that being explicit is better.

Op 21-May-11 21:48, Balog Pal schreef:
> "Dombo" <dombo@disposable.invalid>
>> The difference is that C if you want some thing to happen you must
>> explicitly write code for it; what you see is what you get. In C++
>> lots of things can happen because of an innocently looking statement
>> or even when there is no code at all (destructors); you may very well
>> get more than that you see.
>
> Is there any real difference? C was created as a "portable assembler".
> You lost the "what you see" attribute right with that step.

I never looked seriously at C99 but the last time I looked at C it 
didn't have destructors, exceptions, templates or other constructs that 
can generate surprising amounts of code if one is not careful.

> By design certainly, that was the point -- you write code using abstract
> types like int, short, pointers, "arrays", and the approppriate assembly
> code is generated for the platform.
>
> Can you tell what machine instructions you will get from a C source? For
> some level, yes: if you know the semantics.
>
> But the very same is true for C++.

In the strict sense that can be said for just about any language, but 
for some programming languages it is easier to predict what code will 
generated than others. There are many shades of gray between black and 
white.

The point "Nobody" was making is that C being such a low level language 
the translation from source code to assembly is relatively 
straightforward, so it is easier for a programmer to predict what kind 
of code and how much code the compiler will produce by just looking at 
the source code. In many cases this is a matter of no concern, but in 
small embedded systems where every cycle counts and the amount memory is 
expressed in Kilobytes or less rather than Mega- or Gigabytes you don't 
want to have too much between you and the bare metal. In some cases C 
might be the right compromise between assembly and C++.

On 05/22/11 08:45 AM, Dombo wrote:
> Op 21-May-11 21:48, Balog Pal schreef:
>> "Dombo"<dombo@disposable.invalid>
>>> The difference is that C if you want some thing to happen you must
>>> explicitly write code for it; what you see is what you get. In C++
>>> lots of things can happen because of an innocently looking statement
>>> or even when there is no code at all (destructors); you may very well
>>> get more than that you see.
>>
>> Is there any real difference? C was created as a "portable assembler".
>> You lost the "what you see" attribute right with that step.
>
> I never looked seriously at C99 but the last time I looked at C it
> didn't have destructors, exceptions, templates or other constructs that
> can generate surprising amounts of code if one is not careful.

No its doesn't.  You just have to generate that very same code by hand! 
  Whether the compiler or the programmer generates the code is 
irrelevant.  If a job has to be done, code has to be generated to do it.

>> By design certainly, that was the point -- you write code using abstract
>> types like int, short, pointers, "arrays", and the approppriate assembly
>> code is generated for the platform.
>>
>> Can you tell what machine instructions you will get from a C source? For
>> some level, yes: if you know the semantics.
>>
>> But the very same is true for C++.
>
> In the strict sense that can be said for just about any language, but
> for some programming languages it is easier to predict what code will
> generated than others. There are many shades of gray between black and
> white.
>
> The point "Nobody" was making is that C being such a low level language
> the translation from source code to assembly is relatively
> straightforward, so it is easier for a programmer to predict what kind
> of code and how much code the compiler will produce by just looking at
> the source code. In many cases this is a matter of no concern, but in
> small embedded systems where every cycle counts and the amount memory is
> expressed in Kilobytes or less rather than Mega- or Gigabytes you don't
> want to have too much between you and the bare metal. In some cases C
> might be the right compromise between assembly and C++.

That may have been true in the 90s, but it is no longer the case with 
contemporary compilers.  Have you ever looked at the generated assembler 
for a highly optimised code module?

-- 
Ian Collins

On May 21, 11:45=A0pm, Dombo <do...@disposable.invalid> wrote:
> Op 21-May-11 21:48, Balog Pal schreef:
>
> > "Dombo" <do...@disposable.invalid>
> >> The difference is that C if you want some thing to happen you must
> >> explicitly write code for it; what you see is what you get. In C++
> >> lots of things can happen because of an innocently looking statement
> >> or even when there is no code at all (destructors); you may very well
> >> get more than that you see.
>
> > Is there any real difference? C was created as a "portable assembler".
> > You lost the "what you see" attribute right with that step.
>
> I never looked seriously at C99 but the last time I looked at C it
> didn't have destructors, exceptions, templates or other constructs that
> can generate surprising amounts of code if one is not careful.

C++ used wrongly is indeed a great tool for code obfuscation. For
example, like you seem to complain, some of C++ features allow to
generate implicit easter egg code that is hard to spot.

These features are indeed there but that does not mean you absolutely
have to use the features. On the contrary, most C++ coding standards
suggest not to use conversion operators, suggest to avoid implicit
conversion constructors, put lot of limitations to usage of exceptions
and so on.

For example in our team obfuscated C++ usually does not pass the code
review and author has to correct it.

I am not sure what is wrong with destructors and templates you claim.
Usage of templates has to be explicit and all classes do have
destructors so these can not be surprise.

"Kai-Uwe Bux" <jkherciueh@gmx.net>

> In C++, destructors and exceptions are the two things that carry a load of
> implicitness with them. That it makes a real difference is illustrated by
> the need of people getting used to it.

Hm, I'm reading C++ forums for nearly 2 decades, and know a shelfload of 
stuff that needs "getting used to".  i can't recall a single case someone 
didn;t get the "destructor will be called on any kind of exiting scope" 
part.  And there is confusion around exceptions, but it is definitely not 
the implicit code generated by the exception.

> If it was "just the same", old habits
> should carry over and work just fine.

IME people with good programming habits fare well with whatever 
language/system. And those with bad habits mes up anything. Putting with C 
they mess up miserably and need no help from C++.  (buffer overruns? leaks? 
race conditions? dongling pointers?)

> he difficulty of learning to aquire
> the habit of writing code that fares well in the presence of possible
> exceptions goes to show that the difference is real.

Again, IME people who can could not grok exception safety did not write 
usable code in C either -- it maybe the "straight" path worked to some 
level, but errors were not checked, and/or the error handling code was 
buggy.

And those who mastered the discipline to write correct C code (with no leaks 
or UB on any condition) all could deal with exceptions -- and actually 
preferred to use them whenever possible. Just to get rid of the extreme 
source bloat handling the error conditions bring even to single functions --  
let alone when you want to propagate upwards.  What is a too common case.

"Dombo" <dombo@disposable.invalid>

> I never looked seriously at C99 but the last time I looked at C it didn't 
> have destructors, exceptions, templates or other constructs that can 
> generate surprising amounts of code if one is not careful.

For some reason claims about amount of code in forums generally come from 
people who never bothered to look at assy.  Just like the famous priest back 
in middle age who knew better that Jupiter can not have moons.  Please do 
some experiments then come back with results, and we may have a fruitful 
discussion.

>> By design certainly, that was the point -- you write code using abstract
>> types like int, short, pointers, "arrays", and the approppriate assembly
>> code is generated for the platform.
>>
>> Can you tell what machine instructions you will get from a C source? For
>> some level, yes: if you know the semantics.
>>
>> But the very same is true for C++.
>
> In the strict sense that can be said for just about any language, but for 
> some programming languages it is easier to predict what code will 
> generated than others. There are many shades of gray between black and 
> white.

Probably so, but I keep the claim that destructor code hardly surprises any 
competent C programmer.
With implicit  converting ctors and operators you indeed can create a mess, 
but the base guidelines say not to use them. And when used they are 
hopefully well designed.   (And deliberate bad design is not worth 
discussing, as C has too many elements that are can be broken.)

> The point "Nobody" was making is that C being such a low level language 
> the translation from source code to assembly is relatively 
> straightforward, so it is easier for a programmer to predict what kind of 
> code and how much code the compiler will produce by just looking at the 
> source code.

I never had problem predicting the code in either language. My experience 
really show no practical difference. I mean if said prediction happens in 
the correct context, as comparing it to the *necessary* code to have a 
desired behavior.

> In many cases this is a matter of no concern, but in small embedded 
> systems where every cycle counts and the amount memory is expressed in 
> Kilobytes or less rather than Mega- or Gigabytes you don't want to have 
> too much between you and the bare metal.

Another interesting observation from forums, that claims about embedded 
systems too often come from people never working on any.   I for example did 
embedded stuff in both languages. Exceptions are normally turned off, while 
dtors and templates are welcome.  And they create the same code you would by 
hand.   And when you're hit by a case you need to do assembly, it is the 
same in C.

> In some cases C might be the right compromise between assembly and C++.

The only cases I experienced were "no C++ compiler" and "C++ compiler way 
too expensive".

When Bjarne created C++ the design foundation had both "C compatibility" and 
"no pay for what is not used". And those fairly succeeded.

Balog Pal wrote:
> "MikeP" <mp011011@some.org>
>>>> The trade-off (there always is one) being Template Code Bloat
>>>> (TCB).
>>>
>>>  What's that, exactly?
>>
>> Type "template code bloat" or "C++ template code bloat" into your
>> favorite internet search engine and you'll get a long listing.
>
> Type in bullshit at the same place to get an even longer list... Care
> to explain your own assertion, especially what bloat is created
> compared to what alternative executing the same task?
>
> Or you're just creating flood to have more posts i this thread than
> the rest together?

I can only lead you to the water. I can't make you drink it. Suit 
yourself. 

Keith H Duggar wrote:
> On May 21, 1:30 am, "MikeP" <mp011...@some.org> wrote:
>> Keith H Duggar wrote:
>>> [...] I would say that
>>> the C++ automatic constructor/destructor paradigm (which was a C++
>>> innovation as far as I know?) is also extremely valuable.
>>
>> Innovation? Looks like a quite nice and convenient side-effect.
>
> Side-effect of what?

Of the quest to make user-defined types behave like built-in types.

> Which languages do you know of that
> had automatic deterministic destructors prior to C++?
>

Stefan Ram wrote:
> "MikeP" <mp011011@some.org> writes:
>> RAII has become such a clouding concept to the underpinnings.
>
>  Why is it �clouding�?
>
>> It seems like there is some terminology conspicuously absent
>> in between the mechanisms and the high level idiom RAII
>
>  If terminology is missing for something that already exists,
>  the terminology can be introduced. Would you mind to suggest
>  some of this terminology?

Actually, I was hoping someone else would after thinking about it so I 
could fit that info in with my own thoughts on the matter. Seems like a 
good question for "the man" himself! How about it Bjarne, too busy? It's 
not a major thing, but maybe something more than just trivia. 

Dombo wrote:
> Op 21-May-11 16:08, MikeP schreef:
>> Juha Nieminen wrote:
>>> MikeP<mp011011@some.org>  wrote:
>>>> That seems like a juxtaposed statement, for it is C++ exceptions
>>>> that instigate the NEED for the RAII idiom. Without exceptions,
>>>> RAII is merely a convenience (still nice, but not
>>>> important/necessary).
>>>
>>>   I don't understand where this notion is coming from.
>>>
>>>   Even if exceptions were disabled (in many compilers you can
>>> disable them so that they will never be thrown) it would still be a
>>> nightmare to develop a large project without RAII.
>>>
>>
>> But not impossible. And creativity counts. Do/undo and keep functions
>> short (the C way) and then you're out of the realm of "nightmare".
>> (Not that I'm suggesting one do it that way).
>>
>>>   I would say the opposite of you: RAII is essential. The fact that
>>> it allows making code exception-safe is a nice side-effect, but not
>>> the main point.
>>
>> The scoped lifetime of classes on the stack is nifty, yes. I think
>> the RAII idiom necessarily brings in the exception stuff though.
>> It's the best way to do it, but not the only way (unless you turn on
>> the exception switch on the compiler). Constructors and operators
>> need exceptions, exceptions necessitate RAII... it's a chain
>> reaction of which there are at least a few of in the design of C++.
>
> Several C++ compilers I have used in the early nineties didn't support
> exceptions at all, yet they did support constructors and destructors.
> In those days classes often had an initialize method or a method to
> check if the object was successfully constructed; not particularly
> elegant but at the end of the day it did get the job done.
>
> There certainly is a strong synergy between exceptions and RAII in
> C++, the C++ language would have been a lot worse without one or the
> other. But without exceptions RAII would be still useful, whereas
> exceptions would be useless in C++ without RAII (unless something
> like a 'finally' clause were added to the language).

Can there be "synergy" where there is a dependency? Doesn't the 
dependency make it (exceptions + RAII) a singularity rather than 
plurality? 

MikeP <mp011011@some.org> wrote:
> Balog Pal wrote:
>> "MikeP" <mp011011@some.org>
>>>>> The trade-off (there always is one) being Template Code Bloat
>>>>> (TCB).
>>>>
>>>>  What's that, exactly?
>>>
>>> Type "template code bloat" or "C++ template code bloat" into your
>>> favorite internet search engine and you'll get a long listing.
>>
>> Type in bullshit at the same place to get an even longer list... Care
>> to explain your own assertion, especially what bloat is created
>> compared to what alternative executing the same task?
>>
>> Or you're just creating flood to have more posts i this thread than
>> the rest together?
> 
> I can only lead you to the water. I can't make you drink it. Suit 
> yourself. 

  I still don't understand what this "template code bloat" is.

  Does templated code require more code than non-templated code?
Well, if we compare it to *one* non-templated function or class, there
indeed is at least one additional line of code (the "template" part).
Also, every member function of a template class, if not implemented in
the class declaration, will require the additional "template" line as
well. Also, there will be additional "<type>" specifications. This indeed
increases the amount of code somewhat, but not very radically.

  However, if we compare the *generated* code with the equivalent
non-templated versions, the amount of code is immediately smaller in
the templated version, rather obviously, because there will be no
code repetition. A non-templated function or class will have to be
duplicated for each type. This would indeed be code bloat. In fact,
templates are helping *reduce* code bloat, not increase it. So I don't
really understand your point.

  Or are you talking about the executable binary? Do you mean that the
end result ends up significantly larger than when not using templates?
My question would be: Compared to what?

  If you use a templated function or class with one type, the generated
code will be pretty much the same as if a non-templated version of that
function or class had been used with that specific type. I don't see how
the executable binary would get any larger. (If the binary includes
debugging information then it may be larger because mangled template
names are usually larger than non-templated ones. However, that would be
a pretty silly argument because the debug information is there for a
debug build of the project, but not intended for the final distribution
build.)

  If you use the same templated function or class with two types, the
code will be duplicated (although optimized for each type individually,
possibly resulting in a smaller result for one type than the other).
What would be a non-templated alternative? Most obviously, explicitly
duplicating the source code for each of the two types. The resulting
binary would still be pretty much the same as with the templated version,
so exactly what would be the difference?

  In some situations you could try to make a (somewhat) generic but
non-templated implementation, as is typical in C. Almost invariably
this will introduce inefficiency and lack of type-safety compared to
the templated version (see qsort() for a practical example). Rather
ironically, in some situations it might even produce a *larger* binary
than the templated version (because the templated version can usually
be inlined by the compiler, possibly optimizing entire function calls
away and tightly optimizing and packing their code at the calling site,
embedded and merged with the surrounding code).

  Nevertheless, even in situations where heavily templated code truly
generates a larger executable binary by a significant margin compared to
some non-templated alternative, is it really that catastrophic? Maybe in
some embedded systems with very little RAM it could be an issue, but the
vast majority of C++ code out there is not made for such systems. In a
typical desktop machine it makes little difference whether the executable
binary is 1 MB or 1.5 MB in size (assuming the templated code makes that
much of a difference).

  It is still unclear to me what exactly is it that you mean by "template
code bloat".

On May 21, 10:57=A0pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> =A0 I still don't understand what this "template code bloat" is.

Imagine you have a container, such as std::vector. There are two basic
ways to implement it, as C++ std::vector, or as you have to in C with
void pointers, or as you would in Java with their equivalent of
pointers eg: ArrayList.

It's a tradeoff. With the C approach (equivalently
java.util.ArrayList), there is one piece of assembly corresponding to
that function for all possible instantiations of the container class
and for all possible contained types. With the std::vector approach,
you can have a different piece of assembly in the object file for each
different type used to instantiate the template. That is,
std::vector<int> and std::vector<char> can (and usually will) be
compiled down to different functions in the object file, distinguished
by name mangling. Thus, the template way results in less instructions
executed compared to the void pointer approach, but it results in
larger executables.

The tradeoff is do you want smaller executables, or less instructions
implemented. The decision is particulars specific, and I'm not talking
about hard memory constraints. I'm talking about execution time.
Larger executables generally mean that your cache hit rate will be
smaller, possibly dwarfing the benefit of less instructions executed,
resulting in a slower running executable.

Balog Pal wrote:

> 
> "Kai-Uwe Bux" <jkherciueh@gmx.net>
> 
>> In C++, destructors and exceptions are the two things that carry a load
>> of implicitness with them. That it makes a real difference is illustrated
>> by the need of people getting used to it.
> 
> Hm, I'm reading C++ forums for nearly 2 decades, and know a shelfload of
> stuff that needs "getting used to".  i can't recall a single case someone
> didn;t get the "destructor will be called on any kind of exiting scope"
> part.  
[...]

You snipped too much context. Also, it seems as though you are shifting the 
question under discussion. The question was whether the difference of 
explicitness and implicitness "is real" (a vague term). I don't think the 
difference, although real, has to manifest itself in items that some people 
just don't get. Of course, both languages can be learned and understood 
(like German and Japaneese). Still there can be real differences (like with 
German and Japaneese).


Upthread, you asked the question in the first place:

> "Dombo" <dombo@disposable.invalid>
> > The difference is that C if you want some thing to happen you must 
> > explicitly write code for it; what you see is what you get. In C++
> > lots of things can happen because of an innocently looking statement
> > or even when there is no code at all (destructors); you may very
> > well get more than that you see.
> 
> Is there any real difference?

Since you chose the term, maybe you could _define_ "real difference"?

The way, I understand it, the difference between explicit and implicit is 
real. But it seems, your understanding is different.


Best,

Kai-Uwe Bux

"Kai-Uwe Bux" <jkherciueh@gmx.net>

[quotes rearranged!]
>> "Kai-Uwe Bux" <jkherciueh@gmx.net>
> Upthread, you asked the question in the first place:
>
>> "Dombo" <dombo@disposable.invalid>
>> > The difference is that C if you want some thing to happen you must
>> > explicitly write code for it; what you see is what you get. In C++
>> > lots of things can happen because of an innocently looking statement
>> > or even when there is no code at all (destructors); you may very
>> > well get more than that you see.
>>
>> Is there any real difference?

Seem like poor choice of words on my part.  I meant something like real 
*practical* difference. A difference that leads to actual better/worse 
software, more/less planted bugs etc.

>>> In C++, destructors and exceptions are the two things that carry a load
>>> of implicitness with them. That it makes a real difference is 
>>> illustrated
>>> by the need of people getting used to it.
>>
>> Hm, I'm reading C++ forums for nearly 2 decades, and know a shelfload of
>> stuff that needs "getting used to".  i can't recall a single case someone
>> didn;t get the "destructor will be called on any kind of exiting scope"
>> part.
> [...]
>
> You snipped too much context. Also, it seems as though you are shifting 
> the
> question under discussion. The question was whether the difference of
> explicitness and implicitness "is real" (a vague term).

I was following my own thoughts ;-)  In the abstract terms, certainly 
explicit is "really" different from implicit. I don't see too productive to 
discuss sophistry. I'm interested in implications on the real world.

>  I don't think the
> difference, although real, has to manifest itself in items that some 
> people
> just don't get. Of course, both languages can be learned and understood
> (like German and Japaneese). Still there can be real differences (like 
> with
> German and Japaneese).

After clearing up the misunderstanding, could we follow the practical chain?

Balog Pal wrote:

> "Kai-Uwe Bux" <jkherciueh@gmx.net>
> 
> [quotes rearranged!]
>>> "Kai-Uwe Bux" <jkherciueh@gmx.net>
>> Upthread, you asked the question in the first place:
>>
>>> "Dombo" <dombo@disposable.invalid>
>>> > The difference is that C if you want some thing to happen you must
>>> > explicitly write code for it; what you see is what you get. In C++
>>> > lots of things can happen because of an innocently looking statement
>>> > or even when there is no code at all (destructors); you may very
>>> > well get more than that you see.
>>>
>>> Is there any real difference?
> 
> Seem like poor choice of words on my part.  I meant something like real
> *practical* difference. A difference that leads to actual better/worse
> software, more/less planted bugs etc.

[...]

> After clearing up the misunderstanding, could we follow the practical
> chain?

Certainly.

In terms of likelyhood of bugs, I think it's not so much a difference in 
total number of bugs per line but a difference in distribution. The error 
patterns will be different. The implicit coding style can help to avoid many 
bugs. If you put clean up code in the destructor, it will be very hard to 
_not_ execute it at the appropriate point. Exceptions in templated code, on 
the other hand, can lurk at places where you don't espect them diverting 
control flow to a point determined by the type of the exception thrown (and 
within a template, that can be an unknown type, whence the target of the 
jump is unknown, too). On the other hand, not seeing those jumps written 
explicitly, can improve readability of the code; and having client code 
determine the target of the jump even allows for greater flexibility than 
goto -- whether that is good or bad, I guess, depends on the perspective.

In terms of better/worse software, I do not see any evidence either way. It 
seems that other factors are much more decisive. In the end, it's not the 
language alone but a tupel

  (group of developers, languages used, toolchain, ...)

that influences overall quality of the result. This is not to say that 
changing a single element in the tupel does not have an effect. But in one 
setting going from C to C++ can boost the quality and in another setting it 
can make things worse.


Upshot:
=======
It think, for any particular project, there is a practical difference in 
choosing C++ or C or (insert other language here). Making the right choice 
will improve work flow and quality of the developed program. However, what 
the "right choice" is depends on many factors and the "right choice" is not 
uniform.

I am not sure whether that qualifies as a "practical difference" in the 
sense of your question. But surely, choosing C++ or C is a consideration of 
practical importance. I would, however, venture the following conjecture: 
whether the explicit/implicit distinction will have any seizable weight in 
choosing the language probably depends more on the developers involved than 
the task at hand.


Best,

Kai-Uwe Bux

Balog Pal wrote:

> Is there any real difference?  C was created as a "portable assembler".
> You lost the "what you see" attribute right with that step.
> 
> By design certainly, that was the point -- you write code using abstract
> types like int, short, pointers, "arrays", and the approppriate assembly
> code is generated for the platform.
> 
> Can you tell what machine instructions you will get from a C source? For
> some level, yes: if you know the semantics.
> 
> But the very same is true for C++.

No one may be 100% sure on how a C source will translate to opcode.  The 
same also applies to C++.  Yet, while the case with C is limited to how a 
set of C instructions is translated to opcode, the case with C++ also 
involves how the C++ code is used to generate other language constructs 
and subsequently how those language constructs are translated to opcode.  
Therefore, with C++ you have to deal with an added, opaque abstraction 
layer which no one actually has any control over.  This is a real 
difference.


Rui Maciel

Öö Tiib wrote:

> C++ used wrongly is indeed a great tool for code obfuscation. For
> example, like you seem to complain, some of C++ features allow to
> generate implicit easter egg code that is hard to spot.
> 
> These features are indeed there but that does not mean you absolutely
> have to use the features. On the contrary, most C++ coding standards
> suggest not to use conversion operators, suggest to avoid implicit
> conversion constructors, put lot of limitations to usage of exceptions
> and so on.
> 
> For example in our team obfuscated C++ usually does not pass the code
> review and author has to correct it.
> 
> I am not sure what is wrong with destructors and templates you claim.
> Usage of templates has to be explicit and all classes do have
> destructors so these can not be surprise.

As I see it, the point is that, in this context, while with C you only 
need to invest your time researching how to generate code from your source 
code, with C++ you are forced to research how to generate code from your 
source code and, more importantly, how to avoid code being generated for 
you from your source code.  Although this isn't necessarily a big concern 
in many applications, when it is then it's quite possible that C++ 
generates more work than it saves, or at least requires a greater level of 
expertise than that which would otherwise be required.


Rui Maciel

Juha Nieminen <nospam@thanks.invalid> writes:
>  Nevertheless, even in situations where heavily templated code truly
>generates a larger executable binary by a significant margin compared to
>some non-templated alternative, is it really that catastrophic? Maybe in
>some embedded systems with very little RAM it could be an issue, but the
>vast majority of C++ code out there is not made for such systems. In a
>typical desktop machine it makes little difference whether the executable
>binary is 1 MB or 1.5 MB in size (assuming the templated code makes that
>much of a difference).

  When code is smaller, the chance is greater that it might fit in some
  cache, which will make it execute much faster.

Op 22-May-11 6:55, MikeP schreef:
> Dombo wrote:
>> Op 21-May-11 16:08, MikeP schreef:
>>> Juha Nieminen wrote:
>>>> MikeP<mp011011@some.org>   wrote:
>>>>> That seems like a juxtaposed statement, for it is C++ exceptions
>>>>> that instigate the NEED for the RAII idiom. Without exceptions,
>>>>> RAII is merely a convenience (still nice, but not
>>>>> important/necessary).
>>>>
>>>>    I don't understand where this notion is coming from.
>>>>
>>>>    Even if exceptions were disabled (in many compilers you can
>>>> disable them so that they will never be thrown) it would still be a
>>>> nightmare to develop a large project without RAII.
>>>>
>>>
>>> But not impossible. And creativity counts. Do/undo and keep functions
>>> short (the C way) and then you're out of the realm of "nightmare".
>>> (Not that I'm suggesting one do it that way).
>>>
>>>>    I would say the opposite of you: RAII is essential. The fact that
>>>> it allows making code exception-safe is a nice side-effect, but not
>>>> the main point.
>>>
>>> The scoped lifetime of classes on the stack is nifty, yes. I think
>>> the RAII idiom necessarily brings in the exception stuff though.
>>> It's the best way to do it, but not the only way (unless you turn on
>>> the exception switch on the compiler). Constructors and operators
>>> need exceptions, exceptions necessitate RAII... it's a chain
>>> reaction of which there are at least a few of in the design of C++.
>>
>> Several C++ compilers I have used in the early nineties didn't support
>> exceptions at all, yet they did support constructors and destructors.
>> In those days classes often had an initialize method or a method to
>> check if the object was successfully constructed; not particularly
>> elegant but at the end of the day it did get the job done.
>>
>> There certainly is a strong synergy between exceptions and RAII in
>> C++, the C++ language would have been a lot worse without one or the
>> other. But without exceptions RAII would be still useful, whereas
>> exceptions would be useless in C++ without RAII (unless something
>> like a 'finally' clause were added to the language).
>
> Can there be "synergy" where there is a dependency? Doesn't the
> dependency make it (exceptions + RAII) a singularity rather than
> plurality?

I have used C++ compilers which supported RAII but not exceptions (and 
even today you can disable exception support without disabling RAII on 
several C++ compilers), there are also quite a few programming languages 
which support exceptions but no RAII. So as far as 'm concerned RAII and 
exceptions are not mutually dependent in the sense that you cannot have 
one without the other.

Dombo wrote:
> Op 22-May-11 6:55, MikeP schreef:
>> Dombo wrote:
>>> Op 21-May-11 16:08, MikeP schreef:
>>>> Juha Nieminen wrote:
>>>>> MikeP<mp011011@some.org>   wrote:
>>>>>> That seems like a juxtaposed statement, for it is C++ exceptions
>>>>>> that instigate the NEED for the RAII idiom. Without exceptions,
>>>>>> RAII is merely a convenience (still nice, but not
>>>>>> important/necessary).
>>>>>
>>>>>    I don't understand where this notion is coming from.
>>>>>
>>>>>    Even if exceptions were disabled (in many compilers you can
>>>>> disable them so that they will never be thrown) it would still be
>>>>> a nightmare to develop a large project without RAII.
>>>>>
>>>>
>>>> But not impossible. And creativity counts. Do/undo and keep
>>>> functions short (the C way) and then you're out of the realm of
>>>> "nightmare". (Not that I'm suggesting one do it that way).
>>>>
>>>>>    I would say the opposite of you: RAII is essential. The fact
>>>>> that it allows making code exception-safe is a nice side-effect,
>>>>> but not the main point.
>>>>
>>>> The scoped lifetime of classes on the stack is nifty, yes. I think
>>>> the RAII idiom necessarily brings in the exception stuff though.
>>>> It's the best way to do it, but not the only way (unless you turn
>>>> on the exception switch on the compiler). Constructors and
>>>> operators need exceptions, exceptions necessitate RAII... it's a
>>>> chain reaction of which there are at least a few of in the design
>>>> of C++.
>>>
>>> Several C++ compilers I have used in the early nineties didn't
>>> support exceptions at all, yet they did support constructors and
>>> destructors. In those days classes often had an initialize method
>>> or a method to check if the object was successfully constructed;
>>> not particularly elegant but at the end of the day it did get the
>>> job done. There certainly is a strong synergy between exceptions and 
>>> RAII in
>>> C++, the C++ language would have been a lot worse without one or the
>>> other. But without exceptions RAII would be still useful, whereas
>>> exceptions would be useless in C++ without RAII (unless something
>>> like a 'finally' clause were added to the language).
>>
>> Can there be "synergy" where there is a dependency? Doesn't the
>> dependency make it (exceptions + RAII) a singularity rather than
>> plurality?
>
> I have used C++ compilers which supported RAII but not exceptions (and
> even today you can disable exception support without disabling RAII on
> several C++ compilers), there are also quite a few programming
> languages which support exceptions but no RAII. So as far as 'm
> concerned RAII and exceptions are not mutually dependent in the sense
> that you cannot have one without the other.

I was asking [the group] in general about "synergy". But on the C++ 
topic, I was suggesting that C++ exceptions (not exceptions in general) 
depend on RAII. A one-way dependency rather than a mutual one. 

On 05/23/11 04:10 PM, MikeP wrote:
>
> I was asking [the group] in general about "synergy". But on the C++
> topic, I was suggesting that C++ exceptions (not exceptions in general)
> depend on RAII. A one-way dependency rather than a mutual one.

C++ exceptions depends on destructors.  Without destructors, some form 
of finally block is required.

RAII also depends on destructors.

-- 
Ian Collins

Ian Collins wrote:
> On 05/23/11 04:10 PM, MikeP wrote:
>>
>> I was asking [the group] in general about "synergy". But on the C++
>> topic, I was suggesting that C++ exceptions (not exceptions in
>> general) depend on RAII. A one-way dependency rather than a mutual
>> one.
>
> C++ exceptions depends on destructors.

Destructors that DO SOMETHING (RAII and other cleanup). Yes, the 
mechanics are related also, but the language (semantics) was really the 
point (I think!).

> Without destructors, some form
> of finally block is required.
>
> RAII also depends on destructors.

So what's your take on the synergy thing? Is there any in this case? Can 
there be synergy where there is dependency? 

On 05/23/11 04:38 PM, MikeP wrote:
> Ian Collins wrote:
>> On 05/23/11 04:10 PM, MikeP wrote:
>>>
>>> I was asking [the group] in general about "synergy". But on the C++
>>> topic, I was suggesting that C++ exceptions (not exceptions in
>>> general) depend on RAII. A one-way dependency rather than a mutual
>>> one.
>>
>> C++ exceptions depends on destructors.
>
> Destructors that DO SOMETHING (RAII and other cleanup). Yes, the
> mechanics are related also, but the language (semantics) was really the
> point (I think!).
>
>> Without destructors, some form
>> of finally block is required.
>>
>> RAII also depends on destructors.
>
> So what's your take on the synergy thing? Is there any in this case? Can
> there be synergy where there is dependency?

Buggered if I know, I'm an engineer, not a philosopher!

-- 
Ian Collins

"MikeP" <mp011011@some.org> wrote in news:ira50p$mjq$2@dont-email.me:

> Keith H Duggar wrote:
>> On May 21, 1:30 am, "MikeP" <mp011...@some.org> wrote:
>>> Keith H Duggar wrote:
>>>> [...] I would say that
>>>> the C++ automatic constructor/destructor paradigm (which was a C++
>>>> innovation as far as I know?) is also extremely valuable.
>>>
>>> Innovation? Looks like a quite nice and convenient side-effect.
>>
>> Side-effect of what?
> 
> Of the quest to make user-defined types behave like built-in types.

Built-in types don't have destructors, do they?

Paavo Helde wrote:
> "MikeP" <mp011011@some.org> wrote in news:ira50p$mjq$2@dont-email.me:
>
>> Keith H Duggar wrote:
>>> On May 21, 1:30 am, "MikeP" <mp011...@some.org> wrote:
>>>> Keith H Duggar wrote:
>>>>> [...] I would say that
>>>>> the C++ automatic constructor/destructor paradigm (which was a C++
>>>>> innovation as far as I know?) is also extremely valuable.
>>>>
>>>> Innovation? Looks like a quite nice and convenient side-effect.
>>>
>>> Side-effect of what?
>>
>> Of the quest to make user-defined types behave like built-in types.
>
> Built-in types don't have destructors, do they?

You're missing the point. To endow user-defined types (UDTs) with 
reasonable lifetime semantics, some kind of setup/teardown construct(s) 
are required. Constructors/destructors are more like a discovery than an 
invention. 

"Kai-Uwe Bux" <jkherciueh@gmx.net>
>>>> > The difference is that C if you want some thing to happen you must
>>>> > explicitly write code for it; what you see is what you get. In C++
>>>> > lots of things can happen because of an innocently looking statement
>>>> > or even when there is no code at all (destructors); you may very
>>>> > well get more than that you see.
>>>>
>> Seem like poor choice of words on my part.  I meant something like real
>> *practical* difference. A difference that leads to actual better/worse
>> software, more/less planted bugs etc.
>
> In terms of likelyhood of bugs, I think it's not so much a difference in
> total number of bugs per line but a difference in distribution. The error
> patterns will be different. The implicit coding style can help to avoid 
> many
> bugs. If you put clean up code in the destructor, it will be very hard to
> _not_ execute it at the appropriate point.

I definitely agree with different distribution. As theat "implicit" code the 
ctors and dtors are executed, with healthy guidelines you can say goodby to 
"uninitialized" and "leak" classes of bugs.  This IME is a huge source with 
great produce.  Do I get your assertion right: you claim that we get similar 
amount of other problems in the exchange?  My observation has big 
difference, I'd guss by 2 orders of magnitude or even more.

> Exceptions in templated code, on
> the other hand, can lurk at places where you don't espect them diverting
> control flow to a point determined by the type of the exception thrown 
> (and
> within a template, that can be an unknown type, whence the target of the
> jump is unknown, too).

I don't get this part. IME I write the big majority of C++ code as 
'exception transparent'.  It is a very rare case I bother to look at 
exception spec of any called stuff: just expect any letter may emit an 
exception.  (What may be close to reality too -- if the implementation just 
use a string as temporary, you immediately gain bad_alloc potentially.) 
While the situation where it actually matters is rare.  And in those rare 
situations you pay attention anyway.

This applies to any normal function.  How templates bring in anything 
fundamentally new?  You can't tell what T is and dependent stuff actually 
does -- but should you care more?   There are some special cases where you 
require a nothrow guarantee, say for dtors and swap() -- but it is the same 
for nontemplates.

May our observations differ due to difference in basic view of code: my 
based on 'any point is an exit; where we expect otherwise needs 
documentation' and you go the opposite thinking default is nothrow?

> On the other hand, not seeing those jumps written
> explicitly, can improve readability of the code; and having client code
> determine the target of the jump even allows for greater flexibility than
> goto -- whether that is good or bad, I guess, depends on the perspective.

The difference in readability is heaven and hell ;-).   With the insult 
added to injury that all the "alternate" paths execute only "exceptionally", 
but take over 80% of the source.  Just killing the possibility of 
abstraction. As instead of

DoSomething(par1, par2, par3);

that was the intention, at least you must write

if (DoSomething(par1, par2, par3))
  { some handling }

At every place in client code.  I rather not even start what proliferation 
occours if par1 above had a conversion, especially one involving memory 
allocation. Eg. in function argument was string but par1 was "Hello world".

It will create a bunch of implicit, inisible code -- constructing a 
temporary, destructing it, adding a throw point.  I do not deny the 
*possiblility* of surprise caused by any of those.

But if the intent was as written: call that very function with that very 
argument, the explicit mass of code would be there as well, as a noise 
making a 5 second review into a 5 minute one for that single command.   And 
if intent was different, the problem is not really in the implicit code --  
and I'd think with black noise stripped it is easier to discover.

Also, the correct, but "inefficient" code is normally preference to fast but 
buggy one; and we have great tools that count calls and elapsed time, so in 
the time you do not spend on hunting bugs it's possible to pay attention to 
the 2-3 spots where you can tune away a temporary.

> In terms of better/worse software, I do not see any evidence either way.

I recall Mike Howard stating in Writing Secure Code, that conversion to use 
*any* kind of "string class" instead of C counterpart lead to extreme drop 
of critical problems that lurked for years. i experienced a ton of evidence 
how RAII based code drops bug count (not only the immediately related ones), 
development time, and overall health of the project and its development.

> It
> seems that other factors are much more decisive. In the end, it's not the
> language alone but a tupel
>
>  (group of developers, languages used, toolchain, ...)
>
> that influences overall quality of the result.

If by that you mean that any language or language feature will not solve any 
problem (aka 'No silver bullets'), of course.

I think in assuming a good process with competent and motivated people. 
(meaning they know their tools whatever those are).  Having that, different 
tools and language features DO create a big difference.   Allowing to spend 
the programmers' time on writing the meat instead of hand-crafting all the 
"noise".

> This is not to say that
> changing a single element in the tupel does not have an effect. But in one
> setting going from C to C++ can boost the quality and in another setting 
> it
> can make things worse.

Well, if you take a working C team novive in C++ and just tell them to start 
writing C++ code, picking up featires along the way it is sure recipe for 
disaster. ;-)  You need competence.  No doubt, gaining it for C++ is way 
more work.  But the bright side is, it can be done with just a few C++ gurus 
put in charge, who mentor the others and review all the code until everyone 
is familiar wit the gotchas.


> Upshot:
> =======
> It think, for any particular project, there is a practical difference in
> choosing C++ or C or (insert other language here). Making the right choice
> will improve work flow and quality of the developed program. However, what
> the "right choice" is depends on many factors and the "right choice" is 
> not
> uniform.


Sure.

> I am not sure whether that qualifies as a "practical difference" in the
> sense of your question. But surely, choosing C++ or C is a consideration 
> of
> practical importance. I would, however, venture the following conjecture:
> whether the explicit/implicit distinction will have any seizable weight in
> choosing the language probably depends more on the developers involved 
> than
> the task at hand.

And we know all too well, that people will chose "the familiar way". 
Especially in stress.  Even in cases where they already learned that their 
familiar way is wrong in long and short term...

On May 23, 1:41=A0am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> "MikeP" <mp011...@some.org> wrote innews:ira50p$mjq$2@dont-email.me:
>
> > Keith H Duggar wrote:
> >> On May 21, 1:30 am, "MikeP" <mp011...@some.org> wrote:
> >>> Keith H Duggar wrote:
> >>>> [...] I would say that
> >>>> the C++ automatic constructor/destructor paradigm (which was a C++
> >>>> innovation as far as I know?) is also extremely valuable.
>
> >>> Innovation? Looks like a quite nice and convenient side-effect.
>
> >> Side-effect of what?
>
> > Of the quest to make user-defined types behave like built-in types.
>
> Built-in types don't have destructors, do they?

In C they have neither constructors nor destructors. They begin
life uninitialized (disregarding zero initialization of statics
which is a different matter) and they meet a silent trivial end.

KHD

On May 23, 2:02=A0am, "MikeP" <mp011...@some.org> wrote:
> Paavo Helde wrote:
> > "MikeP" <mp011...@some.org> wrote innews:ira50p$mjq$2@dont-email.me:
>
> >> Keith H Duggar wrote:
> >>> On May 21, 1:30 am, "MikeP" <mp011...@some.org> wrote:
> >>>> Keith H Duggar wrote:
> >>>>> [...] I would say that
> >>>>> the C++ automatic constructor/destructor paradigm (which was a C++
> >>>>> innovation as far as I know?) is also extremely valuable.
>
> >>>> Innovation? Looks like a quite nice and convenient side-effect.
>
> >>> Side-effect of what?
>
> >> Of the quest to make user-defined types behave like built-in types.
>
> > Built-in types don't have destructors, do they?
>
> You're missing the point. To endow user-defined types (UDTs) with
> reasonable lifetime semantics, some kind of setup/teardown construct(s)
> are required. Constructors/destructors are more like a discovery than an
> invention.

Presuming that you would agree C structs have "reasonable lifetime
semantics" and that they have no destructors, it seems to me quite
a stretch to say destructors were a "discovery".

Anyhow, whether they were a "discovery" or "innovation", C does not
have user defined automatic constructors/destructors. C++ does. And
to me that was a significant advance. One that proved more powerful
and useful than I'm guessing was even realized at the time.

KHD

In article <ir8hll$k7d$2@dont-email.me>, MikeP <mp011011@some.org> wrote:
>Juha Nieminen wrote:
>> MikeP <mp011011@some.org> wrote:
>>
>>> Indeed, I forego many of the C++
>>> "built-in" offerings for ones that I craft myself.
>>
>>  If you use your own tool instead of a standard tool even in
>> situations where the standard tool would be perfectly suited, that's
>> not very smart.
>
>Opinions vary. I note that you are an "in the paint" kind of guy: 
>"standards this... standards that". To each their own is what I say. 

"To each their own" is only valid if you write code only for
yourself.  If you are a professional programmer and are paid to write
code that will become the property of someone/something else and will
most likely need to be maintained in the future by someone else than
yourself, then using your own personal hand crafted tool when a
standard tool would be perfectly suited is demonstrably a bad thing. 

Yannick

In conclusion, the reason why a home is vastly inferior
to a skyscraper can be summarized with one single sentence:

A home has no support for supersonic elevators needed to go to floor 487.

You will never be able to rocket through 486 floors in 75.8 seconds
in a home. Never.

You may live better though.

:-)

none (Yannick Tremblay) wrote:
> In article <ir8hll$k7d$2@dont-email.me>, MikeP <mp011011@some.org>
> wrote:
>> Juha Nieminen wrote:
>>> MikeP <mp011011@some.org> wrote:
>>>
>>>> Indeed, I forego many of the C++
>>>> "built-in" offerings for ones that I craft myself.
>>>
>>>  If you use your own tool instead of a standard tool even in
>>> situations where the standard tool would be perfectly suited, that's
>>> not very smart.
>>
>> Opinions vary. I note that you are an "in the paint" kind of guy:
>> "standards this... standards that". To each their own is what I say.
>
> "To each their own" is only valid if you write code only for
> yourself.  If you are a professional programmer and are paid to write
> code that will become the property of someone/something else and will
> most likely need to be maintained in the future by someone else than
> yourself, then using your own personal hand crafted tool when a
> standard tool would be perfectly suited is demonstrably a bad thing.
>
> Yannick

Hey Yannick, I really don't have time for less than 10 points above my IQ 
(and EQ) AND 10 years my senior. 

Keith H Duggar wrote:
> On May 23, 2:02 am, "MikeP" <mp011...@some.org> wrote:
>> Paavo Helde wrote:
>>> "MikeP" <mp011...@some.org> wrote innews:ira50p$mjq$2@dont-email.me:
>>
>>>> Keith H Duggar wrote:
>>>>> On May 21, 1:30 am, "MikeP" <mp011...@some.org> wrote:
>>>>>> Keith H Duggar wrote:
>>>>>>> [...] I would say that
>>>>>>> the C++ automatic constructor/destructor paradigm (which was a
>>>>>>> C++ innovation as far as I know?) is also extremely valuable.
>>
>>>>>> Innovation? Looks like a quite nice and convenient side-effect.
>>
>>>>> Side-effect of what?
>>
>>>> Of the quest to make user-defined types behave like built-in types.
>>
>>> Built-in types don't have destructors, do they?
>>
>> You're missing the point. To endow user-defined types (UDTs) with
>> reasonable lifetime semantics, some kind of setup/teardown
>> construct(s) are required. Constructors/destructors are more like a
>> discovery than an invention.
>
> Presuming

On "presumption", yeah, I'm gonna write a book about that, "soon". Maybe 
I'll call it "C++ Gotchas", or something. Yeah, I'm gonna write that one. 
Maybe you are one of Eric Weis's minions? (Oh yeah, he got me "fair and 
square"). (For "the record": I don't hate him).

> that you would agree

I would "agree" (I think you will agree to this), that you should not get 
in my face and tell me what "would agree" upon. (Read: get the fuck out 
of my face, punk, I'm not your father).

> C structs have "reasonable lifetime
> semantics" and that they have no destructors, it seems to me quite
> a stretch to say destructors were a "discovery".

I'm a "language designer", in the sense that the "prevailing sense" makes 
no sense at all and I do it better. So I can't banter here with y'all 
language-lawyer-wannabes. You will live, you will die. You will have some 
span in between those 2 things. Those who want to establish a SUCK 3rd 
position, suck.

>
> Anyhow, whether they were a "discovery" or "innovation", C does not
> have user defined automatic constructors/destructors.

C does not have class objects.

> C++ does. And
> to me that was a significant advance.

You don't know "advance". "Youth is wasted on the young".  Why don't you 
go vote. I mean, fine. Vote. And while you are their, raise their flag 
(high). OOPs, the "FLAG", surely you know it. "Pledge of Allegience", 
recite now, so your computer file can be updated.

Test (note that willing participant who "answers", will be held liable 
for his "freedom of speech"):

What is a flag?

Is a flag rape?

Should flags be burned?

Do you feel raped by a flag?

Do you feel you will be draped by a flag?

Do flags rape?

jacob navia wrote:
> In conclusion, the reason why a home is vastly inferior
> to a skyscraper can be summarized with one single sentence:
>
> A home has no support for supersonic elevators needed to go to floor
> 487.
> You will never be able to rocket through 486 floors in 75.8 seconds
> in a home. Never.
>
> You may live better though.
>
> :-)

I owe you what? 

jacob navia wrote:
> In conclusion, the reason why a home is vastly inferior
> to a skyscraper can be summarized with one single sentence:
>
> A home has no support for supersonic elevators needed to go to floor
> 487.
> You will never be able to rocket through 486 floors in 75.8 seconds
> in a home. Never.
>
> You may live better though.
>
> :-)

Lament not your old age, lament those that politics will kill, if you 
observe the abhorance of killing people for someone else's cause. I am a 
person. And I hold all that came before me in contempt.

No I won't celebrate your killing. I will celebrate the death of your 
flag. Send someone to war? You got it comin. :P You do suck, anyone who 
imposes their will upon another. Time is not your friend if your "heart" 
is not true. Cry for those dead under your regime. Pfft. I cry that you 
continue that. 

On May 23, 9:18=A0pm, jacob navia <ja...@spamsink.net> wrote:
> In conclusion, the reason why a home is vastly inferior
> to a skyscraper can be summarized with one single sentence:
>
> A home has no support for supersonic elevators needed to go to floor 487.

Now, excuse me, I've got to go and work on getting the house standards
committee to give planning permission for this rickety, unsafe, steam-
powered 19th century escalator that I'm bolting to the outsides of my
house (I've put an emergency exit half way up - in case the whole
thing starts to collapse - but its the tenants job to provide enough
mattresses for a soft landing).  Because that's all the help anyone
will ever need to get upstairs.

/ Hey! That's not a car analogy. Minus 5 points.

In article <irfg4m$e42$1@dont-email.me>, MikeP <mp011011@some.org> wrote:
>none (Yannick Tremblay) wrote:
>> In article <ir8hll$k7d$2@dont-email.me>, MikeP <mp011011@some.org>
>> wrote:
>>> Juha Nieminen wrote:
>>>> MikeP <mp011011@some.org> wrote:
>>>>
>>>>> Indeed, I forego many of the C++
>>>>> "built-in" offerings for ones that I craft myself.
>>>>
>>>>  If you use your own tool instead of a standard tool even in
>>>> situations where the standard tool would be perfectly suited, that's
>>>> not very smart.
>>>
>>> Opinions vary. I note that you are an "in the paint" kind of guy:
>>> "standards this... standards that". To each their own is what I say.
>>
>> "To each their own" is only valid if you write code only for
>> yourself.  If you are a professional programmer and are paid to write
>> code that will become the property of someone/something else and will
>> most likely need to be maintained in the future by someone else than
>> yourself, then using your own personal hand crafted tool when a
>> standard tool would be perfectly suited is demonstrably a bad thing.
>>
>> Yannick
>
>Hey Yannick, I really don't have time for less than 10 points above my IQ 
>(and EQ) AND 10 years my senior. 
>

Sorry Mike but you started here having a discussion.  Some of the
points you raised are let's say controversial or at least not everyone
are in agreement with.  However, until your last few posts, you were
acting as a positive contributor attempting to have a worthwhile
technical discussion.  Your alternate point of view was actually
interesting and worthwhile to consider.

Have you decided that you were not interested in having a valid and
constructive technical discussion but would rather become a negative
contributor to this newsgroup?

Regards
Yannick

Joshua Maurice <joshuamaurice@gmail.com> wrote:
> On May 21, 10:57�pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>> � I still don't understand what this "template code bloat" is.
> 
> Imagine you have a container, such as std::vector. There are two basic
> ways to implement it, as C++ std::vector, or as you have to in C with
> void pointers, or as you would in Java with their equivalent of
> pointers eg: ArrayList.
> 
> It's a tradeoff. With the C approach (equivalently
> java.util.ArrayList), there is one piece of assembly corresponding to
> that function for all possible instantiations of the container class
> and for all possible contained types. With the std::vector approach,
> you can have a different piece of assembly in the object file for each
> different type used to instantiate the template. That is,
> std::vector<int> and std::vector<char> can (and usually will) be
> compiled down to different functions in the object file, distinguished
> by name mangling. Thus, the template way results in less instructions
> executed compared to the void pointer approach, but it results in
> larger executables.

  You chose a pretty poor example because it's so easy to refute.

  Firstly, consider the std::vector versus the C array containing void
pointers to the elements (which I suppose are each dynamically allocated
individually). The elements in the std::vector will be tightly packed
in memory into one single array. The C array will have a memory overhead
for each array element of one pointer plus whatever ancillary space the
memory allocator needs for each allocated block (which varies from 4 to 8
and even more bytes depending on the situation and architecture).

  Thus, any possible saving that there could be from having single
functions handling all arrays of the same type will be lost because of
the additional memory consumption of the data itself. The more elements
in the array, the more the memory consumption overhead will tilt to the
C side.

  This is especially so because the functions in std::vector tend to be
really small and inline very well. So well that many of the functions will
basically disappear completely because they will be fully merged into the
calling code. (For example, std::vector indexing will end up being completely
equivalent to indexing a raw array. Also std::vector iterators are usually
plain pointers. Hence there's no space difference depending on which type
is being used and how many there are. In other words, there will be no
space difference compared to a "generic" C implementation using void
pointers.)

  In fact, it might even happen that the std::vector version will, quite
ironically, produce a *smaller* executable than the "generic" C version
(because the compiler can inline better), even if more than one type is
being used. (No, I haven't tried this, but I wouldn't be surprised if that
was the case.)

  Add to this that there will also be speed overhead with the C version
that is not there in the std::vector version. Not only do accesses have
extra indirection steps, but allocating individual elements separately
will decrease data locality and increase memory fragmentation (not to
talk about the fact that allocation and deallocation is a quite slow
operation). Even if the executable binary was smaller, any cache benefits
resulting from this could well be nullified by the cache unfriendliness of
the data being handled.

  Even if the templated version produced larger binaries, how much larger,
compared to an equivalent implementation without templated code? Can we
honestly talk about "bloat"?

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>  When code is smaller, the chance is greater that it might fit in some
>  cache, which will make it execute much faster.

  Just because the executable is larger overall doesn't mean that the
functions are larger.

Juha Nieminen <nospam@thanks.invalid> writes:
>Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>When code is smaller, the chance is greater that it might fit in some
>>cache, which will make it execute much faster.
>Just because the executable is larger overall doesn't mean that the
>functions are larger.

  In this case, there must be many small functions. Since
  functions usually call each other, they might have to be
  swapped in and swapped out of the limited cache.

  Would there only be few small functions, all of them would
  fit into the limited cache.

On 24/05/2011 17:13, Stefan Ram wrote:
> Juha Nieminen<nospam@thanks.invalid>  writes:
>> Stefan Ram<ram@zedat.fu-berlin.de>  wrote:
>>> When code is smaller, the chance is greater that it might fit in some
>>> cache, which will make it execute much faster.
>> Just because the executable is larger overall doesn't mean that the
>> functions are larger.
>
>    In this case, there must be many small functions. Since
>    functions usually call each other, they might have to be
>    swapped in and swapped out of the limited cache.
>
>    Would there only be few small functions, all of them would
>    fit into the limited cache.
>

Yes but haven't you heard that old adage that 5% of the code is executed 
95% of the time?  One only has to worry about that 5% which likely would 
fit in the cache.

Remember: premature optimization is the root of all evil.

/Leigh

Stefan Ram wrote:

> When code is smaller, the chance is greater that it might fit in some
> cache, which will make it execute much faster.

Not necessarily.

http://en.wikipedia.org/wiki/Belady%27s_anomaly


Rui Maciel

On May 24, 7:42=A0pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> Stefan Ram wrote:
> > When code is smaller, the chance is greater that it might fit in some
> > cache, which will make it execute much faster.
>
> Not necessarily.
>
> http://en.wikipedia.org/wiki/Belady%27s_anomaly
>
> Rui Maciel

That's not very relevant as I don't think a FIFO is very popular
replacement strategy for cache.

hanukas wrote:

> That's not very relevant as I don't think a FIFO is very popular
> replacement strategy for cache.

I believe you didn't quite understood it.  The main point, which Belady's 
anomaly demonstrates, is that there isn't necessarily a direct correlation 
between how much cache a program takes up and the number of cache misses. 
If it isn't possible to assume a direct correlation between how much cache 
a program takes up and the number of cache misses then it isn't possible 
to claim that a specific variation in a program's size has a specific 
impact on how fast a program is ran.  If the subject being discussed is 
the relation between a program's size and the influence that size may have 
on how fast that program runs, particularly due to the number of cache 
misses it generates, then it is obviously relevant.


Rui Maciel

Le 25/05/11 12:15, Rui Maciel a �crit :
> hanukas wrote:
>
>> That's not very relevant as I don't think a FIFO is very popular
>> replacement strategy for cache.
>
> I believe you didn't quite understood it.  The main point, which Belady's
> anomaly demonstrates, is that there isn't necessarily a direct correlation
> between how much cache a program takes up and the number of cache misses.
> If it isn't possible to assume a direct correlation between how much cache
> a program takes up and the number of cache misses then it isn't possible
> to claim that a specific variation in a program's size has a specific
> impact on how fast a program is ran.  If the subject being discussed is
> the relation between a program's size and the influence that size may have
> on how fast that program runs, particularly due to the number of cache
> misses it generates, then it is obviously relevant.
>
>
> Rui Maciel

Yes, you are right in principle. It is conceivable that a huge
program uses only a small fraction of its executable foot print
and all of it fits in the cache.

It is also conceivable that a program has a huge footprint but
it has almost no jumps so that its cache misses are exceptionally
low because when code is loaded all of it is used in highly
efficient loops.

And there could be more of those situations.

ALl I can tell you is that in my experience both the above
cases aren't found "in nature"...

What I did find of course, is that huge programs tend to
trash around a lot jumping from one small method to the
next one...

THAT is surely a common observation.

jacob

On May 25, 12:07=A0pm, jacob navia <ja...@spamsink.net> wrote:

> What I did find of course, is that huge programs tend to
> trash around a lot jumping from one small method to the
> next one...
>
> THAT is surely a common observation.

Yup. That sounds about right.

Leigh Johnston <leigh@i42.co.uk> writes:
>Remember: premature optimization is the root of all evil.

  The whole point of C++ is premature optimization, otherwise
  one would use a programming language that is more safe,
  simple, portable, and powerful.

  I leave it up to you to decide whether this means that
  C++ is the root of all evil.

On 25/05/2011 13:52, Stefan Ram wrote:
> Leigh Johnston<leigh@i42.co.uk>  writes:
>> Remember: premature optimization is the root of all evil.
>
>    The whole point of C++ is premature optimization, otherwise
>    one would use a programming language that is more safe,
>    simple, portable, and powerful.
>
>    I leave it up to you to decide whether this means that
>    C++ is the root of all evil.

Nonsense.

HTH.

/Leigh

Stefan Ram wrote:

> The whole point of C++ is premature optimization

Why do you believe that "the whole point of C++ is premature 
optimization"?  


Rui Maciel

On May 25, 1:52=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Leigh Johnston <le...@i42.co.uk> writes:
> >Remember: premature optimization is the root of all evil.
>
> =A0 The whole point of C++ is premature optimization, otherwise
> =A0 one would use a programming language that is more safe,
> =A0 simple, portable, and powerful.

I don't think you comprehend what "premature" means.

jacob navia wrote:

> Yes, you are right in principle. It is conceivable that a huge
> program uses only a small fraction of its executable foot print
> and all of it fits in the cache.
> 
> It is also conceivable that a program has a huge footprint but
> it has almost no jumps so that its cache misses are exceptionally
> low because when code is loaded all of it is used in highly
> efficient loops.
> 
> And there could be more of those situations.
> 
> ALl I can tell you is that in my experience both the above
> cases aren't found "in nature"...
> 
> What I did find of course, is that huge programs tend to
> trash around a lot jumping from one small method to the
> next one...
> 
> THAT is surely a common observation.

The reference to Belady's anomaly is based on the unavoidable fact that we 
must deal with cache misses, which means that it applies to the cases we 
do find, as you've put it, "in nature".

Based on that, what the Belady's anomaly shows us is that there isn't 
necessarily a direct correlation between the number of page frames which 
are used and the number of cache misses.  This observation is independent 
of what programs are running, and therefore how they jump around from one 
method to another.  No matter how common that observation is, from that 
observation alone is still not possible to claim that the size of a 
program is directly correlated to the number of cache misses, and 
therefore how fast it is executed.


Rui Maciel

Rui Maciel <rui.maciel@gmail.com> writes:
>Stefan Ram wrote:
>>The whole point of C++ is premature optimization
>Why do you believe that "the whole point of C++ is premature 
>optimization"?

  Design decision in C++ are usually decided in favor of
  run-time efficiency.

  For example, Java has decided to check array indices
  at runtime, C++ not to.

      �Learning C++ is equivalent to studying to be a NASA
      test pilot. Its incredibly fast and effective, but takes
      years to master the arcania and things tend to blowup in
      your face if you're not very careful.� 

    Shinji Ikari

      �I would rather compare it to learning how to drive a
      racecar: yes, it can be fast. Most people tend to drive
      it off track right away. Some people die in it.�

    Matthias Blume 

  OOP: bind as /late/ as possible
  C++: bind as /early/ as possible (generic programming)

  Since this optimization is /always/ done, by pure /choice of
  the language/, it can be called premature.

On May 25, 1:15=A0pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> hanukas wrote:
> > That's not very relevant as I don't think a FIFO is very popular
> > replacement strategy for cache.
>
> I believe you didn't quite understood it. =A0The main point, which Belady=
's
> anomaly demonstrates, is that there isn't necessarily a direct correlatio=
n
> between how much cache a program takes up and the number of cache misses.
> If it isn't possible to assume a direct correlation between how much cach=
e
> a program takes up and the number of cache misses then it isn't possible
> to claim that a specific variation in a program's size has a specific
> impact on how fast a program is ran. =A0If the subject being discussed is
> the relation between a program's size and the influence that size may hav=
e
> on how fast that program runs, particularly due to the number of cache
> misses it generates, then it is obviously relevant.
>
> Rui Maciel

In that case you choice of example algorithm to demonstrate the case
was not the best possible one; it only demonstrates paradox with FIFO.

On May 25, 5:52=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Leigh Johnston <le...@i42.co.uk> writes:
> >Remember: premature optimization is the root of all evil.
>
> =A0 The whole point of C++ is premature optimization, otherwise
> =A0 one would use a programming language that is more safe,
> =A0 simple, portable, and powerful.
>
> =A0 I leave it up to you to decide whether this means that
> =A0 C++ is the root of all evil.

The whole point of C++ is not premature optimization. One of its major
design goals, inherited from C, is to be a portable general purpose
assembly language. Part of that design goal is indeed optimization. If
that is premature depends on the particular program. While I'm always
a fan of measuring first, optimizing second, that maxim has its
limits. One is not going to write an OS in Ruby just to profile it and
rewrite the important parts in C. Writing software just doesn't work
that way. Sometimes choosing things up front for performance
considerations is /not/ premature. A classic example is you have to
decide pretty early if you want a single threaded, multi-threaded, or
distributed, application as that will have big impacts on your design
and code.

On May 26, 2:39=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Rui Maciel <rui.mac...@gmail.com> writes:
> >Stefan Ram wrote:
> >>The whole point of C++ is premature optimization
> >Why do you believe that "the whole point of C++ is premature
> >optimization"?
>
> =A0 Design decision in C++ are usually decided in favor of
> =A0 run-time efficiency.
>
> =A0 For example, Java has decided to check array indices
> =A0 at runtime, C++ not to.
>
> =A0 =A0 =A0 =BBLearning C++ is equivalent to studying to be a NASA
> =A0 =A0 =A0 test pilot. Its incredibly fast and effective, but takes
> =A0 =A0 =A0 years to master the arcania and things tend to blowup in
> =A0 =A0 =A0 your face if you're not very careful.=AB
>
> =A0 =A0 Shinji Ikari
>
> =A0 =A0 =A0 =BBI would rather compare it to learning how to drive a
> =A0 =A0 =A0 racecar: yes, it can be fast. Most people tend to drive
> =A0 =A0 =A0 it off track right away. Some people die in it.=AB
>
> =A0 =A0 Matthias Blume
>
> =A0 OOP: bind as /late/ as possible
> =A0 C++: bind as /early/ as possible (generic programming)
>
> =A0 Since this optimization is /always/ done, by pure /choice of
> =A0 the language/, it can be called premature.

You have to separate run-time from coding time:

Yes, you are right if you *only* consider run-time.
The binding that happens at run-time, through virtual
functions, in Java can also happen (but needs not) at
compile time, through templates, in C++.

But what's the problem with that? If the designer
*knows* at design time (prior to compile time) what
the application is supposed to do, what's the problem
with him using template code? Why force him to make
do with slow, lesser type-safe virtual functions if
a robust, fast alternative exists?

Of course, if some decision is made during program
execution what method or class to use, then the
late-binding virtual function is the correct tool to use.

But that's a different situation than the designer knowing
at design time what the program needs to do.

Rune

"Stefan Ram" <ram@zedat.fu-berlin.de>

>      �Learning C++ is equivalent to studying to be a NASA
>      test pilot. Its incredibly fast and effective, but takes
>      years to master the arcania and things tend to blowup in
>      your face if you're not very careful.�
>
>    Shinji Ikari
>
>      �I would rather compare it to learning how to drive a
>      racecar: yes, it can be fast. Most people tend to drive
>      it off track right away. Some people die in it.�
>
>    Matthias Blume

Quite true. But leads to the wrong implications. AAMOF the other languages 
are not different, if you want to do actual industry stuff and not just 
play.

Unfortunatley the most common approach to programming is still  hacking away 
before/instead of  learning, and "trial an error".    With C or C++ it will 
blow your leg spectacularly.  With other languages you more likely get some 
error report.

But you still drive it off track, and keep it that way. And the difference 
will be in whjat people "die" -- you push the problem on the client.

It would be time to face that software architecture is HARD. And that the 
idea of uncle Fred writing his own fish shop software as presented in the 
famous dBase III book will never happen. Regardless what languages and 
environments are there.  And working stuff needs huge amount of using brains 
and discipline. 

On May 26, 1:39=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Rui Maciel <rui.mac...@gmail.com> writes:
> >Stefan Ram wrote:
> >>The whole point of C++ is premature optimization
> >Why do you believe that "the whole point of C++ is premature
> >optimization"?
>
> =A0 Design decision in C++ are usually decided in favor of
> =A0 run-time efficiency.
>
> =A0 For example, Java has decided to check array indices
> =A0 at runtime, C++ not to.

Really? What does .at() do?

> =A0 OOP: bind as /late/ as possible
> =A0 C++: bind as /early/ as possible (generic programming)

That's an statement utterly unsupported by reality. Are you suggesting
C++ doesn't allow OOP?

> =A0 Since this optimization is /always/ done,

Which optimisation? Early binding is done where possible, late binding
is done where necessary. Where's the optimisation.

On 26 mai, 02:39, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Rui Maciel <rui.mac...@gmail.com> writes:
> >Stefan Ram wrote:
> >>The whole point of C++ is premature optimization
> >Why do you believe that "the whole point of C++ is premature
> >optimization"?
>
> =A0 Design decision in C++ are usually decided in favor of
> =A0 run-time efficiency.

Design decision in C++ are nearly always driven by "you don't pay for
what you don't need".

IMO, this is not premature optimisation, it is common sense. Even
though, there is a trade-off with scalability of compiler extension
(such as array indices check).

> =A0 For example, Java has decided to check array indices
> =A0 at runtime, C++ not to.

Is it explicitly forbidden by the standard ?
I thought it was up to the compiler to provide it or not. IIRC Visual
has the option.

Java doesn't let you the choice.

> =A0 =A0 =A0 =BBLearning C++ is equivalent to studying to be a NASA
> =A0 =A0 =A0 test pilot. Its incredibly fast and effective, but takes
> =A0 =A0 =A0 years to master the arcania and things tend to blowup in
> =A0 =A0 =A0 your face if you're not very careful.=AB
>
> =A0 =A0 Shinji Ikari

I call that 'harnessing power'.

> =A0 =A0 =A0 =BBI would rather compare it to learning how to drive a
> =A0 =A0 =A0 racecar: yes, it can be fast. Most people tend to drive
> =A0 =A0 =A0 it off track right away. Some people die in it.=AB
>
> =A0 =A0 Matthias Blume

Well, the learning curve is hard. Much more so if you have a C
background.

> =A0 OOP: bind as /late/ as possible
> =A0 C++: bind as /early/ as possible (generic programming)

Are you talking about "name binding" vs "early bound method call" or
"compile time" vs "run time" ?

> =A0 Since this optimization is /always/ done, by pure /choice of
> =A0 the language/, it can be called premature.

Except if I work on a Java processor (or a LISP machine for that
matter).

And more generally, it depends on what you want to achieve, the
context, the domain, the scale of the software, the tools and all the
ilities driving the design.

I wonder how many times C++ is chosen for its performances; do you
have numbers ?

--
Michael

On May 25, 5:39=A0pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> =A0 =A0 =A0 =BBLearning C++ is equivalent to studying to be a NASA
> =A0 =A0 =A0 test pilot. Its incredibly fast and effective, but takes
> =A0 =A0 =A0 years to master the arcania and things tend to blowup in
> =A0 =A0 =A0 your face if you're not very careful.=AB
>
> =A0 =A0 Shinji Ikari

Do you have a source or citation of some kind for this quote, where it
was first said? I'm just kind of curious curious for no particular
reason at all.

On 26 mai, 08:39, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On May 25, 5:52=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> > Leigh Johnston <le...@i42.co.uk> writes:
> > >Remember: premature optimization is the root of all evil.
>
> > =A0 The whole point of C++ is premature optimization, otherwise
> > =A0 one would use a programming language that is more safe,
> > =A0 simple, portable, and powerful.
>
> > =A0 I leave it up to you to decide whether this means that
> > =A0 C++ is the root of all evil.
>
> The whole point of C++ is not premature optimization. One of its major
> design goals, inherited from C, is to be a portable general purpose
> assembly language.

While the simplification seems to work, I don't buy that. C was first
designed as a *tool* for abstracting the underlying assembly language
but it has since evolved into a *language* that generates an
executable code.

We use our vocal cords (and our hands :) ) to communicate but it is
the language that carries the meaning.

The difference might be philosophical but I think it is important.

> Part of that design goal is indeed optimization. If
> that is premature depends on the particular program. While I'm always
> a fan of measuring first, optimizing second, that maxim has its
> limits. One is not going to write an OS in Ruby just to profile it and
> rewrite the important parts in C.

I can write it in ruby and the use a ruby-to-bytecode tool (or a ruby-
to-C if it does not exists for my platform). Well, I theory.

IIRC there was some talk about an OS (from MS) which support
inspection and reflexion.

> Writing software just doesn't work
> that way. Sometimes choosing things up front for performance
> considerations is /not/ premature. A classic example is you have to
> decide pretty early if you want a single threaded, multi-threaded, or
> distributed, application as that will have big impacts on your design
> and code.

While there are some tension between some design values and optimality
of execution (see "Spending Moore's Dividend"), the two are not
necessarily exclusives.
IMHO the bet of C++ is to provide a language that scales from high
level requirements (modularity, policies, ...) down to low level next
to the metal. Some things don't have to be decided up-front but can be
delegated to higher-level policy without performance loss.

--
Michael

"Michael Doubez" <michael.doubez@free.fr>

>> For example, Java has decided to check array indices
>> at runtime, C++ not to.

>Is it explicitly forbidden by the standard ?
>I thought it was up to the compiler to provide it or not. IIRC Visual
>has the option.

If we're talking about std::vector, it has .at()  that checks and throws. It 
has [] that makes oob access undefined behavior. Allowing implementation to 
dfine it as no-op, as throw, as anything. What most implementations use for 
diagnostics in debug build and no code in release.

>Java doesn't let you the choice.

Yep. There is only one java way decided upward, puny programmers shall not 
mess with decisions :-o

Indeed, Java seem to be created for "idiots" assumong that if they are 
placed in a sandbox they will be productive.  I didn't see much good coming 
out of that experiment, just the expected gargabe in - garbage out.

And the few unfortunate sould who are out to do good job have to fight their 
way against the wind.

On Thu, 2011-05-26, Stefan Ram wrote:
> Rui Maciel <rui.maciel@gmail.com> writes:
>>Stefan Ram wrote:
>>>The whole point of C++ is premature optimization
>>Why do you believe that "the whole point of C++ is premature 
>>optimization"?
....
>   Since this optimization is /always/ done, by pure /choice of
>   the language/, it can be called premature.

One day I'm going to have to write a paper called
"The phrase 'premature optimization' considered harmful" ...

/Jorgen,
only half joking

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

On May 26, 1:53=A0am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Thu, 2011-05-26, Stefan Ram wrote:
> > Rui Maciel <rui.mac...@gmail.com> writes:
> >>Stefan Ram wrote:
> >>>The whole point of C++ is premature optimization
> >>Why do you believe that "the whole point of C++ is premature
> >>optimization"?
> ...
> > =A0 Since this optimization is /always/ done, by pure /choice of
> > =A0 the language/, it can be called premature.
>
> One day I'm going to have to write a paper called
> "The phrase 'premature optimization' considered harmful" ...

I'd fund it.

On May 26, 10:31=A0am, gwowen <gwo...@gmail.com> wrote:
> On May 26, 1:39=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>
> > Rui Maciel <rui.mac...@gmail.com> writes:
> > >Stefan Ram wrote:
> > >>The whole point of C++ is premature optimization
> > >Why do you believe that "the whole point of C++ is premature
> > >optimization"?
>
> > =A0 Design decision in C++ are usually decided in favor of
> > =A0 run-time efficiency.
>
> > =A0 For example, Java has decided to check array indices
> > =A0 at runtime, C++ not to.
>
> Really? What does .at() do?

Doesn't look like array index to me.

On May 26, 12:53=A0pm, hanukas <ju...@liimatta.org> wrote:
> > Really? What does .at() do?
>
> Doesn't look like array index to me.

No, it doesn't LOOK like an array index.  Nevertheless, it *is* an
array index. And offering a checked and unchecked indexing doesn't
strike me as an optimisation at all, premature or otherwise.

http://www.cplusplus.com/reference/stl/vector/operator%5B%5D/
http://www.cplusplus.com/reference/stl/vector/at/

On May 26, 4:53=A0am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Thu, 2011-05-26, Stefan Ram wrote:
> > Rui Maciel <rui.mac...@gmail.com> writes:
> >>Stefan Ram wrote:
> >>>The whole point of C++ is premature optimization
> >>Why do you believe that "the whole point of C++ is premature
> >>optimization"?
> ...
> > =A0 Since this optimization is /always/ done, by pure /choice of
> > =A0 the language/, it can be called premature.
>
> One day I'm going to have to write a paper called
> "The phrase 'premature optimization' considered harmful" ...

Thank you. That phrase is being used by the ignorant masses in
a manner only marginally less moronic than "conservatives want
to starve autistic children to death".

KHD

On 5/16/2011 12:25 PM, Juha Nieminen wrote:
> Lynn McGuire<lmc@winsim.com>  wrote:
>> Why C++ is vastly superior to C:
>>      http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>
>    I'm glad I'm not writing those articles just for myself... :)

Congrats on an interesting topic to this forum.

Lynn

gwowen <gwowen@gmail.com> writes:
>>For example, Java has decided to check array indices
>>at runtime, C++ not to.
>Really? What does .at() do?

  It does not apply to arrays.

>Are you suggesting C++ doesn't allow OOP?

  In 2003, I asked Alan Kay, who coined the term
  �object-oriented programming�, what this means.
  He kindly answered:

      �OOP to me means only messaging, local retention and
      protection and hiding of state-process, and extreme
      late-binding of all things. It can be done in Smalltalk
      and in LISP. There are possibly other systems in which
      this is possible, but I'm not aware of them.�

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

>>Since this optimization is /always/ done,
>Which optimisation? Early binding is done where possible,
>late binding is done where necessary. Where's the
>optimisation.

  The optimization is that the language had to become larger
  and more complex to allow this gain of efficiency.

On Thu, 26 May 2011 00:31:30 -0700, gwowen wrote:

>>   For example, Java has decided to check array indices
>>   at runtime, C++ not to.
> 
> Really? What does .at() do?

Checks vector indices. Vectors aren't arrays (and the default
indexing operation, operator[], doesn't do bounds-checking).

"Nobody" <nobody@nowhere.com>

>>> For example, Java has decided to check array indices
>>> at runtime, C++ not to.
>> 
>> Really? What does .at() do?
> 
> Checks vector indices. Vectors aren't arrays (and the default
> indexing operation, operator[], doesn't do bounds-checking).

Err, exactly what makes it *default*?

Michael Doubez <michael.doubez@free.fr> writes:
>>OOP: bind as /late/ as possible
>>C++: bind as /early/ as possible (generic programming)
>Are you talking about "name binding" vs "early bound method call" or
>"compile time" vs "run time" ?

  �Late� means to me: the decision which function body to call
  is made depending on the run-time type of the participating
  objects. (I guess, I would also have to require multimethods, 
  then. But multimethod lookup also has its drawbacks [complexity].)

  Run-time polymorphism is possible in C++ (at least for one
  object in an expression), but the C++ standard library is
  based on templates. (I have not yet studied whether this
  makes OOP harder in C++.)

  In a real OOP language, like Smalltalk, blocks of statements
  are also objects. This means, for example, one can define an
  if method (in Smalltalk) as a method taking a boolean and a
  block (of statements), then passing the block to the
  boolean, where boolean objects of the class True execute
  their blocks, while those of the class False do not. This
  requires late binding, because the class of (x<y) is only
  known as late as at run time (it might be the subclass True
  of the class Boolean or the subclass False).

  In C++, �if� is not a method at all, but a keyword
  hard-coded in the programming language. (Possibly, in
  Smalltalk, if also is hard-coded. But it could be defined as
  described in the preceding paragraph.)

  But maybe C++0x is getting closer to Smalltalk and LISP with
  its new closure objects!

>I wonder how many times C++ is chosen for its performances;
>do you have numbers ?

  No, but since C++ is very complex, there must be some reason
  to use in instead of languages more simple and secure, so
  performance is a good candidate. 

On Thu, 26 May 2011 00:39:59 +0000, Stefan Ram wrote:

>>>The whole point of C++ is premature optimization
>>Why do you believe that "the whole point of C++ is premature 
>>optimization"?
> 
>   Design decision in C++ are usually decided in favor of
>   run-time efficiency.

>   Since this optimization is /always/ done, by pure /choice of
>   the language/, it can be called premature.

Only if you're really desperate to make a "premature optimisation"
argument.

The alternative, i.e. to use a higher-level but less efficient language,
results in the optimisation never being performed at all, even in the
finished product.

Some optimisations must inherently be performed at the outset, if they are
to be performed at all. If you adopt an approach which is structurally
inefficient, then the only way to get rid of the inefficiency is to start
over with a more efficient structure. That doesn't make such optimisations
"premature".

Premature optimisation means performing "optimisations" before you have
sufficient knowledge to determine what is actually optimal.

This is primarily a problem with "code first, design later" development,
where you don't really know what you should be doing until you have a
working prototype (either because the problem isn't amenable to structured
development, or the programmer isn't).

OTOH, if you have a good understanding of the problem, it's entirely
possible (and reasonable) to make optimisation decisions long before you
start writing code.

On May 26, 9:55=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >Are you suggesting C++ doesn't allow OOP?
>
> =A0 In 2003, I asked Alan Kay, who coined the term
> =A0 =BBobject-oriented programming=AB, what this means.
> =A0 He kindly answered:
>
> =A0 =A0 =A0 =BBOOP to me means only messaging, local retention and
> =A0 =A0 =A0 protection and hiding of state-process, and extreme
> =A0 =A0 =A0 late-binding of all things. It can be done in Smalltalk
> =A0 =A0 =A0 and in LISP. There are possibly other systems in which
> =A0 =A0 =A0 this is possible, but I'm not aware of them.=AB
>
> http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

I've been here before.

http://c2.com/cgi/wiki?DefinitionsForOo
http://c2.com/cgi/wiki?IsCeePlusPlusObjectOriented

This is nothing new, and I otherwise have nothing new to add to this
silly discussion.

Joshua Maurice <joshuamaurice@gmail.com> writes:
>On May 25, 5:39�pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>>�Learning C++ is equivalent to studying to be a NASA
>>test pilot. Its incredibly fast and effective, but takes
>>years to master the arcania and things tend to blowup in
>>your face if you're not very careful.�
>>Shinji Ikari
>Do you have a source or citation of some kind for this quote, where it
>was first said? I'm just kind of curious curious for no particular
>reason at all.

  My source is

Message-ID: <8cd70836.0307221922.5c355605@posting.google.com>
From: shinji@swirve.com (Shinji Ikari)
Newsgroups: comp.theory.cell-automata,comp.lang.java.advocacy,comp.lang.scheme,comp.lang.misc
Subject: Re: Cellular automata benchmarks: Java vs C++ vs Java vs C++
Date: 22 Jul 2003 22:33:27 -0700

On Thu, 26 May 2011 19:10:12 +0200, Balog Pal wrote:

>>>> For example, Java has decided to check array indices
>>>> at runtime, C++ not to.
>>> 
>>> Really? What does .at() do?
>> 
>> Checks vector indices. Vectors aren't arrays (and the default
>> indexing operation, operator[], doesn't do bounds-checking).
> 
> Err, exactly what makes it *default*?

It's the "natural" indexing operation. The one that has dedicated syntax
rather than being a normal method. The one you'll end up using if you
convert C code to C++ with minimal re-writing.

On May 27, 2:15=A0am, Nobody <nob...@nowhere.com> wrote:
> On Thu, 26 May 2011 19:10:12 +0200, Balog Pal wrote:
> >>>> For example, Java has decided to check array indices
> >>>> at runtime, C++ not to.
>
> >>> Really? What does .at() do?
>
> >> Checks vector indices. Vectors aren't arrays (and the default
> >> indexing operation, operator[], doesn't do bounds-checking).
>
> > Err, exactly what makes it *default*?
>
> It's the "natural" indexing operation. The one that has dedicated syntax
> rather than being a normal method. The one you'll end up using if you
> convert C code to C++ with minimal re-writing.

Good C code has the bounds under explicit control anyway. Crap C is
not worth converting. So what is your issue?

Stefan Ram wrote:

> Design decision in C++ are usually decided in favor of
> run-time efficiency.
> 
> For example, Java has decided to check array indices
> at runtime, C++ not to.
> 
> »Learning C++ is equivalent to studying to be a NASA
> test pilot. Its incredibly fast and effective, but takes
> years to master the arcania and things tend to blowup in
> your face if you're not very careful.«

What does this quote have to do with your statement on premature 
optimization?


> »I would rather compare it to learning how to drive a
> racecar: yes, it can be fast. Most people tend to drive
> it off track right away. Some people die in it.«

Again, what does this quote have to do with your statement on premature 
optimization?


> OOP: bind as /late/ as possible
> C++: bind as /early/ as possible (generic programming)

Again, what does this quote have to do with your statement on premature 
optimization?


> Since this optimization is /always/ done, by pure /choice of
> the language/, it can be called premature.

You clearly don't understand what premature optimization means.


Rui Maciel

Nobody wrote:

> Premature optimisation means performing "optimisations" before you have
> sufficient knowledge to determine what is actually optimal.

It's a bit more than that, as it also implies wasting human resources 
(man*hour) in a futile task which provides questionable performance 
improvements and ends up making it harder to develop and maintain the 
code.  So, considering this, compiling a program which is still in alpha 
stage with the -O3 flag obviously isn't premature optimization.  Nor using 
CPP macros.  Nor using templates.  Nor using inline functions.


Rui Maciel

Stefan Ram wrote:

> My source is
> 
> Message-ID: <8cd70836.0307221922.5c355605@posting.google.com>
> From: shinji@swirve.com (Shinji Ikari)
> Newsgroups:
> comp.theory.cell-
automata,comp.lang.java.advocacy,comp.lang.scheme,comp.lang.misc
> Subject: Re: Cellular automata benchmarks: Java vs C++ vs Java vs C++
> Date: 22 Jul 2003 22:33:27 -0700

When people quote someone, they do it with the hope that the aura of 
authority that emits from that specific person is enough to force others 
to simply swallow a statement without exercizing the faintest attempt at 
critical thinking.  You don't benefit from that by quoting some random 
usenet post made by some anonymous person who posted a random message 8 
years ago under a pseudonim inspired by an anime series.  


Rui Maciel

Nobody wrote:

> It's the "natural" indexing operation. The one that has dedicated syntax
> rather than being a normal method. The one you'll end up using if you
> convert C code to C++ with minimal re-writing.

As operator overloading amounts to nothing more than syntax sugar, a 
method is as "natural" as a call to any operator defined for that class, 
including the array subscript operator.


Rui Maciel

On May 27, 12:15=A0am, Nobody <nob...@nowhere.com> wrote:

> It's the "natural" indexing operation. The one that has dedicated syntax
> rather than being a normal method.

So, what you're saying is "C++ doesn't do bounds checking if you're
too lazy to you ask it to."

>The one you'll end up using if you  convert C code to C++ with minimal re-=
writing.

So, you're bad/lazy at porting, and seemingly don't know how to do a
regex-replace.  How is this a problem with C++? You get the choice of
checked and unchecked, and you're complaining that the checked one
requires too much typing? (Also your implementation probably provides
a switch to access a bounds-checked operator[].)

On May 26, 3:24=A0pm, gwowen <gwo...@gmail.com> wrote:
> On May 26, 12:53=A0pm, hanukas <ju...@liimatta.org> wrote:
>
> > > Really? What does .at() do?
>
> > Doesn't look like array index to me.
>
> No, it doesn't LOOK like an array index. =A0Nevertheless, it *is* an
> array index. And offering a checked and unchecked indexing

I'm fairly confident that it is a method of a class. I wouldn't be
surprised to find out that C++ was Turing Complete.

On May 27, 9:32=A0am, hanukas <ju...@liimatta.org> wrote:
> On May 26, 3:24=A0pm, gwowen <gwo...@gmail.com> wrote:
>
> > On May 26, 12:53=A0pm, hanukas <ju...@liimatta.org> wrote:
>
> > > > Really? What does .at() do?
>
> > > Doesn't look like array index to me.
>
> > No, it doesn't LOOK like an array index. =A0Nevertheless, it *is* an
> > array index. And offering a checked and unchecked indexing
>
> I'm fairly confident that it is a method of a class. I wouldn't be
> surprised to find out that C++ was Turing Complete.

I'll skip one iteration to save everyone's time. at() is a method of
class std::vector, for example. It's a method of a class. That's
great, but I was (indirectly) commenting on this:

"For example, Java has decided to check array indices at runtime, C++
not to. "

So, array indices =3D=3D std::vector? I stand corrected, thank you
internet.

On Fri, 27 May 2011 00:57:04 +0100, Rui Maciel wrote:

>> It's the "natural" indexing operation. The one that has dedicated syntax
>> rather than being a normal method. The one you'll end up using if you
>> convert C code to C++ with minimal re-writing.
> 
> As operator overloading amounts to nothing more than syntax sugar,

Use of the term "nothing more" minimises the significance of syntax.
There's a reason why C++ has "operator" methods when they don't provide
any additional functionality.

The fact that it provides a bounds-checked method does nothing to
eliminate the argument that they made the wrong choice for operator[].
FWIW, I'm not taking any particular side in that argument, I'm just saying
that it exists, and the existence of .at() doesn't change that.

Also, arrays don't have .at(), so if you want to write code which works
with either vectors or arrays, subscript notation is the only option.

"Nobody" <nobody@nowhere.com>
> Also, arrays don't have .at(), so if you want to write code which works
> with either vectors or arrays, subscript notation is the only option.

Less ignorant people know that "do not use C-style arrays" is on the top of 
C++ guidelines anywhere.

On May 26, 8:10=A0pm, "Balog Pal" <p...@lib.hu> wrote:
> "Nobody" <nob...@nowhere.com>
>
> >>> For example, Java has decided to check array indices
> >>> at runtime, C++ not to.
>
> >> Really? What does .at() do?
>
> > Checks vector indices. Vectors aren't arrays (and the default
> > indexing operation, operator[], doesn't do bounds-checking).
>
> Err, exactly what makes it *default*?

The context? I think the topic was arrays, until derailed to
std::vector.

On May 27, 8:41=A0am, "Balog Pal" <p...@lib.hu> wrote:
> "Nobody" <nob...@nowhere.com>
>
> > Also, arrays don't have .at(), so if you want to write code which works
> > with either vectors or arrays, subscript notation is the only option.
>
> Less ignorant people know that "do not use C-style arrays" is on the top =
of
> C++ guidelines anywhere.

Also, std::tr1::array<foo_t,N> (the C++ std-library equivalent of
C90's foo_t foo[N]) absolutely *does* have .at().  Of course you can't
do C99 VLA's like that, but C99 VLA's don't have sensible semantics
for detecting memory allocation fails (i.e. stack-overflow) anyway.  C+
+ gives the programmer the choice between C-style "unsafe" indexing
*and* safe indexing.  Whatever "premature optimisation" means, I'm
pretty certain its not providing

[Besides, Java arrays are heap based like std::vector<> - so it makes
no sense to say "Java's equivalent of std::tr1::array are type-
checked" as no such object is exists]

"hanukas" <jukka@liimatta.org>
>> > Checks vector indices. Vectors aren't arrays (and the default
>> > indexing operation, operator[], doesn't do bounds-checking).
>>
>> Err, exactly what makes it *default*?

>The context? I think the topic was arrays, until derailed to
>std::vector.

Derailed? Did you look what group it is? C++. We do not use C arrays. By 
default we use vector, when something like that is needed. By non-default we 
use some other collection. C array we use only as last resort, or for very 
special circumstances. In those, indexing is done through an enum, or 
equivalent, and bounds checking would not apply in any way. 

gwowen <gwowen@gmail.com> writes:
>Java arrays are heap based

      �If an object is allocated in a subroutine, and a
      pointer to the object never escapes, the object may be a
      candidate for stack allocation instead of heap allocation.�

http://en.wikipedia.org/wiki/Escape_analysis

On May 27, 9:12=A0am, hanukas <ju...@liimatta.org> wrote:

> The context? I think the topic was arrays, until derailed to
> std::vector.

Everything I said applies to std::tr1::array too...

template <class T,size_t N>
class bounds_checked_c_array
{
private:
  std::tr1::array<T,N> arr_;
public:
  T& operator[](size_t idx) { return arr_.at(idx);};
  const T& operator[](size_t idx) const { return arr_.at(idx);};
  // exposing a more STL-container like interface left as an
exercise.
  // This will do for porting - you may wish to have operator T*() for
  // faking C-array-decay-to-pointer
};

On May 27, 9:40=A0am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> gwowen <gwo...@gmail.com> writes:
> >Java arrays are heap based
>
> =A0 =A0 =A0 If an object is allocated in a subroutine, and a
> =A0 =A0 =A0 pointer to the object never escapes, the object may be a
> =A0 =A0 =A0 candidate for stack allocation instead of heap allocation.
>
> http://en.wikipedia.org/wiki/Escape_analysis

I stand corrected: "Java arrays are almost always heap based except in
a set of extremely restrictive circumstances, and subject to the
compiler / runtime noticing,"

(Of course, you could say exactly the same thing about std::vector -
the as-is rule allows for exactly the same escape analysis - although
the existence of efficient stack-based alternatives [i.e.
std::tr1::array] means that nobody bothers.)

"gwowen" <gwowen@gmail.com>

>I stand corrected: "Java arrays are almost always heap based except in
>a set of extremely restrictive circumstances, and subject to the
>compiler / runtime noticing,"

>(Of course, you could say exactly the same thing about std::vector -
>the as-is rule allows for exactly the same escape analysis - although
>the existence of efficient stack-based alternatives [i.e.
>std::tr1::array] means that nobody bothers.)

LOL. Well put.

Balog Pal <pasa@lib.hu> wrote:
> Less ignorant people know that "do not use C-style arrays" is on the top of 
> C++ guidelines anywhere.

  Which can be quite a detrimental principle in terms of efficiency in
some cases. Many a newbie has learned that principle by heart, causing
tons and tons of really inefficient code. How many times have you seen
something like this:

class Vector3D
{
    std::vector<double> values;

 public:
    Vector3D(): values(3) {}
    ...
};

  That class is at least 10 times less efficient (both memorywise and
speedwise) than the simpler:

class Vector3D
{
    double values[3];

 public:
    ...
};

  (The same is even more common with things like fixed-size 4x4
transformation matrices, many times going to such horrendous lengths
as having a vector of vectors as a member variable, making it even
*more* inefficient than the above example.)

  std::array in the new C++ standard will alleviate this problem, but
that's far in the future...

* Juha Nieminen, on 28.05.2011 13:35:
> Balog Pal<pasa@lib.hu>  wrote:
>> Less ignorant people know that "do not use C-style arrays" is on the top of
>> C++ guidelines anywhere.
>
>    Which can be quite a detrimental principle in terms of efficiency in
> some cases. Many a newbie has learned that principle by heart, causing
> tons and tons of really inefficient code. How many times have you seen
> something like this:
>
> class Vector3D
> {
>      std::vector<double>  values;
>
>   public:
>      Vector3D(): values(3) {}
>      ...
> };
>
>    That class is at least 10 times less efficient (both memorywise and
> speedwise) than the simpler:
>
> class Vector3D
> {
>      double values[3];
>
>   public:
>      ...
> };

Well, it depends. Instance creation may be much more than 10 times less 
efficient, but indexing can be quite efficient. And memorywise it's likely but 
not certain that the std::vector version will use the small buffer optimization.

However, it illustrates that one often is willing to sacrifice some efficiency 
in order to have simple, general, easy to follow rules.

It may be that the quality of the code as a whole improves by having simple 
rules, even though that means non-optimal code for some special cases.


Cheers,

- Alf

-- 
blog at <url: http://alfps.wordpress.com>

On May 28, 2:35=A0pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> =A0 std::array in the new C++ standard will alleviate this problem, but
> that's far in the future...

boost::array<> and boost::scoped_array<> were made public somewhere at
start of this millenia. So C++ style of array has been available for
decade for anyone connected to internet.

One doesn't need to include whole boost to use such ... actually
extremely simple classes.

"�� Tiib" <ootiib@hot.ee>
>
>> std::array in the new C++ standard will alleviate this problem, but
>> that's far in the future...

>boost::array<> and boost::scoped_array<> were made public somewhere at
>start of this millenia. So C++ style of array has been available for
>decade for anyone connected to internet.

>One doesn't need to include whole boost to use such ... actually
>extremely simple classes.

Yeah. As we had arrays in NIH, in Borland classlib, in MFC and many other 
libraries that were around before CFront 3.0.  And people from early days 
did write a plenty of those funcdamental clases themselves routinely too.

On May 28, 7:41=A0am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Juha Nieminen, on 28.05.2011 13:35:
>
>
>
>
>
>
>
>
>
> > Balog Pal<p...@lib.hu> =A0wrote:
> >> Less ignorant people know that "do not use C-style arrays" is on the t=
op of
> >> C++ guidelines anywhere.
>
> > =A0 =A0Which can be quite a detrimental principle in terms of efficienc=
y in
> > some cases. Many a newbie has learned that principle by heart, causing
> > tons and tons of really inefficient code. How many times have you seen
> > something like this:
>
> > class Vector3D
> > {
> > =A0 =A0 =A0std::vector<double> =A0values;
>
> > =A0 public:
> > =A0 =A0 =A0Vector3D(): values(3) {}
> > =A0 =A0 =A0...
> > };
>
> > =A0 =A0That class is at least 10 times less efficient (both memorywise =
and
> > speedwise) than the simpler:
>
> > class Vector3D
> > {
> > =A0 =A0 =A0double values[3];
>
> > =A0 public:
> > =A0 =A0 =A0...
> > };
>
> Well, it depends. Instance creation may be much more than 10 times less
> efficient, but indexing can be quite efficient. And memorywise it's likel=
y but
> not certain that the std::vector version will use the small buffer optimi=
zation.
>
> However, it illustrates that one often is willing to sacrifice some effic=
iency
> in order to have simple, general, easy to follow rules.
>

The class in question is something that might be found in a library.
Every library writer I know is willing to learn some more of the ins
and outs to improve their library.  If the library author does his job
well, users don't have to be aware of the complexities of the library.


Brian Wood
http://webEbenezer.net

none (Yannick Tremblay) wrote:
> In article <irfg4m$e42$1@dont-email.me>, MikeP <mp011011@some.org>
> wrote:
>> none (Yannick Tremblay) wrote:
>>> In article <ir8hll$k7d$2@dont-email.me>, MikeP <mp011011@some.org>
>>> wrote:
>>>> Juha Nieminen wrote:
>>>>> MikeP <mp011011@some.org> wrote:
>>>>>
>>>>>> Indeed, I forego many of the C++
>>>>>> "built-in" offerings for ones that I craft myself.
>>>>>
>>>>>  If you use your own tool instead of a standard tool even in
>>>>> situations where the standard tool would be perfectly suited,
>>>>> that's not very smart.
>>>>
>>>> Opinions vary. I note that you are an "in the paint" kind of guy:
>>>> "standards this... standards that". To each their own is what I
>>>> say.
>>>
>>> "To each their own" is only valid if you write code only for
>>> yourself.  If you are a professional programmer and are paid to
>>> write code that will become the property of someone/something else
>>> and will most likely need to be maintained in the future by someone
>>> else than yourself, then using your own personal hand crafted tool
>>> when a standard tool would be perfectly suited is demonstrably a
>>> bad thing.
>>>
>>> Yannick
>>
>> Hey Yannick, I really don't have time for less than 10 points above
>> my IQ (and EQ) AND 10 years my senior.
>>
>
> Sorry Mike but you started here having a discussion.  Some of the
> points you raised are let's say controversial

Oh? Do tell. Spill, please.

> or at least not everyone
> are in agreement with.

Is change good or bad?

> However, until your last few posts, you were
> acting as a positive contributor attempting to have a worthwhile
> technical discussion.

It's an affliction. I really do love this stuff. I have to take drugs to 
stop doing this programming drug. ;) (Recruiters and 
using-me-as-your-lotto-ticket "things": that was NOT an invitation. What 
part of 'NO' don't you understand?).

> Your alternate point of view

I have one of those? Do tell, please. I might learn something about 
myself (not likely, I know me very well)!

> was actually
> interesting and worthwhile to consider.

:) Cool. How did you mean that?


>
> Have you decided that you were not interested in having a valid and
> constructive technical discussion but would rather become a negative
> contributor to this newsgroup?

You surely will admit that it gets quite boring here sometimes. Shoot the 
message, not the messenger?

Juha Nieminen wrote:
> MikeP <mp011011@some.org> wrote:
>> Balog Pal wrote:
>>> "MikeP" <mp011011@some.org>
>>>>>> The trade-off (there always is one) being Template Code Bloat
>>>>>> (TCB).
>>>>>
>>>>>  What's that, exactly?
>>>>
>>>> Type "template code bloat" or "C++ template code bloat" into your
>>>> favorite internet search engine and you'll get a long listing.
>>>
>>> Type in bullshit at the same place to get an even longer list...
>>> Care to explain your own assertion, especially what bloat is created
>>> compared to what alternative executing the same task?
>>>
>>> Or you're just creating flood to have more posts i this thread than
>>> the rest together?
>>
>> I can only lead you to the water. I can't make you drink it. Suit
>> yourself.
>
>  I still don't understand what this "template code bloat" is.
>

Scott Meyers (I don't know if it was the book-writing SM) posed the 
question in one of the links I gave. Maybe he should follow up and close 
that thread by writing a conclusion/what he learned. I think it's still a 
good question, but for those who are not "just" followers that program to 
the cookie cutter (NOT a remark about templates (that's a separate post! 
hehe)). I can answer you questions, in depth. But I don't think I want 
to.

I don't know if you are sincere or you are doing that (decidedly) "icky" 
thing of trying to test me (in which case all you will test, is my 
patience). If I'm wrong, I'm wrong, I don't need round-a-bout "methods of 
learning" (e.g., "colledge", but been there, done that, if that floats 
your boat). I'm not afraid of "throwing caution to the wind" and "asking" 
a question here. I should probably change my nick to "LoneCoder" or 
something! LOL! 

Balog Pal wrote:
> "Nobody" <nobody@nowhere.com>
>> Also, arrays don't have .at(), so if you want to write code which
>> works with either vectors or arrays, subscript notation is the only
>> option.
>
> Less ignorant people know that "do not use C-style arrays" is on the
> top of C++ guidelines anywhere.

I hate tangential threads of discussion. Y'all need to get some 
discipline. :P 

Joshua Maurice wrote:
> On May 25, 5:39 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> �Learning C++ is equivalent to studying to be a NASA
>> test pilot. Its incredibly fast and effective, but takes
>> years to master the arcania and things tend to blowup in
>> your face if you're not very careful.�
>>
>> Shinji Ikari
>
> Do you have a source or citation

Oh, a Wikipedia afficionado. Hello (facetious me, I meant "helllo", this 
is not Wikipedia).

> of some kind for this quote, where it
> was first said?

Oh, FIRST, said. I smell competition rearing its ugly face. (Just a 
feeling, I could be wrong).

> I'm just kind of curious curious for no particular
> reason at all.

Uh huh. "No reason whatsoever". (You can be read like a book!). :P 

Rui Maciel wrote:
> Stefan Ram wrote:
>
>> My source is
>>
>> Message-ID: <8cd70836.0307221922.5c355605@posting.google.com>
>> From: shinji@swirve.com (Shinji Ikari)
>> Newsgroups:
>> comp.theory.cell-
> automata,comp.lang.java.advocacy,comp.lang.scheme,comp.lang.misc
>> Subject: Re: Cellular automata benchmarks: Java vs C++ vs Java vs C++
>> Date: 22 Jul 2003 22:33:27 -0700
>
> When people quote someone, they do it with the hope that the aura of
> authority that emits from that specific person is enough to force
> others to simply swallow a statement without exercizing the faintest
> attempt at critical thinking.

Shush you. That is what the followers of a demigod do. Stop being so 
wrongly general, because sometimes I will point out your pessimism.

> You don't benefit from that by quoting
> some random usenet post made by some anonymous person who posted a
> random message 8 years ago under a pseudonim inspired by an anime
> series.

I don't know the scenario, but you are accusing the poster. (I'm not a 
lawyer though. And who's "law", anyway?).

Jorgen Grahn wrote:
> On Thu, 2011-05-26, Stefan Ram wrote:
>> Rui Maciel <rui.maciel@gmail.com> writes:
>>> Stefan Ram wrote:
>>>> The whole point of C++ is premature optimization
>>> Why do you believe that "the whole point of C++ is premature
>>> optimization"?
> ...
>>   Since this optimization is /always/ done, by pure /choice of
>>   the language/, it can be called premature.
>
> One day I'm going to have to write a paper called
> "The phrase 'premature optimization' considered harmful" ...
>
> /Jorgen,
> only half joking

I'm a (SLOOOOOWWWWWWLY) recovering C programmer (who "stopped" using C 
and "moved" to C++ over 10 years ago). C is bad, and C is good, let us 
thank it, for our... confusion (investigation into the matter :))! It is 
good and bad (having the C "experience"). The standard library (not the C 
part, but rather the template part) was written (ask me) by C++ers rather 
than Cers or those "I haven't used C in years, I don't use drugs anymore, 
I admit I used to"-guys.

I hate tangential threads-WITHIN-a thread. I "mispoke" when I wrote, "I 
hate tangential threads of discussion". I actually like them a lot, but 
in a SEPARATE thread! 

Joshua Maurice wrote:
> On May 26, 1:53 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Thu, 2011-05-26, Stefan Ram wrote:
>>> Rui Maciel <rui.mac...@gmail.com> writes:
>>>> Stefan Ram wrote:
>>>>> The whole point of C++ is premature optimization
>>>> Why do you believe that "the whole point of C++ is premature
>>>> optimization"?
>> ...
>>> Since this optimization is /always/ done, by pure /choice of
>>> the language/, it can be called premature.
>>
>> One day I'm going to have to write a paper called
>> "The phrase 'premature optimization' considered harmful" ...
>
> I'd fund it.

Have you ever funded anything? 

Keith H Duggar wrote:
> On May 26, 4:53 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Thu, 2011-05-26, Stefan Ram wrote:
>>> Rui Maciel <rui.mac...@gmail.com> writes:
>>>> Stefan Ram wrote:
>>>>> The whole point of C++ is premature optimization
>>>> Why do you believe that "the whole point of C++ is premature
>>>> optimization"?
>> ...
>>> Since this optimization is /always/ done, by pure /choice of
>>> the language/, it can be called premature.
>>
>> One day I'm going to have to write a paper called
>> "The phrase 'premature optimization' considered harmful" ...
>
> Thank you. That phrase is being used by the ignorant masses in
> a manner only marginally less moronic than "conservatives want
> to starve autistic children to death".
>

Someone suggested that YOU were "premature optimization"? (I sense an 
angry baby!). Dude, we are not your "dad". Deal with it, you're just the 
outcome of a human petri dish. Seriously, dude, deal with it. (Don't 
worry if you CAN'T HANDLE THE TRUTH. What is "truth"? Do you like to 
think? Does it hurt to think? Is the banning of IQ as a parameter a crime 
against humanity? Why is taxing your neighbor for your personal petri 
dish not a crime?). 

Nobody wrote:

> Premature optimisation means performing "optimisations" before you
> have sufficient knowledge to determine what is actually optimal.

No, it means that you are dragging out a non-issue.

gwowen wrote:
> On May 25, 1:52 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> Leigh Johnston <le...@i42.co.uk> writes:
>>> Remember: premature optimization is the root of all evil.

"OMG", Leigh is back? Hi Leigh. How did that affair with you and Paul 
work out? 

Joshua Maurice wrote:
> On May 25, 5:52 am, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
>> Leigh Johnston <le...@i42.co.uk> writes:
>>> Remember: premature optimization is the root of all evil.

You were on my "blocked senders" list because I couldn't take anymore of 
your .... nevermind. You are back online in this world. Get help with 
your ultra-low-level-of-nothingness-<whatever>.

(See, I'm not good with "people-issues". :P). Right? 

Alf P. Steinbach /Usenet wrote:

> However, it illustrates that one often is willing to sacrifice some
> efficiency in order to have simple, general, easy to follow rules.
>
> It may be that the quality of the code as a whole improves by having
> simple rules, even though that means non-optimal code for some
> special cases.

"HELLO". "Teachers" do not really know how to teach anything. You can say 
one thing like that to someone who is a sponge for the information, and 
it is KEY. I've noted other times that your practicality is such as my 
own (or something like that). (No, I don't want to "date you", bitch). 
LOL! I'm open to COMPLEMENTARY association (lawyers (not "language 
lawyers", but those may be solicited and used (not RAPED, been there/done 
that) precisely), sales people (I will tell you what to sell and how and 
NO, you WILL NOT "own" MY customers), ... blah, blah... it's my 
"LinkedIn" profile I just posted here! 

Ebenezer wrote:

>> However, it illustrates that one often is willing to sacrifice some
>> efficiency in order to have simple, general, easy to follow rules.
>>
>
> The class in question is something that might be found in a library.
> Every library writer I know is willing to learn some more of the ins
> and outs to improve their library.  If the library author does his job
> well, users don't have to be aware of the complexities of the library.
>
>

Hey "Scrooge", I suggest that what you quoted resembles MASTURBATION to a 
"high degree".  (I am facetious. Or am I?). 

jacob navia wrote:
> Le 25/05/11 12:15, Rui Maciel a �crit :
>> hanukas wrote:
>>
>>> That's not very relevant as I don't think a FIFO is very popular
>>> replacement strategy for cache.
>>
>> I believe you didn't quite understood it.  The main point, which
>> Belady's anomaly demonstrates, is that there isn't necessarily a
>> direct correlation between how much cache a program takes up and the
>> number of cache misses. If it isn't possible to assume a direct
>> correlation between how much cache a program takes up and the number
>> of cache misses then it isn't possible to claim that a specific
>> variation in a program's size has a specific impact on how fast a
>> program is ran.  If the subject being discussed is the relation
>> between a program's size and the influence that size may have on how
>> fast that program runs, particularly due to the number of cache
>> misses it generates, then it is obviously relevant. Rui Maciel
>
> Yes, you are right in principle. It is conceivable that a huge
> program uses only a small fraction of its executable foot print
> and all of it fits in the cache.
>

This a programming NG. Show me the 'cache' keyword or whatever. There is 
no "cache". What part of "ankh" don't you understand? There is no 
"cache"!

On Thu, 26 May 2011 18:28:02 +0100, Nobody wrote:

> Premature optimisation means performing "optimisations" before you have
> sufficient knowledge to determine what is actually optimal.

I get really tired of how this quote is abused (I'm not accusing you of 
abusing it, I'm speaking generally).

When Knuth wrote that, he was writing in the context of of algorithms.  
His point was it's important to analyze and optimize your algorithms and 
logic before mucking around with the fiddly-bits.  In other words, what 
optimization is premature is a matter of good judgment.  

His statement does *not* mean that you should neglect performance until 
you have a working prototype you can profile, which is unfortunately the 
context in which I most often see it quoted.   He was being intentionally 
hyperbolic, in order to point out the fact that you can purchase just as 
much inefficiency by overthinking performance at too early a stage, as you 
would if you neglect it completely.

Finding the right priority to assign performance during your design and 
initial coding decisions is a judgement call.  It depends on the needs of 
your application and the hardware that you're working with.  Developing 
good judgment in that (and most) regards requires introspection, self-
evaluation, and constant learning.  Oversimplifications and dogmatism will 
prevent self-improvement, and thus prevent developing good judgement.

I can't find the reference anymore, but I recall reading an essay from 
Knuth where he laments how much that quote is misused and misunderstood.  
If anyone knows the reference, please pass it on.

On Jun 25, 1:07=A0pm, glen stark <m...@dontspammebro.glenstark.net>
wrote:
> On Thu, 26 May 2011 18:28:02 +0100, Nobody wrote:
> > Premature optimisation means performing "optimisations" before you have
> > sufficient knowledge to determine what is actually optimal.
>
> I get really tired of how this quote is abused (I'm not accusing you of
> abusing it, I'm speaking generally).
>
> When Knuth wrote that, he was writing in the context of of algorithms. =
=A0

"Programmers waste enormous amounts of time thinking about, or
worrying about, the speed of noncritical parts of their programs, and
these attempts at efficiency actually have a strong negative impact
when debugging and maintenance are considered. We should forget about
small efficiencies, say about 97% of the time: premature optimization
is the root of all evil. Yet we should not pass up our opportunities
in that critical 3%."  -- Structured Programming With Goto Statements
- http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

He's *evidently* and *clearly* talking about programs, and evidently
saying "do not sacrifice code clarity for speed, unless the speed-up
actually matters. He wasn't talking about algorithms - the paper from
which the quote comes is about using 'goto' in structured programs -
something that is essentially algorithm agnostic.

Your intepretation is incorrect.

On May 16, 4:08=A0pm, Lynn McGuire <l...@winsim.com> wrote:
> Why C++ is vastly superior to C:
> =A0 =A0 =A0http://warp.povusers.org/programming/cplusplus_superior_to_c.h=
tml
>
> "In conclusion, the reason why C is so vastly inferior to C++ as
> described in this article can be summarized with one single sentence:
> C has no support for RAII nor templates, while C++ does. That's two
> of the most important features that make C++ by far the superior
> language."
>
> Lynn


    The functionality of C++ is a superset of the functionality of C.
So of course C++ has more features and functionality. Even if you have
a preference for "C style programming", you can always choose to use a
C++ compiler to compiler your code without using any of the C++-
specific features such as templates and classes.

    So what use is C nowadays? The answer is that the standard for C
is much simpler than C++ and so it takes far less man-hours to produce
a C compiler for any given platform. I've programmed microcontrollers
in C, purely because there was no C++ compiler available (PIC
microcontrollers). C is far more prevalent than C++ in the land of
microcontrollers.

"Virchanza" <virtual@lavabit.com>

>    So what use is C nowadays? The answer is that the standard for C
>is much simpler than C++ and so it takes far less man-hours to produce
>a C compiler for any given platform. I've programmed microcontrollers
>in C, purely because there was no C++ compiler available (PIC
>microcontrollers). C is far more prevalent than C++ in the land of
>microcontrollers.

For the record, IAR has C++ for PIC stuff. But it is expensive like hell, so 
in practice you're really stuck with C. 

Virchanza <virtual@lavabit.com> wrote:
> C is far more prevalent than C++ in the land of microcontrollers.

  That's probably completely true, but prevalence doesn't say anything
about quality.

On 6/29/2011 1:37 PM, Virchanza wrote:
> On May 16, 4:08 pm, Lynn McGuire<l...@winsim.com>  wrote:
>> Why C++ is vastly superior to C:
>>       http://warp.povusers.org/programming/cplusplus_superior_to_c.html
>>
>> "In conclusion, the reason why C is so vastly inferior to C++ as
>> described in this article can be summarized with one single sentence:
>> C has no support for RAII nor templates, while C++ does. That's two
>> of the most important features that make C++ by far the superior
>> language."
>>
>> Lynn
>
>
>      The functionality of C++ is a superset of the functionality of C.
> So of course C++ has more features and functionality. Even if you have
> a preference for "C style programming", you can always choose to use a
> C++ compiler to compiler your code without using any of the C++-
> specific features such as templates and classes.
>
>      So what use is C nowadays? The answer is that the standard for C
> is much simpler than C++ and so it takes far less man-hours to produce
> a C compiler for any given platform. I've programmed microcontrollers
> in C, purely because there was no C++ compiler available (PIC
> microcontrollers). C is far more prevalent than C++ in the land of
> microcontrollers.


well, and it is also easier to write tools to process ones' C code and 
generate reflection metadata or similar, but retrofitting these tools to 
support C++ would be a non-trivial task...

also useful for metaprogramming and reflective code generation (where 
tools write tasks to accomplish certain tasks based on code that is 
already there).

this can also be useful when combined with run-time code generation, or 
with self-modifying programs, or when implementing VMs for other 
languages which need to be able to interface with ones' natively 
compiled code.


so, having a technically simpler language may outweigh some of the gains 
of being able to write code in it a little easier. even then, C is still 
a fairly complex language, but some of us don't uphold simplicity as a 
gold standard either, as "simple" languages (for example: Forth, 
Smalltalk, Lisp and Scheme, ...) have generally failed to gain 
widespread adoption (or be ideally suited to many real-world programming 
tasks).


or such...