C++ coding styles and standards

[Ephphatha]

Trying to steer clear of religious wars territory here, all I'm interested in is whether the C++ standard recommends one thing or the other on the following points.

Code: Select all

void Class::Draw(void)
{
    //Code that does stuff

    return;
}


• Should a function that takes no arguments be declared as Foo() or Foo(void)?
• Should a void function have a return statement?
• Should a constructor ever have a return statement?

With no arg functions, I've been using the latter, but I developed the habit while coding pure C. I've found one website that says function signatures of the form Foo() are preferred in C++ but no reasoning was given.
I've been putting a return statement at the end of every void function after reading somewhere that they should... Can't find the source. I'm not going to follow the school of "Only one return statement in a function, *EVER*" since that creates some ugly ugly code, but again, that's not the issue
I'm under the assumption that having a return statement in a constructor is a terrible idea, and as such I haven't been doing it, but I haven't really found anything that says either way.

Can anyone shed some light on the issue? Or at least knock me off the fence

[phlip]

The standard itself doesn't really say anything one way or the other on style points... it just says what is and what isn't a valid C++ program, and, for the ones that are, what they should do.

A void parameter list and an empty parameter list are different things in C (and you should pretty much always avoid the latter)... but they're the same in C++. The void option is mostly still around for backwards-compatibility with C headers (and C programmers)... the empty list does feel cleaner, but that's the only real reason to choose it.

As for return statements at the end of void functions and constructors/destructors... it's allowed, but pretty pointless. It's easier (and more idiomatic) to just let it flow out the end of the function. A return with no value is typically only useful in the middle of the function, inside a conditional block (if, or catch, or suchlike)... which some people frown on (my prof at uni thought it, along with break and continue, were as bad as using goto... yes, really) but is generally seen as reasonable. Constructors and destructors aren't special here, they can have returns wherever, just the same as void functions.

[Jplus]

A good source on C++ coding style in general is Danny Kalev's C++ Reference Guide

[Thesh]

Code: Select all

void Class::Draw(void)
{
    //Code that does stuff

    return;
}


In that case, in both C and C++ the void is unnecessary, the only time you require the void in C is in the prototype. Technically this is not required since C89, but it's generally good practice to do so.

[Sc4Freak]

In C++, Foo() and Foo(void) are identical. You should prefer Foo() over Foo(void), because it's cleaner and more concise. But if your code already uses Foo(void), there's no reason to go through all your code and change it, just be consistent.

[Ephphatha]

The void option is mostly still around for backwards-compatibility with C headers (and C programmers)

See, this makes me think that the "proper" way of doing it is not to declare functions that take no arguments as taking void, but just leave the parameters blank.

That C++ reference guide looks pretty good, but is there any way to download it? It's not exactly convenient to read when it's split to 400 pages.

[phlip]

Well, all I mean by that was that if C++ was redesigned from scratch to not be (mostly) compatible with C, then void parameter lists probably wouldn't exist. But then, if C was redesigned from scratch to not be (mostly) compatible with older C, then void parameter lists probably wouldn't exist in it either... and they're still definitely proper form in C as it actually exists.

My guidelines: if there's any chance the code will be compiled as C (say, a header for a library that works with both C and C++) the include the void. If not, do the same as any existing functions for consistency. If there aren't any existing functions (new project) then leave out the void, if only for aesthetics. But then I'd probably put it in by force of habit anyways, since I've spent more time coding C than I have C++.

[Jplus]

That C++ reference guide looks pretty good, but is there any way to download it? It's not exactly convenient to read when it's split to 400 pages.

Only if by "download" you mean "purchase". As a book made from paper, that is.

[bieber]

The void option is mostly still around for backwards-compatibility with C headers (and C programmers)

See, this makes me think that the "proper" way of doing it is not to declare functions that take no arguments as taking void, but just leave the parameters blank.

That C++ reference guide looks pretty good, but is there any way to download it? It's not exactly convenient to read when it's split to 400 pages.

Write a scraper?

[Ephphatha]

That C++ reference guide looks pretty good, but is there any way to download it? It's not exactly convenient to read when it's split to 400 pages.

Only if by "download" you mean "purchase". As a book made from paper, that is.

Ah, thought it was available as a free ebook somewhere considering it was online. I guess they put it up like that to piss you off into buying it. I'm going to need to save up some money and go shopping pretty soon. I'd appreciate any suggestions for C++ books I should buy but I'm sure a quick bit of googling can weed out a few highly recommended texts.

[Jplus]

I have recommended books before in other threads, and I feel there should be some "recommended literature" thread in the coding forums, but at present I can't find either. So, here's a list. Please realise that learning a language, or learning to program, is not just a matter of reading as many books as possible. Exercise (with the internet as reference when you meet problems) is at least as important, and I think it would be a waste of your money/time to (immediately) buy all books/read all resources I list below.

• Savitch is a good guide into the basics of C++. It teaches real C++, so you won't be writing some bastard dialect of C and then come out like an ass when you tell someone that you're programming in C++ (this, to my horror, is something that happens all too often). Unfortunately, it doesn't go a single step beyond the basics (say, enough to order in a restaurant but not to write a column in a newspaper) and it's also rather expensive.
• Kalev I have already mentioned.
• The Gang of Four provides a good guide into the general concepts of object-oriented programming, as well as a catalogue of design patterns that often occur in OOP. Most examples are written in C++, but that doesn't make it a dedicated C++ book. As has been discussed in other threads, OOP has its beauties as well as its weaknesses. You should never make OOP a goal on itself, but it can prove useful in certain cases.
• SGI provides a brilliant overview of the STL, as well as a short but decent explanation of the concept of generic programming. In modern, state-of-the-art C++ programming, the generic paradigm is at least as important as OOP, so you should make yourself familiar with it (but again, not make it a goal on itself). Unfortunately, I don't know of a book that explains generic programming as elegantly as the Gang of Four do with OOP. Maybe it's because generic programming is not as widely supported among programming languages as OOP. AFAIK Haskell is the only other language that provides the same strong, rigorous level of (static) generic programming.
• Stroustrup is the inventor of C++ and his book is the standard source on how to program with it. It's somewhat less of a basic course like Savitch and proceeds into a more advanced level of programming. Still, it might be overkill to directly buy it. His website, however, contains not-so-readable but very information-rich pages about C++ technicalities.

[Unparallelogram]

A void parameter list and an empty parameter list are different things in C (and you should pretty much always avoid the latter)...

Could you elaborate further on this please?

I recall learning C and being told to have nothing between the parentheses for functions that don't take arguments.

[Sc4Freak]

In C, a void parameter list means a function that takes no arguments. An empty parameter list means a function that can take any number of arbitrary arguments (variadic function). Usage of variadic functions in C should be fairly rare, because they sacrifice all type safety. In C++ they should pretty much never be used, because you have vastly better alternatives in C++.

At least, that's from what I remember. My language of choice is C++, so my knowledge of straight C is somewhat limited.

[phlip]

The following compiles perfectly fine (with about a million warnings, but compiles) in C:

Code: Select all

/* NB: no headers */
a(); /* This doesn't even really need to be here */

main()
{
   printf("a=%c\n",a(5, "Hello!"));
   return 0;
}

a(x,s)
   char *s;
{
   return s[x];
}

(New challenge: see how many other archaic C throwbacks you can cram into this snippet...)

[Coffee Stain]

I always forget that C is allowed to come without a ++.

[Rysto]

For more fun, change that last line to:

return x[s];