So I'm wondering. Why isn't "null" a keyword? Why don't we put semicolons at the end of functions (implementation)? How come it's so inconvenient to change a function's prototype? I have to change it in the header file, the implementation file, and everywhere that it's called. Shouldn't header guards be implemented in a less hackish way? When would you include the same file twice?

Quote:Original post by Boder
So I'm wondering.

Why isn't "null" a keyword?

Why don't we put semicolons at the end of functions (implemenation)?

How come it's so inconvenient to change a function's prototype? I have to change it in the header file, the implementation file, and everywhere that it's called.

Shouldn't header guards be implemented in a less hackish way? When would you include the same file twice?

1. NULL is a value, values are not keywords
I think Visual C++.NET 8.0 has a keyword called nullptr
I don't see the point anyway...

2. You can put a semicolon at the end of a functions implementation if your heart desires but it isn't necessary because of the braces

3. That's what find/replace is good for. BTW. What do you mean by inconvinient? Why are you changing the names of functions in the middle of a project anyway?

4. They are... #pragma once for visual c++ compilers.

This is a situation where main.cpp will include the header1.h file twice
The header guard would detect this and subsequently not bothering with the parsing of the object class again (Slower....)

header1.h

class object
{};

header2.h
#include "object.h"
class der1 : object
{};

header3.h
#include "object.h"
class der2 : object
{};


main.cpp
#include "header2.h"
#include "header3.h"

Quote:Original post by Adam Hamilton
1. NULL is a value, values are not keywords

What about true and false? [wink] [reference link]

I don't have an answer as to why null is not a keyword, it's more of a logical problem. For example, what would you define NULL as? It can't be 0, then you could have char x = null; , but x would not represent null since it is not a pointer. Tricky stuff like that is what makes it not I'd venture to say.

Is NULL guaranteed to be defined even if you don't include stdlib.h (C and C++)?

Here is a little trick for toggling a boolean value (just saw it):

flag ^= true;

But [smile]

char x = false;

x is a character, certainly not a boolean

Quote:Original post by Boder
Why isn't "null" a keyword?

Historical reasons. 0 is recognized as "0" for most types (floating point 0, integer 0, null pointer 0) and is false for those types (with anything else being true). In a way, 0 is the C++ word for null.

Quote:
Why don't we put semicolons at the end of functions (implementation)?

For the same reason you don't for if/else, while, namespace, etc. No ; after } is actually more consistent. The reason it's required after class, struct, and enum definitions is because you can create an instance.

class A { /* stuff... */ } a;

You now have an instance. Don't want an instance? Leave it blank. I don't know the history of when code such as:

struct A { /* stuff... */ };
struct A a;

entered C, but it's in C++ because it's in C.

Quote:
How come it's so inconvenient to change a function's prototype? I have to change it in the header file, the implementation file, and everywhere that it's called.

First, how could it be possible to change the prototype but not change everywhere it's called? I can imagine an IDE potentially replacing every call with some default for new paramters, but I'm not sure if that's very useful or not.

As for having to change it in a header and the implementation file, that's to make things easier on the compiler and, in some ways, offers more flexibility in how you design your source tree. It means the compiler doesn't have to know about or even have access to the code or binaries of libraries. All the relevant information is in the file it's currently compiling.

Quote:
Shouldn't header guards be implemented in a less hackish way? When would you include the same file twice?

See cassert for an example.



So, basically, it's a lot of leftovers from C. Objective-C has a #import keyword to #include only once, but some criticise it saying that it's for the header file to decide how many times it should be able to be included.

If it all seems a bit archaic, try a younger language. (or an older language *cough* Lisp *cough*)

[Edited by - Way Walker on March 26, 2006 11:28:59 PM]

I made modifications to my original post when I saw how mean I sounded...

true and false... I have never thought of them as keywords (more like a reserved word), just something handy the compiler gives you (maybe the compiler can optimise better). I read the reference link you posted and noticed they are the only keywords that are described as values...

I still wouldn't consider it a keyword though (I'm stubborn I know) keywords make the compiler switch different states

Because C++ is one of the most poorly designed languages to ever see such popularity. There are a zillion things about C++ that are simply retarded, but we use it anyway.

Why do initializers in a class constructor take the form varName(value)? Why not a list of expressions to be evaluated? Why is that the only place where that syntax appears in the entire language? Becuase it's a horrid language from a design perspective, that's why.

C++ is one big hack.

(BTW, I'm not trying to start a flame war, so nobody get mad.)

I looked into initialization lists because I didn't quite understand what you were suggestion they be replaced with.

It looks like the main drawback is that you can't do error-checking on the arguments that were given to the constructor.

How would the "list of expressions to be evaluated look"? Would there be two {} {} sections?