Re: A style question on const char* vs. std::string
Carlos Moreno wrote:
Zeljko Vrba wrote:
Hello! Consider a hypothetical situation:
std::map<type_a, const char*> some_map;
Another person has proposed to use std::map<type_a, std::string>, one of the
arguments being that "it's safer". Namely, referencing an unitialized element
in the map (some_map[blah]) will insert and return a default-constructed value
type. When the value type is const char*, its default is NULL, and this is
what gets returned to the caller, resulting in a crash as soon as the value is
used. Since the mapping is supposed to be 1:1, and referencing an
uninitialized element is a programmer's error, I believe that crashing is a
GOOD thing and an early indication of faulty program.
I have to stop you there and strongly contest this argument: a prorgam
crash CAN NOT be a good thing.
It may not be a good thing, but it is better than silently
giving a wrong answer, or doing something else wrong. If the
program is broken, the best thing that can happen is that it let
the user know this, as noisily as possible. (Obviously, it's
not a good thing that the program is broken.)
Under no circumstance (other than for
demonstration purposes --- as a teacher, I often enough find myself
trying to convince someone that something is bad by showing them that
if they do it, they'll make the program crash; in *those* situations
I consider the crash a good thing! :-))
An error in the program should be detected *at compile-time* if
possible; if not possible and you must wait until run-time to detect
it, then at least you should *detect* it, and not let it cause undefined
behaviour (you claim that the program crash --- really, the behaviour
is unpredictable; it usually ends up in a "crash").
Seen from that point of view... Yes, a guaranteed crash is what
is wanted. Dereferencing a null pointer is undefined behavior,
but on the systems I work on (all of them), the implementation
has defined it to cause a core dump. So returning a null
pointer is a good response to an error, IF he can be sure that
the user dereferences the pointer immediately. A better
solution, of course, is to wrap the access to the map with a
function which uses find(), and aborts (possibly via an assert)
if find() returns end().
I have in addition claimed that using std::string (in this particular
scenario, NOT in general!) would actually hide errors and push them deeper in
the program logic where they would be harder to discover. I argument this on
the grounds that std::string will silently insert and return an empty string
to the caller. This not only inserts a value in the map that logically should
not be there (remember, it's a map from an enum type to a list of constant
strings), but it does not signal it in any visible way. Empty string might
eventually cause program malfunction in a more subtle way, thus potentially
hiding bugs for a long time.
Ok, then don't allow that! Create your own class that encapsulates a
constant string (either a const char * or an std::string), and introduce
the behaviour of not accepting insertion of an empty element --- but you
do that not by letting the program crash, but by throwing an exception,
or something with perfectly defined and predictable behaviour.
Calling abort is perfectly defined and predictable behavior.
Throwing an exception when the programs invariants no longer
hold isn't. Throwing an exception when you detect a programming
error is an invitation to trouble.
A strange thing about your question --- you say that the fact that you
have an std::map for this task is not the core of the question; yet
your argument is solely based on the problems that arise from class
map silently inserting empty strings when you would want it to do
otherwise.
Well, the same problem would occur with std::set:-). Or with
the proposed unordered associative containers.
Could you use something other than map, instead of using
something other than std::string? Or, in addition to something other
than std::string?
But I think we agree on the principle. If std::map doesn't do
what you want, use something else (which, in all likelyhood,
will use std::map in its implementation).
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]