Quote:Original post by stonemetal
That is the thing about hungarian notation most people got it wrong. Here is an interesting article explaining how to do it right.
http://www.joelonsoftware.com/articles/Wrong.html

In his specific example, making two new classes equivalent to the first (possibly publically derived from it) with an explicit conversion that does that for you would be leagues better as it would handle the conversion itself. Code shouldn't just "look wrong", if something is always wrong you should be prevented to write it. It's a bit orwellian but in this case it's justified - if you can't write invalid code that is vulnerable (or wrong), you won't. If somebody really really wants to he'll have to use even much more wrong constructs or seek help from somebody - who would be well able to explain why it's forbidden and what to do instead.

Prefixes aren't your friend, they're your warts. The compiler is your friend - let him do the dirty work.

Just thought I'd chip in with my 2p here regarding the classes / struct's discussion.

For me the right time to use a struct is when I want to map out some memory. Most commonly I use C-style structures when I'm doing low-level memory handling with pure pointers and it's more important to me to see the size / layout of the memory than writing an API abstraction. Off the top of my head some common situations where I feel this is necessary are when dealing with file io and network packets.

Often when I want the object to perform some processing on its data or perform otherwise non-trivial interactions with other objects I promote the object to a class.

Although it is possible to code an API which will hide much of the low-level interaction with memory and thus mostly avoid the C-style approach to memory handling, I prefer to hide these things from other programmers but not from myself.

Finally, when it is unavoidable that an unknown quantity of memory has to be thrown around I use a utility class which wraps the memory in an object and using C++ template functions it provides a simpler API for reading / writing the memory.

Maybe this is just me, but I generally prefer const char* over const std::string&. The reason is I can pass either a const char* or a std::string (vis c_str()) without needing to contruct a string object in the former case. Since a lot of the time all that's done with the string is to assign it to a member std::string or a simple comparison, it seems pointless to dynamically allocate a new string to hold a non-changing copy.

Quote:Original post by dmatter
Pass const references: const std::string& filename

Will that solve the error?

Quote:Original post by dmatter
But no, I'm not the author; at the risk of sounding naive, I don't know what Dark Matter is, I assume it's a novel.

It's a game.

Edit: A game I've downloaded that didn't work on my computer. But I tried to install it now and run it and it worked now and the graphics is great. [smile]

[Edited by - programering on January 2, 2008 5:36:29 PM]

Quote:Original post by programering

Quote:Original post by dmatter
Pass const references: const std::string& filename

Will that solve the error?

Sorry, I saw now:

game.cppf:\projects\programming\klingis entertainment\klingis 2d\sdl - 1 sprite\pure c++\game.cpp(24) :error C2664: '__thiscall CFile::CFile(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)' :cannot convert parameter 1 from 'char [9]' to 'class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &'        A reference that is not to 'const' cannot be bound to a non-lvalue

By the way, why doesn't a non-const std::string &reference work?

[Edited by - programering on January 2, 2008 10:42:22 AM]

How do I get rid off the need to write std:: before?
The const std::string &reference parameter declarations are getting a little bit too long.