Giving compile time error!Code:#include<iostream> using namespace std; class man; class car{ public: car(){ } }; class man{ public: car c; man() { } }; int main() { return (0); }
Giving compile time error!Code:#include<iostream> using namespace std; class man; class car{ public: car(){ } }; class man{ public: car c; man() { } }; int main() { return (0); }
*What* compile time error?
Strange, It was throwing error, I restarted my computer, its fine now, how that could happen?
and is this code OK? or my programming style is bad?
Probably there was something complety else wrong. Maybe you didn't safe the file until you rebooted your computer or something simple like that. About your coding style:Originally Posted by kapil1089thekin
* "#include<iostream>" I prefer a space before the "<"
* "class man;" is completely useless: remove that line.
* The empty constructors are completely useless: remove them.
* "public:" indented is not very clear, in my opinion. You should probably remove the tab/spaces in front of it.
* class names should usually start with an uppercase, like Man and Car.
* This way, a man has exactly one car: never more, never less. Maybe that's fine for your example though, but in words it doesn't make much sense.
* The number of spaces before the opening "{" isn't consistent. Use one, or do it on a newline.
* Usually, you should split classes over multiple header/source files.
* I personally dislike "return (0);". It's like people think it's a function. "return 0;" makes more sense.
Other than that, it's fine ;-).
Probably your program was already running while you was trying to run it again, then when you restarted it worked...
Was the error something like "bla bla returned with exit code -1"? It happens to me sometimes.
2B OR !2B? That is the question!
Hmmm... no, they should start with a capital C!
Well, lucky for him, half of them already do. So that would make it Car and CMan? ;-)Hmmm... no, they should start with a capital C!
I think you're being sarcastic, but I hate that "C-prefix-naming-convention". I use the same naming conventions for classes and structs: one capital per word.
No, it should be CCar and CMan, and I wasn't being sarcastic, actually.
If you suggest using capital letters, I suggest using a C prefix.
Point is, this is entirely a matter of style, so there's no right or wrong. You can't say anyone should use capital letters for types. If you can that, then I can say they should be prefixed with a C.
Why should we start classes with a 'C'? Whats the benefit?
What if we define types starting with a capital, objects with lower case, constants all capital and functions like types.
Learn C++ (C++ Books, C Books, FAQ, Forum Search)
Code painter latest version on sourceforge DOWNLOAD NOW!
Download FSB Data Integrity Tester.
Siavosh K C
If you want to do
CCar Car;
I never reserve myself to create objects starting with lower case.
I hate camel case. And for others who do, the "C" prefix is helpful.
I append _t to typedefs, as well. I prepend S to structs. I suppose you could just add T or prefix or postfix something else, but that's up to you.
Why should anyone do that? It's like changing int to tint so we can have tint int;
I read somewhere the reason MFC uses that style is because at the time MFC was been implemented namespaces were not implemented.
Learn C++ (C++ Books, C Books, FAQ, Forum Search)
Code painter latest version on sourceforge DOWNLOAD NOW!
Download FSB Data Integrity Tester.
Siavosh K C
Why? Because some people prefer it. I do, for example.
It's a style choice! Nothing wrong with that.
It's a step above/below Hungarian notation is what it is.
Absolute nonsense.
Is differentiating member variables from local variables hungarian, too?
I don't get why you're so mad about a simple fact. To address your question, no, you can differentiate from members and locals without resorting to one-letter type-related prefixes. Don't be mad that your Hungarian like approach is unpopular. C++'s type system makes using it extraneous. That's all -- in other places where types are dynamic it's more useful, as you probably know.
