Hi!

void func(char *s)
{
   printf("%s",s);
}
---------------
I understand this version should be fine:

AnsiString s="aa";
s=s+"bb";
func(s.c_str());

because the value kept by variable s is guaranteed not to be overwritten  
when program counter enters func(). However, I am not sure the following  
version is always safe although I have not encountered any problem with it  
(yet):

AnsiString s="aa";
func((s+"bb").c_str());

My concern about the second version is that I wonder the data at memory  
address pointed to by c_str() can be overwritten by other processes or  
threads when program counter enters func() and the memory is being heavily  
used.

Clarifications will be much appreciated!

CN

"Ed Mulroy [TeamB]"  wrote:
>

Ouch!

I only intended to say that I was impressed to read what
you offered. Pardon me if I'm unaware how often you scratch
yourself.

~ JD

Alan Bellingham wrote:

> 
> If it's not derived from the VCL TObject base, then I see no reason
> why it should not behave like a C++ object in every way. 
 
There *is* some magic with AnsiString, but I can't remember exactly
what. In particular, IIRC, the compiler refuses to allow you to use
AnsiString as a base class for your own classes...

- Roddy
 




-- 

> For someone who (almost) never visits the vcl group ...

FYIW:
I visit the VCL group each time I look at the newsgroups, many times per 
day, every day.  However I am not a "VCL guy" so normally leave the answers 
to those who know more about it than I.

..  Ed

> JD wrote in message
> news:47787a49$1@newsgroups.borland.com...
>
>> AnsiString is implemented in C++ and not in Delphi.
>
> For someone who (almost) never visits the vcl group ... well
> done!
>
>> While it mimics what the Delphi string does it remains C++
>
> I've been spanked in one of delphi groups because I didn't
> know this. I presumed (in reverse) what Bob did and was
> shamed because I couldn't get the idea. For example, we have
> AnsiString::Length while delphi has length. The result is the
> same but it's implemented quite differently.
>
>> so [it] should follow the same rules regarding temporaries.
>
> Well ... while I tend to agree, B/CG isn't/hasn't been the
> most compliant; especially with vendor-specific stuff.

"Bob"  wrote:

>Exactly;  my point is that AnsiString is vendor specific, so
>I'm unclear on whether it can be expected to behave in the
>same manner as "standard" C++ objects.

If it's not derived from the VCL TObject base, then I see no reason why
it should not behave like a C++ object in every way. 

And as far as order and timing of temporary object lifetimes, I see no
reason why even VCL classes should behave differently, even though VCL
base classes may destruct in a distinctly odd (though predictable)
order.

Alan Bellingham
-- 
Team Browns
ACCU Conference 2008: 2-5 April 2008 - Oxford, UK

JD wrote:
> 
> "Ed Mulroy [TeamB]"  wrote:
> > 
> > AnsiString is implemented in C++ and not in Delphi.
> 
> For someone who (almost) never visits the vcl group ... well
> done!
> 
> > While it mimics what the Delphi string does it remains C++
> 
> I've been spanked in one of delphi groups because I didn't
> know this. I presumed (in reverse) what Bob did and was
> shamed because I couldn't get the idea. For example, we have
> AnsiString::Length while delphi has length. The result is the
> same but it's implemented quite differently.

This is what I get for tapdancing around the truth.   I was trying
to avoid the rabbit hole of discussing how the Delphi string
is emulated in C++  (the actual implementation is a mix of assembler
and C++ with Borland extensions, IIRC).

In hindsight, I should have just dived down the rabbit hole.

> 
> > so [it] should follow the same rules regarding temporaries.
> 
> Well ... while I tend to agree, B/CG isn't/hasn't been the
> most compliant; especially with vendor-specific stuff.
> 

Exactly;  my point is that AnsiString is vendor specific, so
I'm unclear on whether it can be expected to behave in the
same manner as "standard" C++ objects.

"Ed Mulroy [TeamB]"  wrote:
>
> AnsiString is implemented in C++ and not in Delphi.

For someone who (almost) never visits the vcl group ... well
done!

> While it mimics what the Delphi string does it remains C++

I've been spanked in one of delphi groups because I didn't
know this. I presumed (in reverse) what Bob did and was
shamed because I couldn't get the idea. For example, we have
AnsiString::Length while delphi has length. The result is the
same but it's implemented quite differently.

> so [it] should follow the same rules regarding temporaries.

Well ... while I tend to agree, B/CG isn't/hasn't been the
most compliant; especially with vendor-specific stuff.

~ JD

AnsiString is implemented in C++ and not in Delphi.  While it mimics what 
the Delphi string does it remains C++ so should follow the same rules 
regarding temporaries.

..  Ed

> Bob wrote in message
> news:4778370b@newsgroups.borland.com...
>
> Thomas is correct in his interpretation of the standard.  The standard
> also requires, IIRC, that such objects will be destroyed in reverse
> order of their creation.
>
> The only difficulty is that we are talking about AnsiString, which
> is (originally) part of a Delphi library and therefore a little
> beyond scope of the C++ standard.   The question therefore becomes:
> do the same rules apply with Borland-specific library features
> implemented in another language? 

Thomas Maeder [TeamB] wrote:

> "Remy Lebeau \(TeamB\)"  writes:
> 
> >> FWIW, bds2006 appears to not destruct the temporaries (it appears
> >> to create two for the (s+"bb").c_str() expression) until after
> return from >> the func() function call occurs.
> > 
> > It does create 2 temporaries, yes.  One to convert the char* to an 
> > AnsiString, and the other that the '+' operator returns.  But I
> > would think it should destruct the first temporary before func() is
> > called, since the call to the '+' operator is a function call of
> > its own, and the first temporary is not needed for the call to
> > func().
> 
> The ISO C++ Standard requires temporary objects to be destructed after
> the evaluation of the full expression whose evaluation caused them to
> be created.
> 
> The full expression is func((s+"bb").c_str()), so both temporary
> objects have to be destructed after func() returns.

Thomas is correct in his interpretation of the standard.  The standard
also requires, IIRC, that such objects will be destroyed in reverse
order of their creation.

The only difficulty is that we are talking about AnsiString, which
is (originally) part of a Delphi library and therefore a little
beyond scope of the C++ standard.   The question therefore becomes:
do the same rules apply with Borland-specific library features
implemented in another language?

"Thomas Maeder [TeamB]"  wrote in message 
news:m2sl1m3fx0.fsf@glue.ch...

> I don't know about AnsiString, but if s were of type std::string and
> its scope allowed other threads to get a hand at it, the memory that
> s.c_str() points to could very well be tampered with by these threads
> unless appropriate action is taken.

The same applies to AnsiString.


Gambit