Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #7198 > unrolled thread

Why C is vastly superior to C++

Back to article view | Back to comp.lang.c++

Contents

  Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-06-28 14:12 +0200
    Re: Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-06-28 14:15 +0200
    Re: Why C is vastly superior to C++ Noah Roberts <dont@email.me> - 2011-06-28 10:02 -0700
      Re: Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-06-28 19:14 +0200
    Re: Why C is vastly superior to C++ Juha Nieminen <nospam@thanks.invalid> - 2011-06-29 20:20 +0000
      Re: Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-06-29 23:04 +0200
        Re: Why C is vastly superior to C++ Ian Collins <ian-news@hotmail.com> - 2011-06-30 09:45 +1200
        Re: Why C is vastly superior to C++ Juha Nieminen <nospam@thanks.invalid> - 2011-06-30 05:08 +0000
          Re: Why C is vastly superior to C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-30 06:10 +0000
            Re: Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-06-30 08:42 +0200
              Re: Why C is vastly superior to C++ Ian Collins <ian-news@hotmail.com> - 2011-06-30 21:08 +1200
                Templates (was Re: Why C is vastly superior to C++) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-30 15:03 +0000
                  Re: Templates (was Re: Why C is vastly superior to C++) Juha Nieminen <nospam@thanks.invalid> - 2011-06-30 16:40 +0000
                    Re: Templates (was Re: Why C is vastly superior to C++) "MikeP" <mp011011@some.org> - 2011-06-30 22:06 -0500
                  Re: Templates (was Re: Why C is vastly superior to C++) "MikeP" <mp011011@some.org> - 2011-06-30 22:05 -0500
              Re: Why C is vastly superior to C++ Juha Nieminen <nospam@thanks.invalid> - 2011-06-30 10:45 +0000
                Re: Why C is vastly superior to C++ BGB <cr88192@hotmail.com> - 2011-06-30 16:09 -0700
              Re: Why C is vastly superior to C++ Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-07 00:39 -0700
        Re: Why C is vastly superior to C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-30 06:32 +0000
        Re: Why C is vastly superior to C++ Noah Roberts <dont@email.me> - 2011-06-30 10:49 -0700
        Re: Why C is vastly superior to C++ "io_x" <a@b.c.invalid> - 2011-07-01 10:20 +0200
          Re: Why C is vastly superior to C++ "io_x" <a@b.c.invalid> - 2011-07-02 08:14 +0200
    Re: Why C is vastly superior to C++ Goran <goran.pusic@gmail.com> - 2011-06-30 23:56 -0700
    Re: Why C is vastly superior to C++ Juha Nieminen <nospam@thanks.invalid> - 2011-07-07 16:39 +0000
      Re: Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-07-07 18:55 +0200
        Re: Why C is vastly superior to C++ "MikeP" <mp011011@some.org> - 2011-07-07 16:48 -0500
          Re: Why C is vastly superior to C++ jacob navia <jacob@spamsink.net> - 2011-07-08 01:29 +0200
            Re: Why C is vastly superior to C++ "MikeP" <mp011011@some.org> - 2011-07-07 19:13 -0500
        Re: Why C is vastly superior to C++ Juha Nieminen <nospam@thanks.invalid> - 2011-07-08 06:57 +0000

Page 1 of 2  [1] 2  Next page →

#7198 — Why C is vastly superior to C++

Memory footprint. C++ uses up a LOT of memory.

:-)

[toc] | [next] | [standalone]

#7199

Le 28/06/11 14:12, jacob navia a écrit :
> Memory footprint. C++ uses up a LOT of memory.
>
> :-)

Attention TROLL message!!!

:-)

[toc] | [prev] | [next] | [standalone]

#7209

On 6/28/2011 5:12 AM, jacob navia wrote:
> Memory footprint. C++ uses up a LOT of memory.
>
> :-)

That's because it's incremented.  Higher value integers use up more memory.

[toc] | [prev] | [next] | [standalone]

#7210

Le 28/06/11 19:02, Noah Roberts a écrit :
> On 6/28/2011 5:12 AM, jacob navia wrote:
>> Memory footprint. C++ uses up a LOT of memory.
>>
>> :-)
>
> That's because it's incremented. Higher value integers use up more memory.

Yes. But my memory is not extensible.
Last time I tried I told my surgeon:

Doctor, doctor!

What's up again jacob?

I need a memory extension, my brain is full!

Why?
You have been studying again  the C++ specs?

Yes, I just wanted to know how the function call works
but it was several dozens of pages of stuff, with a
topological sort of the classes involved, with all those
template specializations that go nuts when I forget a >... etc.

Then I just noticed that as I read
page 12 I was forgetting what was in page one and also
the name of my wife...

Terrible! I need a bigger brain!!!

Well, jacob... I can't do anything for you but...
Why don't you learn a simpler language, like C?
It uses much less memory.

You see?

The doctor told me so.

[toc] | [prev] | [next] | [standalone]

#7249

jacob navia <jacob@spamsink.net> wrote:
> Memory footprint. C++ uses up a LOT of memory.

  I haven't noticed such a difference.

  (In fact, there are many cases where C consumes more memory than the
equivalent C++ version because often C++ allows the compiler to perform
optimizations that the C compiler cannot do.)

[toc] | [prev] | [next] | [standalone]

#7252

Le 29/06/11 22:20, Juha Nieminen a écrit :
> jacob navia<jacob@spamsink.net>  wrote:
>> Memory footprint. C++ uses up a LOT of memory.
>
>    I haven't noticed such a difference.
>
>    (In fact, there are many cases where C consumes more memory than the
> equivalent C++ version because often C++ allows the compiler to perform
> optimizations that the C compiler cannot do.)

Sure, but I was speaking about HUMAN memory, who cares about computer
memory when you can buy megabytes for a dime a dozen?

The problem with my brain is that its memory is not extensible. Trying
to understand and memorize the specifications for overloaded function 
calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
to swallow and digest that without a severe indigestion.

There arrives a point (that C++ has already passed beyond) where
there is no brain in the world, not even the one of Stroustrup,
that is able to understand 100% of the language. See the "concepts"
debacle.

This means that in practice NO ONE understands the language he/she is
using in full. The language has become something beyond the capabilities
of mere people and only a compiler can understand it.

I have seen more and more posts where somebody asks here:

"Why doesn't this compile"?

And the answers are:

o Compiles in MSVC
o Doesn't compile in gcc
o Comeau accepts it...

without ANYBODY even trying to argue about WHY the construct
in question is right or wrong. Nobody knows any more.

Everybody knows what I am speaking about  yet this doesn't seem to be
seen as a problem and the committee keeps adding and adding features
(lambdas, etc) without any person trying to stop that trend, as if
"progress" in software construction implies always MORE complexity
and MORE complexity without any limit.

Well there are limits, and those limits are set by our brain. In the
last resort, mere PEOPLE are using this language, and they just are
now unable to understand ALL the implications of what they are
doing when they write any serious program.

The consequences are that C++ software is "brittle", in the sense that
a small change somewhere, that everybody thought it would be harmless
produces a whole series of catastrophes in other, unrelated parts
of the software.

It is not time to reflect about this problem?

Thanks for your input.

jacob

[toc] | [prev] | [next] | [standalone]

#7255

On 06/30/11 09:04 AM, jacob navia wrote:
>
> Well there are limits, and those limits are set by our brain. In the
> last resort, mere PEOPLE are using this language, and they just are
> now unable to understand ALL the implications of what they are
> doing when they write any serious program.

I have coached a number of C development teams int C++.  The first thing 
we do before committing to a project is a agree the language subset 
everyone in the team is happy with and initially stick to that.  Over 
time as the team's experience grows, so does the language subset they use.

One team was happy just to use C++ as a better C, no OO, just function 
overloading, references, proper const and a few other features (I'm sure 
you are familiar with these features!).  Another was happy to jump in 
boots first and use the kitchen sink.  Others chose a middle ground.

So reflecting on your agenda, C++ can and is used as C with the features 
you are keen to add.  It works well in that space which is why you meet 
so much opposition when proposing additions to C.

> The consequences are that C++ software is "brittle", in the sense that
> a small change somewhere, that everybody thought it would be harmless
> produces a whole series of catastrophes in other, unrelated parts
> of the software.

Not if it has a decent testing framework.

> It is not time to reflect about this problem?

In nigh on 20 years of developing C++ code and development teams, I 
haven't found this to be a problem.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7260

jacob navia <jacob@spamsink.net> wrote:
> The problem with my brain is that its memory is not extensible. Trying
> to understand and memorize the specifications for overloaded function 
> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
> to swallow and digest that without a severe indigestion.

  C isn't all that much better in this regard. C parsers may be significantly
simpler to create than full-fledged C++ parsers, but that doesn't necessarily
mean that *programming* in C is any simpler or easier than in C++.

  When developing large projects in C you usually need to use paradigms and
coding conventions that exist solely because of what C lacks (iow. they are
unnecessary in C++ and most other languages). In other words, you are
mostly just changing your brain capacity usage from learning language
features to learning coding conventions and strict guidelines that should
be unnecessary. In a way, you could say that most large projects use a
"megalanguage" on top of C, and any person who wants to participate in the
development of that project needs to learn it.

> The consequences are that C++ software is "brittle", in the sense that
> a small change somewhere, that everybody thought it would be harmless
> produces a whole series of catastrophes in other, unrelated parts
> of the software.

  I don't think C is much better in this regard.

[toc] | [prev] | [next] | [standalone]

#7266

On Thu, 2011-06-30, Juha Nieminen wrote:
> jacob navia <jacob@spamsink.net> wrote:
>> The problem with my brain is that its memory is not extensible. Trying
>> to understand and memorize the specifications for overloaded function 
>> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
>> to swallow and digest that without a severe indigestion.
>
>   C isn't all that much better in this regard. C parsers may be significantly
> simpler to create than full-fledged C++ parsers, but that doesn't necessarily
> mean that *programming* in C is any simpler or easier than in C++.
>
>   When developing large projects in C you usually need to use paradigms and
> coding conventions that exist solely because of what C lacks (iow. they are
> unnecessary in C++ and most other languages). In other words, you are
> mostly just changing your brain capacity usage from learning language
> features to learning coding conventions and strict guidelines that should
> be unnecessary. In a way, you could say that most large projects use a
> "megalanguage" on top of C, and any person who wants to participate in the
> development of that project needs to learn it.

Precisely. Compared to C, C++ moves complexity /from/ N program to 1
language, so I don't have to learn N different partial solutions to
the same problem.

(Other languages like Python do so even more of course, but none of
the popular ones stay close to C in terms of library support and
performance, for the times you need that.)

You could replace s/CommonLisp/C++/ in Greenspuns Tenth Rule Of
Programming:

    "Any sufficiently complicated C or Fortran program contains an
    ad-hoc, informally-specified, bug-ridden, slow implementation of
    half of CommonLisp."

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#7270

Le 30/06/11 08:10, Jorgen Grahn a écrit :
> On Thu, 2011-06-30, Juha Nieminen wrote:
>> jacob navia<jacob@spamsink.net>  wrote:
>>> The problem with my brain is that its memory is not extensible. Trying
>>> to understand and memorize the specifications for overloaded function
>>> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
>>> to swallow and digest that without a severe indigestion.
>>
>>    C isn't all that much better in this regard. C parsers may be significantly
>> simpler to create than full-fledged C++ parsers, but that doesn't necessarily
>> mean that *programming* in C is any simpler or easier than in C++.
>>
>>    When developing large projects in C you usually need to use paradigms and
>> coding conventions that exist solely because of what C lacks (iow. they are
>> unnecessary in C++ and most other languages). In other words, you are
>> mostly just changing your brain capacity usage from learning language
>> features to learning coding conventions and strict guidelines that should
>> be unnecessary. In a way, you could say that most large projects use a
>> "megalanguage" on top of C, and any person who wants to participate in the
>> development of that project needs to learn it.
>
> Precisely. Compared to C, C++ moves complexity /from/ N program to 1
> language, so I don't have to learn N different partial solutions to
> the same problem.
>


Yes, you have a point here (You and Mr Nieminen). That is a weak point
in C. I am trying to address this within the C community, with
relatively lack of success.

In this sense, the problems with those features is not that they exist,
but that their usage is extremely complicated and hard to follow.

Templates are an example of that. They are both great when they work,
incomprehensible when they don't. You have then, to memorize a series
of "gotchas" and template conventions that make the subject
extremely obscure and memory consuming.

Metaprogramming should be done at compile time within a specific
meta-language, designed to do that. This has been done with extremely
hard to follow templates like IF and others, that approach the
metalanguage goal without EXPLICITELY having a meta-language.

All the memory required to memorize the hacks needed now would be
unnecessary if we would have a simple functional language where
we describe templates with parameter checking, etc etc. A meta-language 
would (again)  "move complexity /from/ N programs to 1 language"

jacob

[toc] | [prev] | [next] | [standalone]

#7271

On 06/30/11 06:42 PM, jacob navia wrote:
> Le 30/06/11 08:10, Jorgen Grahn a écrit :
>> On Thu, 2011-06-30, Juha Nieminen wrote:
>>> jacob navia<jacob@spamsink.net>   wrote:
>>>> The problem with my brain is that its memory is not extensible. Trying
>>>> to understand and memorize the specifications for overloaded function
>>>> calls in the C++ specs goes for PAGES AND PAGES, impossible for a brain
>>>> to swallow and digest that without a severe indigestion.
>>>
>>>     C isn't all that much better in this regard. C parsers may be significantly
>>> simpler to create than full-fledged C++ parsers, but that doesn't necessarily
>>> mean that *programming* in C is any simpler or easier than in C++.
>>>
>>>     When developing large projects in C you usually need to use paradigms and
>>> coding conventions that exist solely because of what C lacks (iow. they are
>>> unnecessary in C++ and most other languages). In other words, you are
>>> mostly just changing your brain capacity usage from learning language
>>> features to learning coding conventions and strict guidelines that should
>>> be unnecessary. In a way, you could say that most large projects use a
>>> "megalanguage" on top of C, and any person who wants to participate in the
>>> development of that project needs to learn it.
>>
>> Precisely. Compared to C, C++ moves complexity /from/ N program to 1
>> language, so I don't have to learn N different partial solutions to
>> the same problem.
>
> Yes, you have a point here (You and Mr Nieminen). That is a weak point
> in C. I am trying to address this within the C community, with
> relatively lack of success.
>
> In this sense, the problems with those features is not that they exist,
> but that their usage is extremely complicated and hard to follow.
>
> Templates are an example of that. They are both great when they work,
> incomprehensible when they don't. You have then, to memorize a series
> of "gotchas" and template conventions that make the subject
> extremely obscure and memory consuming.

Not really, no.  Most programmers get most of their exposure to 
templates through the standard library and they don't find it obscure. 
The excellent book Accelerated C++ launches straight into the standard 
library in its first chapter.

> Metaprogramming should be done at compile time within a specific
> meta-language, designed to do that. This has been done with extremely
> hard to follow templates like IF and others, that approach the
> metalanguage goal without EXPLICITELY having a meta-language.

Metaprogramming is really a corner case, the majority of programmers 
will never have to use it.  Difficulties with metaprogramming are as 
much conceptual as they are practical, it does require a competency 
different mind set.

> All the memory required to memorize the hacks needed now would be
> unnecessary if we would have a simple functional language where
> we describe templates with parameter checking, etc etc.

Care to define one?  I'm not aware of any "hacks" required to use templates.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7294 — Templates (was Re: Why C is vastly superior to C++)

On Thu, 2011-06-30, Ian Collins wrote:
> On 06/30/11 06:42 PM, jacob navia wrote:
...
>> In this sense, the problems with those features is not that they exist,
>> but that their usage is extremely complicated and hard to follow.
>>
>> Templates are an example of that. They are both great when they work,
>> incomprehensible when they don't. You have then, to memorize a series
>> of "gotchas" and template conventions that make the subject
>> extremely obscure and memory consuming.
>
> Not really, no.  Most programmers get most of their exposure to 
> templates through the standard library and they don't find it obscure. 

I think though that to use C++ effectively you need to be able to
write new template code; it's not one of those features you can
happily ignore.  They aren't just for people designing libraries, and
you don't have to be into template metaprogramming to use them.

I don't find templates that hard to grasp; I think of them as
macros without the nasty surprises.

Understanding /how/ and /where/ they can be useful is trickier though.
I hope the best C++ literature out there teaches that, but I've not
read enough of it.

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#7296 — Re: Templates (was Re: Why C is vastly superior to C++)

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> I think though that to use C++ effectively you need to be able to
> write new template code; it's not one of those features you can
> happily ignore.  They aren't just for people designing libraries, and
> you don't have to be into template metaprogramming to use them.

  The vast majority of templated code required in practical projects is
quite simplistic. Basically as "better macros" (ie. more type-safe, etc).
It's much rarer to need the *actual* metaprogramming capabilities of C++
templates (such as overloading, specialization, recursive template
definitions, tricks related to conditional template instantiation,
SFINAE tricks, etc.)

  In other words, in practical programs it's rare to need the more
complex aspects of templates.

[toc] | [prev] | [next] | [standalone]

#7316 — Re: Templates (was Re: Why C is vastly superior to C++)

Juha Nieminen wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> I think though that to use C++ effectively you need to be able to
>> write new template code; it's not one of those features you can
>> happily ignore.  They aren't just for people designing libraries, and
>> you don't have to be into template metaprogramming to use them.
>
>  The vast majority of templated code required in practical projects is
> quite simplistic. Basically as "better macros" (ie. more type-safe,
> etc). It's much rarer to need the *actual* metaprogramming
> capabilities of C++ templates (such as overloading, specialization,
> recursive template definitions, tricks related to conditional
> template instantiation, SFINAE tricks, etc.)
>
>  In other words, in practical programs it's rare to need the more
> complex aspects of templates.

I'll further that by saying that is is GOOD to AVOID those things if at 
all possible. 

[toc] | [prev] | [next] | [standalone]

#7315 — Re: Templates (was Re: Why C is vastly superior to C++)

Jorgen Grahn wrote:

> I don't find templates that hard to grasp; I think of them as
> macros without the nasty surprises.

Unfortunately, they do not make the preprocessor obsolete. (But this may 
be because of the uncohesiveness of C++ features).

[toc] | [prev] | [next] | [standalone]

#7275

jacob navia <jacob@spamsink.net> wrote:
> All the memory required to memorize the hacks needed now would be
> unnecessary if we would have a simple functional language where
> we describe templates with parameter checking, etc etc. A meta-language 
> would (again)  "move complexity /from/ N programs to 1 language"

  If you want that kind of flexibility and expressive power, you could
move to lisp or haskell. However, in practice the C-family of OO languages
(including C++, Java and C#) have the best support in most systems, so
you are pretty much stuck. (Also, the highly functional language require
a rather different mindset than imperative OO languages, which makes the
learning curve rather steep.)

[toc] | [prev] | [next] | [standalone]

#7313

On 6/30/2011 3:45 AM, Juha Nieminen wrote:
> jacob navia<jacob@spamsink.net>  wrote:
>> All the memory required to memorize the hacks needed now would be
>> unnecessary if we would have a simple functional language where
>> we describe templates with parameter checking, etc etc. A meta-language
>> would (again)  "move complexity /from/ N programs to 1 language"
>
>    If you want that kind of flexibility and expressive power, you could
> move to lisp or haskell. However, in practice the C-family of OO languages
> (including C++, Java and C#) have the best support in most systems, so
> you are pretty much stuck. (Also, the highly functional language require
> a rather different mindset than imperative OO languages, which makes the
> learning curve rather steep.)


one can partly build a Lisp-like environment on top of C or C++, say, 
via implementing a GC and a dynamic typesystem, and a lot of special 
purpose functions and macros to do various operations (such as 
car/cdr/cadr/cdddar/..., composing lists, ...).

but then one may find that C++ may not offer much advantage over doing 
the same things in C, but C++ is harder to process via tools (say, 
writing a parser and special-purpose code-transformation or 
code-analysis logic), giving C an advantage for this use case...

granted, one can use Lisp, but this has other drawbacks (and even in a 
pure syntax sense, Lisp is not that much better than crufted-over C WRT 
readability or usability).

yes, one can also build a general purpose "apply" and closures and 
similar as well...


granted, I have a custom script language, which does a lot of this a 
little cleaner, and I may gradually start migrating to this (it has 
existed a long time, but I hadn't been using it for much, as for much of 
its life prior to last-year, its C-interop was fairly poor, requiring 
lots of boilerplate, and a major usage of a lot of my fancy 
code-processing stuff is in reducing the total amount of boilerplate).

another more common, and much older, use case (and tool), is that of 
automatically writing headers (because having to keep source files and 
headers in-sync was kind of a pain, requiring much copy/pasting of 
declarations and so on...). this tool partly supports C++, but will fail 
hard if namespaces are being used (it is not namespace-aware, and this 
would not be an entirely trivial addition).

additionally, I may, eventually, start adding bits and pieces of C++ 
support to the tools, but as is all of this is already a bit complex, 
and I have more important things to work on.


or such...

[toc] | [prev] | [next] | [standalone]

#7566

On Jun 30, 7:42 am, jacob navia <ja...@spamsink.net> wrote:

<snip>

> In this sense, the problems with those features is not that they exist,
> but that their usage is extremely complicated and hard to follow.
>
> Templates are an example of that. They are both great when they work,
> incomprehensible when they don't. You have then, to memorize a series
> of "gotchas" and template conventions that make the subject
> extremely obscure and memory consuming.
>
> Metaprogramming should be done at compile time within a specific
> meta-language, designed to do that. This has been done with extremely
> hard to follow templates like IF and others, that approach the
> metalanguage goal without EXPLICITELY having a meta-language.
>
> All the memory required to memorize the hacks needed now would be
> unnecessary if we would have a simple functional language where
> we describe templates with parameter checking, etc etc.

perl?

> A meta-language
> would (again)  "move complexity /from/ N programs to 1 language"

[toc] | [prev] | [next] | [standalone]

#7269

On Wed, 2011-06-29, jacob navia wrote:
...

> There arrives a point (that C++ has already passed beyond) where
> there is no brain in the world, not even the one of Stroustrup,
> that is able to understand 100% of the language.

That doesn't worry me -- I don't understand all of any other language
either.  What matters to me is that I can write my programs, make them
work, make them reasonably elegant, and be sure that they don't just
/accidentally/ work.

> See the "concepts"
> debacle.

They aren't part of the language -- if I understand correctly, because
they were not properly understood.

> This means that in practice NO ONE understands the language he/she is
> using in full. The language has become something beyond the capabilities
> of mere people and only a compiler can understand it.
>
> I have seen more and more posts where somebody asks here:
>
> "Why doesn't this compile"?
>
> And the answers are:
>
> o Compiles in MSVC
> o Doesn't compile in gcc
> o Comeau accepts it...
>
> without ANYBODY even trying to argue about WHY the construct
> in question is right or wrong.

I've seen those threads. IIRC the interesting ones usually concern
name lookup, or heavy template stuff. Call me lazy, but as long as
there's no doubt what the code would do /if it compiled/, I don't
worry too much.

> Nobody knows any more.

Or noone here can be bothered to decipher every piece of problem code
posted.

> Everybody knows what I am speaking about  yet this doesn't seem to be
> seen as a problem and the committee keeps adding and adding features
> (lambdas, etc) without any person trying to stop that trend, as if
> "progress" in software construction implies always MORE complexity
> and MORE complexity without any limit.

I never understood that oft-repeated complaint.  C++ has stood still
since the mid-1990s. Every other language I use (except C) has grown
immensely during that period. Why can't we have some badly needed
features, when we have waited patiently for over fifteen years?

/Jorgen

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

[toc] | [prev] | [next] | [standalone]

#7302

On 6/29/2011 2:04 PM, jacob navia wrote:
> Le 29/06/11 22:20, Juha Nieminen a écrit :
>> jacob navia<jacob@spamsink.net> wrote:
>>> Memory footprint. C++ uses up a LOT of memory.
>>
>> I haven't noticed such a difference.
>>
>> (In fact, there are many cases where C consumes more memory than the
>> equivalent C++ version because often C++ allows the compiler to perform
>> optimizations that the C compiler cannot do.)
>
> Sure, but I was speaking about HUMAN memory, who cares about computer
> memory when you can buy megabytes for a dime a dozen?
>
> The problem with my brain is that its memory is not extensible.

Actually, I believe this is false.  There are very few places in the 
human brain where you actually grow new neurons upon reaching adulthood, 
memory being one of those places.  I'm not a neural scientist, but I 
read a lot and as I understand it this is the facts of the brain.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web