Quote:Original post by Koshmaar
and I'll probably add there some overloading stuff too.
Don't forget namespaces while you're at it.
Different names for functions that do the same?
Don't forget namespaces while you're at it.
Quote:Effective C++ by Scott Meyers, Item 18: Strive for class interfaces that are complete and minimal:
...the more functions in an interface, the harder it is for potential clients to understand... A class with 10 functions looks tractable to most people, but a class with 100 functions is enough to make many programmers run and hide...
A large interface can also lead to confusion. Suppose you create a class that supports cognition for an artificial intelligence application. One of your member functions is called think, but you later discover that some people want the function to be called ponder, and others prefer the name ruminate. In an effort to be accomodating, you offer all three functions, even though they do the same thing... The client is faced with three different functions, all of which are supposed to do the same thing. Can that really be true? Isn't there some subtle difference...possibly in efficiency or generality or reliability? If not, why are there three different functions? ...such a potential client is likely to wonder what on earth you were thinking (or pondering, or ruminating over).
(If you haven't read Effective C++ you're missing out (ditto for Effective STL and More Effective C++).
Enigma
Author
I've read More Effective C++ ( though that was long time ago), but not first one (I've heard that it's targeted at people who are starting to learn C++). I generally agree with him, but...
... such an user won't be thinking about it, if I'll describe it in the documentation.
...
...
...
(after a while)
Hmmmm, ok ok, no one ever reads documentation, I know, I know. Too bad, there are already many important things described.
Don't worry :-)
Anyway, thanks guys for opinions, I'm not going to implement this idea. EOT?
Quote:..such a potential client is likely to wonder what on earth you were thinking (or pondering, or ruminating over).
... such an user won't be thinking about it, if I'll describe it in the documentation.
...
...
...
(after a while)
Hmmmm, ok ok, no one ever reads documentation, I know, I know. Too bad, there are already many important things described.
Quote:
Don't forget namespaces while you're at it.
Don't worry :-)
Anyway, thanks guys for opinions, I'm not going to implement this idea. EOT?
Author
I'll use this thread to ask one more question, since it's naturally connected with what we were talking about so far.
Currently I have those functions that operate on single entries:
// for reading CFG_ReadBool () CFG_ReadInt () CFG_ReadFloat() CFG_ReadText () // for writing CFG_WriteBool () CFG_WriteInt () CFG_WriteFloat() CFG_WriteText ()and
// removing CFG_RemoveBoolEntry () CFG_RemoveIntEntry () CFG_RemoveFloatEntry() CFG_RemoveTextEntry () // existance checking CFG_BoolEntryExists () CFG_IntEntryExists () CFG_FloatEntryExists() CFG_TextEntryExists ()So, generally it goes like this: CFG_(Read|Write)(Bool|Int|Float|Text), CFG_(Bool|Int|Float|Text)EntryExists and CFG_Remove(Bool|Int|Float|Text)Entry.
As you see, there is little inconsistency in function names, some have "Entry" and some doesn't have it in their names.
I'd like to know what version would you, potential user [wink], personally prefer to use? Should I add "Entry" to read/write functions, or remove it from the other ones?
My personal preference would be for you to remove it; the less typing I have to do, the better (not that I'll necessarily be using your library, but still...). Since the functions are already prefixed with CFG, it'll be obvious that you're operating on entries in the configuration file, I think.
With that in mind, is it even necessary to differentiate between types in the functions for EntryExists and RemoveEntry? If it would be possible for you to make generic "CFG_EntryExists" and "CFG_RemoveEntry" functions, that don't require you to know and/or specify the type, it seems like it would be easier on the endusers.
Cheers,
Twilight Dragon
With that in mind, is it even necessary to differentiate between types in the functions for EntryExists and RemoveEntry? If it would be possible for you to make generic "CFG_EntryExists" and "CFG_RemoveEntry" functions, that don't require you to know and/or specify the type, it seems like it would be easier on the endusers.
Cheers,
Twilight Dragon
Author
Quote:My personal preference would be for you to remove it; the less typing I have to do, the better (not that I'll necessarily be using your library, but still...). Since the functions are already prefixed with CFG, it'll be obvious that you're operating on entries in the configuration file, I think.
To be honest, I also thought about it. What's more, is that all config file libs I checked, were using normal ReadXXX semantics etc.
But - my library has some other functions, that follow the convention of CFG_(DO)(WHERE), where DO = Open, Save, Select, Clear etc. and WHERE = File, Group and (to some extent) Entry, ie. CFG_OpenFile, CFG_SaveFile, CFG_SelectGroup, CFG_RemoveGroup etc. So, it would be more consistent to use Entry postfix in all functions that operate on single entries.
That's why I asked about it here - there are 2 possibilites, where neither is clearly better than other...
Quote:With that in mind, is it even necessary to differentiate between types in the functions for EntryExists and RemoveEntry? If it would be possible for you to make generic "CFG_EntryExists" and "CFG_RemoveEntry" functions, that don't require you to know and/or specify the type, it seems like it would be easier on the endusers.
Hmmm, interesting point. So, do you suggest to replace them with new one, or to add new one to lib, without throwing out anything?
I would suggest you replace the multiple type-specified functions with the new non-type-specified functions. Less confusion all around. End users are stupid creatures which are easily confused. ;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
