Sun 2003-06-01 10:27, Bob Lawrence (3:712/610.12) wrote to Andrew Clarke:

 BL> my complaint is that Borland uses the Delphi (Pascal) VCL in C++. 
 BL> Instead of the standard asci C they have written another set of 
 BL> functions under C++ objects, one set angled towards C and the 
 BL> other towards Delphi... and each is subtly different. For 
 BL> instance, in C there is strcpy(), StrCopy in the VCL and they 
 BL> treat the nul terminator differently.

I haven't come across a situation yet where it was difficult to convert between them.

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

Not sure I understand this.  My experience using the VCL in BC++Builder has
been positive, anyway.

 BL>> It's obvious that everyone at Borland *knows* that Pascal makes
 BL>> more sense, but in locking themselves into Windows, they are
 BL>> forced to adapt to C anyway. The result is that Borland is
 BL>> losing the plot. 

 AC>> I don't think this has anything to do with being "locked into
 AC>> Windows" at all. 

 BL>  As soon as you write a VCL using wrappers on the Win API you are
 BL> "locked into Windows." As soon as Borland moves away from asci C in
 BL> their Pascal VCL, it becomes almost impossible to port to Linux (which
 BL> is my main concern just now).

Use the CLX library instead of the VCL and your code should port to Linux
using Kylix with little drama.  Just stay away from calling any WinAPI
functions directly.

 BL>> In an AnsiString, can I treat it like a Pascal string, and use
 BL>> a char* pointer to an element... then use the old C functions
 BL>> like strstr(), strcomp(), strncomp(), etc?

 AC>> You can use the c_str() method to convert it to a C string.

 BL>  No... it only returns a pointer to THAT string, and won't let you
 BL> change it. If you want to run barefoot through the string, you have to
 BL> allocate new memory, copy across, make your changes, whatever... and
 BL> then copy it back to the original after the changes. It is *so*
 BL> clumsy! Or index the string and use .at() which is even worse.

I don't find it clumsy, but then I don't do that too often.  I'm leaning
towards using the STL C++ string class for almost everything anyway, so I
tend to avoid C strings more and more when I'm writing C++ code.

 BL>  Objects are fabulous, as a foolproof way to manipulate really
 BL> complex thingies, but when it comes to plain data (strings, etc) it is
 BL> much cleaner to just run up and down the actual memory using pchar in
 BL> Pascal or a pointer in C.

I'm less convinced of this when you still have people doing the equivalent
of stupid things like:

char str[5];
strcpy(str, "This");
strcat(str, " will");
strcat(str, " overflow");
strcat(str, " the");
strcat(str, " buffer");
strcat(str, " probably");
strcat(str, " causing");
strcat(str, " a");
strcat(str, " crash!");

The AnsiString and STL C++ string classes simply won't allow this to happen.

#include 
#include 

#ifdef __BORLANDC__
#include 
#endif

static void f1()
{
#ifdef __BORLANDC__
    AnsiString str;

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

    cout << str << endl;
#endif
}

static void f2()
{
    string str;

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

    cout << str << endl;
}

int main()
{
    f1();
    f2();
    return 0;
}

-- mail{at}ozzmosis.com

--- timEd/FreeBSD 1.11.b1