Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Relative prevalence of "good" C++

Reply
Thread Tools

Relative prevalence of "good" C++

 
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      01-18-2006
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?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      01-18-2006
Christopher Benson-Manica wrote:

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

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!


 
Reply With Quote
 
 
 
 
Henryk
Guest
Posts: n/a
 
      01-18-2006
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.

--

Henryk

 
Reply With Quote
 
Howard
Guest
Posts: n/a
 
      01-18-2006

"Christopher Benson-Manica" <(E-Mail Removed)> wrote in message
news:dqk3e4$93o$(E-Mail Removed)...
> 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.)


 
Reply With Quote
 
Earl Purple
Guest
Posts: n/a
 
      01-18-2006

Christopher Benson-Manica wrote:
> 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?
>
> --
> Christopher Benson-Manica | I *should* know what I'm talking about - if I
> ataru(at)cyberspace.org | don't, I need to know. Flames welcome.


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)

 
Reply With Quote
 
Robert J. Hansen
Guest
Posts: n/a
 
      01-18-2006
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.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-18-2006
Robert J. Hansen wrote:
> 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.

--
Ian Collins.
 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      01-19-2006
Robert J. Hansen <(E-Mail Removed)> wrote:

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
steve.j.donovan@gmail.com
Guest
Posts: n/a
 
      01-19-2006
>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.

 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      01-21-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

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


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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
prevalence of different JVM versions Dawid Michalczyk Java 14 08-01-2007 09:07 PM
Prevalence of XHTML? Neo Geshel HTML 33 04-24-2007 01:26 AM
Worrying Prevalence of K++ Compilers Frederick Gotham C++ 9 11-09-2006 02:42 PM
setting relative addressing in composer refuses to work ken Firefox 0 12-10-2003 07:11 PM
Relative placement constraints in VHDL for Virtex multipliers Jack Stone VHDL 1 07-25-2003 08:12 PM



Advertisments