Relative prevalence of "good" C++

[Christopher Benson-Manica]

In your experience, what is the prevalence of "good" C++ (i.e., the
code makes full use of solid language features and the STL) versus C++
written in ignorance (or defiance) of one or more key features of the
language?

 

[Phlip]

In your experience, what is the prevalence of "good" C++ (i.e., the
code makes full use of solid language features and the STL) versus C++
written in ignorance (or defiance) of one or more key features of the
language?

5%.

And worshiping STL ain't the point. You can go overboard too. Just writing
clean flexible code that doesn't crash and is easy to upgrade is very hard,
yet possibly worthwhile.

 

[Henryk]

Some point that come to my mind:

- consistent naming rules (variables, methods, classes) for your code
- using references instead of pointers (if possible) makes your code
saver
- use const for variables, method parameters and, method return values
if this is the nature of the function
- find an elegant class model for your problem (clean encapsulation).

but there are surely more points...

In general:

For my part, I try to write CONSISTENT code. That means: If I have the
same/similar problem I try to use the same/similar solution. That
really helps to make your code more robust (It works there, so it will
work here. Found a logic error there, so I have to fix it here too),
maybe you can even share code (base class), and it's easier to
understand the code for another person.

 

[Howard]

In your experience, what is the prevalence of "good" C++ (i.e., the
code makes full use of solid language features and the STL) versus C++
written in ignorance (or defiance) of one or more key features of the
language?

--

Rule: All programmers write perfect code. All other programmers write
crap.
(-From an unknown source. Not me, though, so it must be crap.)

 

[Earl Purple]

In your experience, what is the prevalence of "good" C++ (i.e., the
code makes full use of solid language features and the STL) versus C++
written in ignorance (or defiance) of one or more key features of the
language?

It's shocking. People are writing this in their code:

class Foo
{
private:
typedef std::vector< Bar > BarVect;
BarVect bars;

public:
void func1( const Bar & bar );

void func2();
};

void Foo::func2()
{
BarVect::const_iterator iter = bars.begin(), itEnd=bars.end();

for ( ; iter != itEnd; ++iter )
{
func1( *iter );
}
}

I mean, look! they use a for-loop instead of some convoluted binder!
(or writing a functor class to solve it)

 

[Robert J. Hansen]

I can answer this question as soon as you define what it means to be
"good", and as soon as you define what it means to be a "key feature".

E.g., the following is perfectly good C++ in my book, although you'd
probably call it "ignorant" or "defiant":

=====
#include <cstdio>

int main()
{
printf("Hello, World!\n");
return 0;
}

=====

C++ is a huge language with tons of different ways to skin cats. There
are usually many perfectly reasonable ways to flay any given feline.
The ultimate measure of reasonableness is the reliability of the code,
how well the code addresses the problem it's supposed to solve, and how
easy it is for successors to maintain.

 

[Ian Collins]

I can answer this question as soon as you define what it means to be
"good", and as soon as you define what it means to be a "key feature".

E.g., the following is perfectly good C++ in my book, although you'd
probably call it "ignorant" or "defiant":

=====
#include <cstdio>

int main()
{
printf("Hello, World!\n");
return 0;
}

Not in mine, it won't compile - should be std:rintf.

 

[Christopher Benson-Manica]

E.g., the following is perfectly good C++ in my book, although you'd
probably call it "ignorant" or "defiant":

There's nothing wrong with that, but I would suggest that C++ code
that takes great pains to duplicate functionality provided by the STL
certainly qualifies as "ignorant" or "defiant", possibly both. Surely
there is something left to be desired in code that cries out for, say,
std::map but is prevented from making use of it by the use of
nonstandard language extensions.

The ultimate measure of reasonableness is the reliability of the code,
how well the code addresses the problem it's supposed to solve, and how
easy it is for successors to maintain.

I also suggest that C++ that uses a static array of, say, 600 structs
and then complains when one wants space for 601 does a poor job of
solving a problem that a std::vector would in all probability be far
better suited for.

I really thought this would be an easy question, but apparently
gratuitously bad C++ would seem to be the exception.

 

[steve.j.donovan]

I also suggest that C++ that uses a static array of, say, 600 structs

and then complains when one wants space for 601 does a poor job of
solving a problem that a std::vector would in all probability be far
better suited for.

That would be indeed perverse. But what about the (I assume) ironical
comment earlier?

I mean, look! they use a for-loop instead of some convoluted binder!
(or writing a functor class to solve it)

C++ is not a true functional language with proper anonymous closures,
so something simple like calling a method for all objects in a
collection can get nasty if one insisted on for_each. So a lot of
people prefer to use explicit loops where they are clearer, and generic
algorithms when they make sense (e.g. std::copy). Now would we call
such people old-fashioned people best left behind by the march of
progress? I think not.

steve d.

 

[Christopher Benson-Manica]

That would be indeed perverse. But what about the (I assume) ironical
comment earlier?

Which one? (They weren't intended to be rhetorical.)