Back to General and Gameplay Programming

C++ Curiosities

General and Gameplay Programming Programming

Started by Boder March 26, 2006 10:59 PM

43 comments, last by jflanglois 18 years ago

560

March 27, 2006 12:08 AM

Quote:Original post by Boder
How would the "list of expressions to be evaluated look"? Would there be two {} {} sections?

The "list of expressions to be evaluated" would look like valid c++ code (whereas the current incarnation does not). The for statement takes (expr list; bool expr; expr list), for example. My point with the initializers is that they were just kinda thrown in and have no relation at all to any other syntax in the C++ language. Assigning a value to a variable shouldn't look like a function call, unless that is what assigning a value to a variable looks like in the language.

The entire language was just sort of slapped together. I wasn't kidding when I said it was a hack. I don't mean it in a bad way (beyond the intrinsic badness of it, at least). It originated in a desire to coerce a non-OO language to work with classes, etc., without sacrificing backward compatibility. It's a recipe for disaster. [grin]

Way Walker

745

March 27, 2006 12:11 AM

Quote:Original post by Boder
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?

Why not? Call them "initializer" and "constructor" sections. If you extend it to functions in general, it could make RAII a more integrated and explicit part of the language. (Of coruse, then you're starting to look like C's "all variables at the start of a function" which was removed, for the most part, because of constructors)

Washu

7,836

March 27, 2006 12:19 AM

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

Why isn't "null" a keyword?

Perhaps you should look at: A name for the null pointer: nullptr

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

Why? The closing brace is sufficient to indicate the end of the function, or any other scope.

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.

This is why you should use refactoring tools, they tend to handle that for you, and are a lot smarter than find and replace (which is indescriminant).

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

Nothing hackish about it, although it can be ugly. You can also use #pragma once on certain compilers, however it is not a standard thing, and thus is not supported by all compilers (such is the nature of pragmas).

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

cow_in_the_well

624

March 27, 2006 01:03 AM

Quote:Original post by Washu
Why? The closing brace is sufficient to indicate the end of the function, or any other scope.

True, which is why needing a ; at the end of a class definition annoys me a bit -_-.

- Thomas Cowellwebsite | journal | engine video

HQ-SOFT

151

March 27, 2006 01:13 AM

Quote:Original post by smitty1276
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.

The varName(value) syntax can be used when initializing a variable. For example:

int main(){    int i(0);    int j = 0;    printf("%d %d \n", i, j);    return (0);}

Either way is perfectly valid C++.

-HQ.

Boder

935

Author

March 27, 2006 01:29 AM

When defining functions for a namespace, I usually do something like so

namespace MySpace{func1() {}func2() {}}

But for classes it works differently.

class MySpace{func1() {}func2() {}}

I don't think that will compile. So I write

MySpace::func1() {}MySpace::func2() {}

Any tips to avoid the extra typing?

Fruny

1,658

March 27, 2006 01:32 AM

Quote:Original post by smitty1276
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.

...

C++ is one big hack.

The same can be said of the x86 architecture, which has seen massive adoption where other arguably better designs have failed.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

Boder

935

Author

March 27, 2006 03:02 AM

Don't you think it would be a good idea to define class methods like so

class MyClass{func1() {}func2() {}}

But not in the header file.

ZQJ

496

March 27, 2006 09:02 AM

Quote:Original post by Boder
Don't you think it would be a good idea to define class methods like so
class MyClass{func1() {}func2() {}}
But not in the header file.

Newer languages like Java and D unify the definition and declaration sections to make the programmer's life easier but it needs a cleverer compiler to search multiple files for the extra definitions. C++ wasn't built like that - it was meant to be like C where the compiler can get everything it needs to know from just the preprocessed input, which is why definition and declaration are separate because the declaration is necessary to call a function/allocate a class instance, but the definition isn't.

On the subject of initialiser lists, how do you want it to work? In C++ if an object is accessable it must have been constructed already and the only way to handle this in a class constructor for its members is to construct them before the start of the constructor itself, so if you want to be able to call non-default constructors initialiser lists are necessary.

As for x86 and C++ being big hacks built on little hacks, yep, they are, but it's about the best we've got at the moment, and I for one am hoping they'll get replaced sooner rather than later (I can't see anything that'll replace C++ soon though, as for x86, x86-64 might do something).

NotAYakk

876

March 27, 2006 01:20 PM

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

Why isn't "null" a keyword?

C had the pseudo-keyword NULL that evaluates to 0.

However, "null" was in use by lots of C code, and using terms that exist in lots of existing code as keywords is rude.

They should have added a nullptr keyword, but they didn't. I expect it to be in the next version of the C++ standard.

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

Semicolons serve three purpsoses.
1> Statement terminators.
2> variable declairation terminators.
3> for(;;) sub-statement seperators.

Functions are not variable declairations.

Most compilers accept naked ;s, so placing one at the end of a function doesn't hurt.

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.

You only have to change it wherever it is called if your new prototype is incompatable with the old prototype. And if it is incompatable, you should be looking at everwhere it is called in any case!

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

The C preprocessor "solved" the problem in a flexable way, so people didn't resolve to resolve the problem. ;)

Sometimes people use header files as "macro programs", defining tokens before hand to change the meaning of #include "header.h".

Reasons to do this have included:
1> #define FORWARD_DECL
#include ...
#undef FORWARD_DECL
to get the forward declairations from a bunch of header files.

2> Primitive generic code tricks. Having a math library that works on doubles or floats or ints depending on what preprocessor tokens you define before #including it.

HTH.

C++ Curiosities

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

C++ Curiosities

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines