Jump to content
  • Advertisement
Sign in to follow this  
Boder

C++ Curiosities

This topic is 4497 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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"

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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;

Share this post


Link to post
Share on other sites
Quote:
Original post by Boder
Why don't we put semicolons at the end of functions (implementation)?


You can but you aren't required to. You are required to for classes and structs because you can define objects (multiple object definitions are separated by commas) between the } and the ;. For example:

#include <iostream>
struct {
int operator()(int x, int y) { return x + y; }
} add;

int main() {
std::cout << add(1, 2) << std::endl; // prints 3
return 0;
}

Share this post


Link to post
Share on other sites
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.


#include <iostream>

#define NDEBUG
#include <cassert>
int foo(int a) { assert(0); std::cout << "foo()\n"; }

#undef NDEBUG
#include <cassert>
int bar(int a) { assert(0); std::cout << "bar()\n"; }

int main() {
foo();
bar(); /* BOOM! */
}





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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!