This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [Patch] Setup: Warn about dropped mirrors.

On 14 March 2006 15:37, Max Bowsher wrote:

> setup doesn't make _any_ C++ calls across DLL boundaries.

  Eminently good practice!

> Looks good, please go ahead and commit.


> It is my fond hope that one day we will have completely eliminated
> String from setup's code in favour of std::string. The current madness
> of using a mixture of two different string classes is silly.

  It wouldn't be mad if String++ was, for example, a lightweight and optimised
version of std::string... but it doesn't even behave the same, so it's not.
Having two nearly-identical classes with the same purpose and model and tiny
subtle differences in API... that's not quite so sane.  And in fact, when you
look at it closely, it seems that String++ is a replacement for std::string
that brings not just the benefits of an incompatible API, but on top of that
the extra juicy goodness of O(N^2) pessimisations:

String::operator + (char const *aString) const
  // expensive, but quick to code.
  return *this + String (aString);

... oh, and words cannot even express the pointlessness of implementing this
class when it has to do things like this ...

String::substr(size_t start, int len) const
  // Adapt the C++ string class
  return string(c_str()).substr(start, len);

  Gah!  Can we say "NIH syndrome"? :-O

  (Actually, if the /entire/ class just passed directly through to
std::string, it'd probably be for the best!)

  Alas, the source is riddled with the things.  It'll be a long and painful
job switching them over to std::string and trying to guarantee nothing breaks.

Can't think of a witty .sigline today....

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]