Re: TeamB, Borland, admit obvious

From: Rudy Velthuis (TeamB) (rvelthuis_at_gmx.de)
Date: 03/05/04 

Date: Fri, 5 Mar 2004 21:08:12 +0100

At 20:39:01, 05.03.2004, Hrvoje Brozovic wrote:

> "Rudy Velthuis (TeamB)" wrote in message
> > At 18:33:13, 05.03.2004, Eric Grange wrote:
> >
> > > > But stuff that is already critical in D7
> > >
> > > Doesn't apply to string concatenations, they typically *aren't*
> > > critical in D7.
> >
> > They are. Code that does that, as I already said, is badly designed.
> > The fact that it didn't bite you as much as it did in D8 doesn't
> > change that. Such code, using simple string concatenation (and it
> > doesn't really matter a lot, whether Concat is used, or +) to build
> > large strings (a few won#t matter, not even in D8) is simply a sign
> > of lacking design.
> >
> This is to what I am objecting.

> What piece of handling string concat in D7 is so critical?

Reallocation of the string. The more you add to it, the more must be
copied over to the new location. In such cases, it really pays out to
allocate a sufficiently large buffer, and add into that buffer. If you
must reallocate, do it in larger chunks, to avoid constant copying.

I thought such things were basic common knowledge.

 Please point me exact what is wrong
> if you preallocate flat memory range with SetLength,
> an after that start stuffing strings with s1 += s2?

Because if you add, you change the length again. So:

  SetLength(S, 100000);
  for I := 1 to 1000 do
    S := S + 'Hello';

will get you a string of size 105000, give or take a few bytes. It will
not, as you might expect, concatenate into the buffer.

 
> As pointed out in exhibits A and B, it is what Borland
> recommends,

No, nowhere does Borland recommend using SetLength, and nowhere do they
recommend using + for *mass* concatenation. And mass concatenation is
exactly the code Eric showed to demonstrate his point (I'd have to look
for the message, it is a while back).

> and as shown in C and D, it is obvious that
> it kind of work.

"Kind of" being the keyword here.

 They check if there is enough free space
> after s1, and there is high probability that it is, since it was
> created with SetLength,

No, sorry. The s2 will be added to the end of those allocated bytes, not
into the buffer:

  SetLength(S, 40);
  S := S + 'Hello there';
  Writeln(Length(S)); // it's not 11, it's not 40, it's 51!

> and second string is copied after
> end of the first one, counters are adjusted and that is all.

What counters?

> Reallocation is called, but Borland clearly made some
> effort to avoid moving memory without reason.

Yes.
 
> And idea of "designing" way to "build string" is hilarious.

Ask any C programmer. They will tell you how to do it: allocate a large
buffer, and add into that buffer. That is not possible using the

  S1 := S1 + S2;

idiom. You'll have to do the same as the C programmer. And StringBuilder
does that for you.
 
> As if I have nothing better to do but to search for
> "solution" for such trivial task.

It is not a trivial task if you must concatenate lots of strings.
 
> I can't wait to see solution to integer addition problem.

Your argument would be better presented without the condescending tone.

> Even more funny is that you of all people
> use so microscopic approach for performance
> considerations as designing how to build strings.

Why do you say "you of all people"? In what way am I special?

> I am not expecting best possible performance
> from my use of s1 += s2; What I expect out of it,
> is not to hang my machine.

It won't, unless you use very many.

> But, since you stating
> that is possible in win32 also, I am anxious to see
> your scenario how to hang computer with
> SetLength final size, s1 += s2 in the loop.

I'd love to see how you would use SetLength(s1, final_size), and then do
s1 := s1 + s2 to build a string. As I showed above, that won't work.

> And, please post QC report to false D7 documentation.

The documentation is quite right. But it seems you draw the wrong
conclusions. 

-- 
Rudy Velthuis (TeamB)
"Learning is what most adults will do for a living in the 21st century."
 -- Perelman

Relevant Pages

  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Secure C library
    ... I read much of the new "security TR", and gee, I don't know. ... the buffer from the buffer size. ... It is not hard to design a better form of buffer and string handling. ... but this is just one example of how thoughtful interface design can ...
    (comp.std.c)
  • Re: Secure C library
    ... >> string functions don't make much sense once you add bounds-checking ... >> designing an interface just for the purpose of reducing the frequency ... > make buffer size decisions more visible, ... Bstrlib is also very interoperable with char *'s, ...
    (comp.std.c)
  • Re: why I can not write to the file after initialize the MFC in a service program
    ... you check EVERY return from a call that can fail, ... Why do you need an intermedate buffer to write literal strings anyway? ... For example, if AfxWinInit fails, you copy a 45-character string into a ... So you are going to try to initialize MFC EACH TIME THROUGH THE LOOP? ...
    (microsoft.public.vc.mfc)
  • Re: Calling dll functions from vb.net with pointer returns!
    ... (ByRef pulLen As Integer, ByVal pszFilter As String, ByVal ulFlags As ... OUT PTCHAR Buffer, ... Address of a buffer to receive a set of NULL-terminated device instance ... pszFilter must specify the name of a device ...
    (microsoft.public.dotnet.languages.vb)