Re: Minimum VC++ for Multi-Core?
On Sun, 20 May 2007 23:00:38 GMT, MrAsm <mrasm@usa.com> wrote:
Hi Doug,
it's not clear to me why COW should be an important technique to be
used e.g. on strings.
i.e.: I think that every C++ programmer understands that for complex
objects (like strings), passing via const reference is a good practice
(to avoid the deep copy).
e.g.:
void Test( const std::string & s );
// and not:
// void Test( std::string s );
Maybe the only place where COW could help performances is in return
value, like:
std::string GetName(...);
is this correct?
Copy-on-write (the real kind) provides three things:
1. Performance gains (potential)
2. Memory savings (potential)
3. Exception safety for copying (absolute)
All these are potentially important, but I especially like (3). For many
applications, strings are as fundamental as integers, and it's nice to be
able to copy them (typically as members of other data structures) into and
out of containers without having to worry about exceptions. That said, the
broken form of COW allowed by the C++ Standard is not worth the trouble it
causes; it doesn't even provide (3).
And in fact, in some cases, I tend to prefer changing the prototype of
the method so that the return value becomes an out reference
parameter, e.g.
void ProcessBigString(
std::string & out,
const std::string & in
);
Is COW really useful in more advanced or exotic scenarios than the
common ones shown above?
BTW: I tend to prefer MFC CString's for GUI-based code (also because I
find useful the implicit LPCTSTR conversion operator, while on
std::string we must use the explicit .c_str() method); but I think
that the "core" non-GUI parts of programs should be better standard
C++, and so std::string and other STL classes should be used for that
part, IMHO.
Moreover, even if I'm *not* an advanced STL user, I find STL
containers and algorithms better designed (more carefully designed)
than MFC collections, but maybe this is just a matter of personal
preferences...
However, I wonder why the std::string class has no conversion operator
(operator const char*) and instead it requires explicit .c_str()
method. Is implicit conversion really so bad?
When you design a class, you should strive to create a minimal interface,
but adding conversion operators greatly expands the interface in
unforeseen, undesirable ways. It tends to allow various mistakes that are
difficult to make otherwise, e.g.
CString s = "whatever";
s = s-'1'; // Should have been +
delete s; // Oops
Silent conversions can also mask overloading problems, such as the
following, which is missing the const CString& overload:
void f(const TCHAR*);
void f(CString&);
const CString s;
f(s);
This will compile and may even work fine, but it may be suboptimal in terms
of efficiency or exception safety, depending on what f does. A long time
ago, I was actually bit by this, when a certain kind of "compressed"
floating point data type I created was working but not performing too well,
because I was missing an overload for that type, and the operator double()
conversion function I defined was being used. Also, conversion operators
tend to lead to ambiguities in overload resolution. For all these reasons,
and probably some I'm not thinking of, conversion operators fell into
disfavor quite a long time ago. It's considered better to make all casts
explicit, and if you think about it, c_str() is a kind of cast.
--
Doug Harrison
Visual C++ MVP