Sun 2003-06-29 11:13, Bob Lawrence (3:712/610.12) wrote to Andrew Clarke:

 BL>> For instance, in C there is strcpy(), StrCopy in the VCL and
 BL>> they treat the nul terminator differently.

 BL> If you create a string variable in the VCL and then use strcpy(), it
 BL> only copies as far as the *first* null.

That's to be expected...

 BL> If the variable is three bytes long and you try to copy four into it,
 BL> it truncates. It works okay with StrCopy(). I assume there are others
 BL> I haven't found yet.

Um, I think I'm missing something here.  Can you give an example?

StrCopy() isn't part of the VCL anyway.  It's in the Strings unit in
Borland Pascal 7.0 from 1992 and has found its way into the SysUtils
unit in Delphi.  It's functionally equivalent to strcpy() in C.

 BL>> In C, you need to give the adress of a data block, in the
 BL>> (pascal) VCL there is no need for that. There is no need to
 BL>> typecast in C, so long as you know what you're doing, in the
 BL>> Pascal VCL you have to typecast everything and sometimes it
 BL>> won't let you.

 AC>> Not sure I understand this.

 BL>  One of the advantages of C (over Pascal), is that a variable memory
 BL> is anything you want it to be. If you have a four-character string,
 BL> you can use it as an integer. Pascal won't let you do that unless you
 BL> do a typecast, and some typecasts (like that one) aren't allowed at
 BL> all. You have to work around it. 

You can either use pointers or the Absolute keyword.  Both of these
examples will work in Borland Pascal 7 and Delphi 7 (10 years
difference!), and also Free Pascal:

{ test.pas }

var
  i : longint;
  p : PChar;

begin
  i := 0;
  p := {at}i;
  p[0] := chr($ff);
  p[1] := chr($ff);
  writeln(i);
end.


{ test2.pas }

var
  i : longint;
  p : array[0..1] of char absolute i;

begin
  i := 0;
  p[0] := chr($ff);
  p[1] := chr($ff);
  writeln(i);
end.

 BL>  What's STL? I've never heard of STL Class.

The Standard Template Library.  Basically a set of C++ header files
containing template classes designed for generic programming, where a
template class is roughly declared along the lines of:

#include 

using namespace std;

template  class myClass
{
public:
    myClass() {}
    ~myClass() {}
    size_t size() { return sizeof (X); }
};

int main()
{
    myClass obj;
    myClass obj2;

    cout << "sizeof obj == " << obj.size() <<
" byte(s)" << endl;
    cout << "sizeof obj2 == " << obj2.size() <<
" byte(s)" << endl;
}

Basically the idea is you specify which datatype you want to use with the
class.  The STL expands on this concept allowing you to work with different
data types using the same set of routines, eg.

#include 
#include 

using namespace std;

typedef list mylist_t;

int main()
{
    mylist_t mylist;

    mylist.push_back(42);
    mylist.push_back(66);
    mylist.push_back(23);

    mylist_t::iterator i;

    for (i = mylist.begin(); i != mylist.end(); i++)
    {
        cout << *i << endl;
    }
}

This is a very basic example.  If you wanted to change the data type
stored in the list to an unsigned long all you would need to do is
change the definition of mylist_t from list to list.
 You can use any data type, including structs or classes (eg. have a
linked list of string classes using list).

This just scratches the surface though.  There are other "containers"
in the STL apart from linked lists.  There are also various standard
algorithms provided by the STL, eg. sorting.

I recommend "The C++ Standard Library" by Nicolai Josuttis if you want
to learn more.  It's an expensive book though, and prior knowledge of
how templates (and numerous other things) work in C++ is necessary.

 BL>  [later] RogueWave? They say it ships with CBuilder4, but it's not on
 BL> my hard drive. I'll have to see if it's on the CD.

That rings a bell.  Probably one implementation of the STL.

 BL>  Ahh. There is is! Now all I have to do is work out how to get it
 BL> included in the HELP files. The trouble with Win98 is that it loads
 BL> everything automatically, which is great when it works but it leaves
 BL> you quite unaware of missing bits.

I wouldn't recommend learning the STL from the help files.

 BL>  That's why God invented Basic... for dickheads. As soon as you start
 BL> using pointers, you *have* to know what you're doing, and how much
 BL> memory you have allocated for variables. I'm still stuck in the
 BL> old-fashioned idea of saving space and fast processing, while the use
 BL> of Objects seem to be moving back towards Basic.... heaps of memory
 BL> and who cares if it's slow... buy a faster computer.

I don't think there is any real correlation between code bloat and the
use of OOP programming.  Basic OOP concepts like constructors,
destructors, member functions and polymorphism require very little
overhead.  Nor does using the STL.  Code bloat is just caused by lazy
programming, lack of knowledge, tight schedules and insufficient
incentive for programmers not to write code in a certain way.

 AC>> str = "This"; str += " won't"; str +=
" overflow"; str += "
 AC>> at"; str += " all";

 BL>  I know all that, but every time you add to the buffer, the object
 BL> counts the extra and allocates new memory!

Probably not every time.  Most likely it's written in such a way that it
will allocate memory in larger blocks rather than based on exact memory.
requirements, eg.

str = "Hello";

might allocate 20 bytes, therefore

str += " world.";

wouldn't require an additional malloc() as the space is already
available.  The extra memory consumed is usually insignificant in
reality.

 BL> It's sloooow,

It may be slower than using strcat() in some cases, but the benefits
outweigh the disadvantages, particularly if you use the C++ string class
rather than the AnsiString class, since the former can be optimised by
the compiler due to it being a template class (which means certain
operations can be done inline).

 BL> plus you can't reuse *that* memory because it could be anywhere, split
 BL> up all over the place.

I think you'll find the string is stored in a single sequential block of
memory.  This is certainly true for the C++ string class (according to
the book I mentioned above), anyway.  A library that stored a complete
string in memory fragments would be quite complex and unnecessary.

-- mail{at}ozzmosis.com

--- timEd/FreeBSD 1.11.b1