Why C++ is vastly superior to C

[gwowen]

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]

 

[Balog Pal]

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.

 

[Stefan Ram]

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

 

[gwowen]

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

 

[gwowen]

      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

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

 

[Balog Pal]

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.

 

[Juha Nieminen]

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

 

[Alf P. Steinbach /Usenet]

* Juha Nieminen, on 28.05.2011 13:35:

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

 

[Öö Tiib]

  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.

 

[Balog Pal]

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.

 

[Ebenezer]

* Juha Nieminen, on 28.05.2011 13:35:

   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.

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

 

[MikeP]

Juha Nieminen 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[/QUOTE]

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?

 

[MikeP]

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!

 

[MikeP]

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.

 

[MikeP]

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

 

[MikeP]

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

 

[MikeP]

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!

 

[MikeP]

I'd fund it.

Have you ever funded anything?

 

[MikeP]

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

 

[MikeP]

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.