From: Thomas Witt (witt_at_[hidden])
Date: 2002-08-30 10:46:26
-----BEGIN PGP SIGNED MESSAGE-----
On Friday 30 August 2002 16:52, Carlo Wood wrote:
> On Fri, Aug 30, 2002 at 03:54:20PM +0200, Thomas Witt wrote:
> > > void demangle_type(std::string & t_o, std::string const & t_i);
> > > void demangle_symbol(std::string & s_o, std::string const & s_i);
> > Take my apologies for the possibly dumb question, but what's wrong with
> > std::string demangle_type(std::string const & t_i);
> The function appends its data to the string.
- From a usability point of view this kind of interface is very problematic (to
say the least). Not only has the user (and the maintenance programmer) to
remember where the "hidden" output parameter is (btw it's completely
invisible at the call site). He has to remember the "non-obvious" semantics
as well. Unless there is a compelling reason I would not like to see this
kind of interface in the public part of a library.
> This allows to 'construct' a string without unnecessary
> need to copy strings.
> For example:
> std::string out = "You are inside ";
> demangle(out, mangled_function_name);
The blunt answer would be : "Hooray you have managed to save a string copy in
debug code, so what?". Seriously I don't think it's worth it. Furthermore I
think that there is a good chance of your claim being wrong.
Somewhere inside demangle you might write something like this:
t_o += demangled_name;
Depending on the history of t_o this might trigger an allocation and a string
> Your prototype can always be added as a wrapper without extra cost.
This is interface bloat. The ideal library API presents exactly one way to
perform a certain task.
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk