🚀 go-pugleaf

In article <3viuuv$dcl@news.rwth-aachen.de>, Peter Haumer
(haumer@informatik.rwth-aachen.de) wrote:

> The macro STRING_CONSTRUCTOR in _string.c limits the size of strings to 
> 512 bytes. I don't think that this is necessary. Does anybody know, why it
> is is implemenented in this way? 

Because it's implemented incorrectly.  Even worse, "512" is hard-coded.
It should be a macro, at least.

> There should be at least an assertion for a precondition or a size check 
> in the macro. Programs which want to construct longer strings with varargs
> just crash/core dump.

The only *portable* way (other than writing one's on sprintf-like
function) to handle very long strings is to write them to a file (with
vfprintf...) and then read the file back into memory.  The
sprintf... functions have no provisions for checking buffer overflow,
which makes checking the precondition very difficult.

A nicer solution, IMO, is for LEDA authors to define left-shift
operators like this:

string & string::operator<<(int i) { ... }
string & string::operator<<(double d) { ... }
etc...

Then you could say:

string s;
int a=4, b=6;
s << a << " times " << b << " equals " << a*b;

which would append to s.  This is type-safe and more "C++-like".

--
David F. Skoll
<a HREF="http://www.doe.carleton.ca/students/dfs/">
Click here for my home page</a> "Query two pi" on typewriter.

I discovered another bug in STRING_CONSTRUCTOR:  After the call
to vsprintf(), there should be a va_end call.

--
David F. Skoll
<a HREF="http://www.doe.carleton.ca/students/dfs/">
Click here for my home page</a> "Query two pi" on typewriter.

Guess what this program does:

#include <LEDA/string.h>
#include <iostream.h>

int main()
{
   string s("Foo Bar Baz");
   char const *pstr;

   pstr = ~s;
   cout << pstr << endl;
}

I think I'll just weep wearily into a good programming-style book...
This takes operator-overloading to absurd new depths.

--
David F. Skoll
<a HREF="http://www.doe.carleton.ca/students/dfs/">
Click here for my home page</a> "Query two pi" on typewriter.

In article <DCLDB9.ArI@cunews.carleton.ca> dfs@doe.carleton.ca (David F. Skoll) writes:
>From: dfs@doe.carleton.ca (David F. Skoll)
>Subject: Re: STRING_CONSTRUCTOR limits strings to 512 byte
>Date: Mon, 31 Jul 1995 17:45:09 GMT

>In article <3viuuv$dcl@news.rwth-aachen.de>, Peter Haumer
>(haumer@informatik.rwth-aachen.de) wrote:

>> The macro STRING_CONSTRUCTOR in _string.c limits the size of strings to 
>> 512 bytes. I don't think that this is necessary. Does anybody know, why it
>> is is implemenented in this way? 

>Because it's implemented incorrectly.  Even worse, "512" is hard-coded.
>It should be a macro, at least.

>> There should be at least an assertion for a precondition or a size check 
>> in the macro. Programs which want to construct longer strings with varargs
>> just crash/core dump.

>The only *portable* way (other than writing one's on sprintf-like
>function) to handle very long strings is to write them to a file (with
>vfprintf...) and then read the file back into memory.  The
>sprintf... functions have no provisions for checking buffer overflow,
>which makes checking the precondition very difficult.

>A nicer solution, IMO, is for LEDA authors to define left-shift
>operators like this:

>string & string::operator<<(int i) { ... }
>string & string::operator<<(double d) { ... }
>etc...

>Then you could say:

>string s;
>int a=4, b=6;
>s << a << " times " << b << " equals " << a*b;

>which would append to s.  This is type-safe and more "C++-like".

>--
>David F. Skoll
><a HREF="http://www.doe.carleton.ca/students/dfs/">
>Click here for my home page</a> "Query two pi" on typewriter.

The latter suggestion is actually implemented in classes strstream and 
ostrstream. Being part of the C++ standard library, they are probably 
preferable to building your own string extensions for this purpose.

Ron van der Wal.

In article <DCLDB9.ArI@cunews.carleton.ca>, dfs@doe.carleton.ca (David F. Skoll) writes:
|> In article <3viuuv$dcl@news.rwth-aachen.de>, Peter Haumer
|> (haumer@informatik.rwth-aachen.de) wrote:
|> 
|> > The macro STRING_CONSTRUCTOR in _string.c limits the size of strings to 
|> > 512 bytes. I don't think that this is necessary. Does anybody know, why it
|> > is is implemenented in this way? 
|> ...

|> A nicer solution, IMO, is for LEDA authors to define left-shift
|> operators like this:
|> 
|> string & string::operator<<(int i) { ... }
|> string & string::operator<<(double d) { ... }
|> etc...
|> 
|> Then you could say:
|> 
|> string s;
|> int a=4, b=6;
|> s << a << " times " << b << " equals " << a*b;
|> 
|> which would append to s.  This is type-safe and more "C++-like".
|> 
|> --
|> David F. Skoll
|> <a HREF="http://www.doe.carleton.ca/students/dfs/">
|> Click here for my home page</a> "Query two pi" on typewriter.
|> 

Why don't you simply use the strstream class ? It's much more elegant (i.e. it
allocates it's own memory as needed) than LEDA's printf-like Constructors, and 
i think it's pretty standard in the C++ world.

I've just looked over the code in _string.cc , it's the most ugly stuff I've
seen so far (and i've produced many ugly things in my lifetime ...).  I think
working with fixed sized arrays for creation/formatting is generally a stupid
idea. They've got so many beautiful data structures, why don't they simply keep a
list of fixed size buffers and cat them together when reading/construction is
complete ?

Besides this, i like the LEDA data types very much, especially the list/graph
stuff. They've just better put some more work into the basics & into Makefile/
configuration stuff (when i get a LEDA version, i don't even try to compile with
their provided Makefiles, i throw them away just after unpacking ... ) 

-- 

===============================================================================
  					       |
  _/_/_/_/_/_/_/_/_/_/_/      _/       _/_/    |      
          _/                 _/_/    _/ _/     |  Thomas Malik     
         _/                 _/  _/ _/  _/      |  malik@serv-400.dfki.uni-kl.de    
        _/                 _/    _/   _/       |  malik@sun.rhrk.uni-kl.de
       _/                 _/         _/        |  Berliner Str. 5-11
      _/                 _/         _/         |  6750 Kaiserlautern     
     _/                 _/         _/          |  (0631) 79868 
    _/  _/             _/         _/  _/       |