Bernd Jendrissek writes:
44 modFormat.mod_type = "rocketseedFormat";
45 vformat[0] = "2";
(...)
rscode/rocketutil/mydap.cpp:44: warning: deprecated conversion from
string constant to 'char*'
rscode/rocketutil/mydap.cpp:45: warning: deprecated conversion from
string constant to 'char*'
Are we risking some sort of free()-based crashes by populating the
struct with string constants?
No. You built the structure, you clean it up.
Would it be safe to const_cast<char *> the string constants,
Yes.
or will I need to wrap each with a strdup() and ldap_mods_free()
it all after we're done?
No. ldap_mods_free() is just a helper function you could use if you
did build the structure with malloc and strdup. Or better yet, with
ber_memalloc and ber_strdup. (These are wrappers needed on Windows or
something because IIRC memory must be freed by the same DLL which
allocated it.)
This is just a case of "const poisoning" - once you slap a "const" at
a
declaration, it can easily spread out, demanding "const"s elsewhere too.
C started out without "const", even on string literals (which may not be
modified). C libraries and programs do tend to grow more consts over
the year, but C++ has gone much farther. For one thing, because it has
features like const_cast<> and mutable which make unwanted consts less
painful.
When defining a library data structure, one has to decide on things like
what to constify. The API has no reason to assume that the data is
intended to be const - in fact, ldap_mods_free() would look strange if
it was. Stranger than in C++, anyway.
--
Regards,
Hallvard