design question

[Grahamo]

Hi,

I'd like to get the opinion of this knowledgable group.

Basically we have 100 billions lines of legacy code that were written
in 1930. Hence there are no stl containers, no std::strings and we're
waaaaay back in the early days of C++. (OK I exaggerate just a little
but you get the drift).

We have a homegrown string class that behaves much like std::string,
call it ourString. ourString behaves much like std::string except that
it has a whole lot of extra methods defined. It inherits from a base
"Object" class a la java.

Object
^
|
String


Now I would like to see if I can get some improvements over the
existing code by using std::sting instead. If this is in place then I
get all the advantages of compiler optimisations and it brings us one
step closer to using stl and the newer features of C++. I can use stl
altorithms to implement the required methods on the class and reap the
advantages our that. i.e. speed and cleaner code.... no need to
reinvent the wheel etc.


My question is this. Is it worth my while embarking on this task? I
mean if I do write a class that encapsulates std::string and provides
the additional methods our custom String class defines, can I really
expect to see improvement. I would have thought yes. The additional
methods defined in the existing OurString will be implemented using stl
algorithms and I will be a little closer to the "stl way".

Or should I let sleeping dogs lie? Assuming the implementation will be
fine, is the net gain here worth the effort?

thanks much

GrahamO

 

[Nick Keighley]

I'd like to get the opinion of this knowledgable group.

Basically we have 100 billions lines of legacy code that were written
in 1930. Hence there are no stl containers, no std::strings and we're
waaaaay back in the early days of C++. (OK I exaggerate just a little
but you get the drift).

We have a homegrown string class that behaves much like std::string,

this is so scary... I think we're working on the same project. You're
Andrew
posting under another name, yes?

call it ourString. ourString behaves much like std::string except that
it has a whole lot of extra methods defined. It inherits from a base
"Object" class a la java.

Object
^
|
String


Now I would like to see if I can get some improvements over the
existing code by using std::sting instead. If this is in place then I
get all the advantages of compiler optimisations and it brings us one
step closer to using stl and the newer features of C++. I can use stl
altorithms to implement the required methods on the class and reap the
advantages our that. i.e. speed and cleaner code.... no need to
reinvent the wheel etc.

My question is this. Is it worth my while embarking on this task? I
mean if I do write a class that encapsulates std::string and provides
the additional methods our custom String class defines, can I really
expect to see improvement. I would have thought yes. The additional
methods defined in the existing OurString will be implemented using stl
algorithms and I will be a little closer to the "stl way".

Or should I let sleeping dogs lie? Assuming the implementation will be
fine, is the net gain here worth the effort?

I'm dubious unless the home-brew string class is *really* poorly
implemented.
Yes the inside of the class becomes more modern but there will still be

10s of KLOCs of client code.

The additional fun I have is third party libraries without source or
adequate
documentation.

 

[Earl Purple]

this is so scary... I think we're working on the same project. You're
Andrew
posting under another name, yes?

Well presumably your archaic code has no abstract base classes either,
all the headers are in one directory and everything includes and calls
everything else.

If you can somehow work out what the real entry points are to each part
of the code, then create abstract base classes, and then create
implementations for them that call the old code, and get your new code
to call through these abstract base classes.

Beware though that std::string is not portable across libraries. You
can use boost::shared_array<char> to replace it for that purpose (if
you and everyone else uses the same version of boost), and you can set
a custom deleter if necessary.

 

[Greg]

Hi,

I'd like to get the opinion of this knowledgable group.

Basically we have 100 billions lines of legacy code that were written
in 1930. Hence there are no stl containers, no std::strings and we're
waaaaay back in the early days of C++. (OK I exaggerate just a little
but you get the drift).

We have a homegrown string class that behaves much like std::string,
call it ourString. ourString behaves much like std::string except that
it has a whole lot of extra methods defined. It inherits from a base
"Object" class a la java.

Object
^
|
String


Now I would like to see if I can get some improvements over the
existing code by using std::sting instead. If this is in place then I
get all the advantages of compiler optimisations and it brings us one
step closer to using stl and the newer features of C++. I can use stl
altorithms to implement the required methods on the class and reap the
advantages our that. i.e. speed and cleaner code.... no need to
reinvent the wheel etc.


My question is this. Is it worth my while embarking on this task? I
mean if I do write a class that encapsulates std::string and provides
the additional methods our custom String class defines, can I really
expect to see improvement. I would have thought yes. The additional
methods defined in the existing OurString will be implemented using stl
algorithms and I will be a little closer to the "stl way".

Or should I let sleeping dogs lie? Assuming the implementation will be
fine, is the net gain here worth the effort?

I would guess that there is probably little to be gained by such an
overhaul. Unless the string class is incredibly inefficient, the
likelihood that std::string would offer much in the way of significant
performance improvements seems slim. In fact, string classes, despite
all the attention paid to them, rarely become a performance bottleneck.
And while the Standard Library is great, particulary when starting a
new project, it is not an order of magnitude better than every other,
similar library. So I think you may be overestimating the benefit of
using the standard library, when another working library already
exists. Besides, using the standard library is not an all-or-nothing
proposition; it certainly is possible to use much of the library
(<algorithm> or <functional> for instance) without bringing in
std::strings.

Another point to consider is that although the code may be old, it has
probably also been thoroughly debugged over time. Working code has
value that is often overlooked, at least until someone starts to
overhaul it. There are few things more disheartening than to have bugs
start to appear in parts of a program that have been stable for years.

I would suggest applying the "Open-closed" principle here, because I
think it may be very apt. It states that existing code is "open to
extension", but "closed to modification". And I take that to mean that
as long as time is spent re-writing code to do pretty much what it did
before, the chances of making any real progress in terms of the
application, are probably pretty small.

Greg

 

[Grahamo]

Greg,

You totally grasped the problem given me the info I'm after.

At the end of the day this code *has* been thoroughly debugged over
time and I reckon the existing legacy string class works efficiently
enough. I'll let sleeping dogs lie

G

 

[roberts.noah]

I would suggest applying the "Open-closed" principle here, because I
think it may be very apt. It states that existing code is "open to
extension", but "closed to modification". And I take that to mean that
as long as time is spent re-writing code to do pretty much what it did
before, the chances of making any real progress in terms of the
application, are probably pretty small.

The existing code has to follow the open-closed principle in order to
apply that logic. If the existing code is not open to extension for
instance, you're kind of screwed. I run into that a LOT.

 

[Nick Keighley]

Well presumably your archaic code has no abstract base classes either,

no, not quite that bad. There is heavy use of inheritance. Perhaps too
heavy.
I think I've seen cases that were 10 deep. Plus heavy use of multiple
inheritance.

all the headers are in one directory and everything includes and calls
everything else.

the project is subdivided into packages and directories. Each class has
a .h and a
..cpp. Some interface classes only have a .h. But sometimes it seems
like
everything depends on everything else... Builds tend to be slow.

If you can somehow work out what the real entry points are to each part
of the code, then create abstract base classes, and then create
implementations for them that call the old code, and get your new code
to call through these abstract base classes.

Beware though that std::string is not portable across libraries.
really?!

You
can use boost::shared_array<char> to replace it for that purpose (if
you and everyone else uses the same version of boost), and you can set
a custom deleter if necessary.

oh and there about 6 different "standard" exception hierarchies. My
favourite is
that one that stores internal state but has only private methods to
access it. I
guess I'm supposed to access the state using the debugger.


--
Nick Keighley

The fscanf equivalent of fgets is so simple
that it can be used inline whenever needed:-
char s[NN + 1] = "", c;
int rc = fscanf(fp, "%NN[^\n]%1[\n]", s, &c);
if (rc == 1) fscanf("%*[^\n]%*c);
if (rc == 0) getc(fp);