Re: error compiling qt frontend

[Kuba Ober]

On poniedziałek 29 lipiec 2002 10:15 am, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> | On środa 24 lipiec 2002 04:10 am, Angus Leeming wrote:
> >> On Wednesday 24 July 2002 7:25 am, Lars Gullik Bjønnes wrote:
> >> > Just make sure that QString::data is required to retrun a
> >> > null-terminated char const *.
> >>
> >> const char* data() const { return latin1(); }
> >>
> >> I don't have the Qt src to hand so can't dig any further.
> |
> | It does return a null terminated char const *, although please notice
> | that this pointer may point to garbage on any subsequent line of your
> | code, if the source QString was destroyed.
> |
> | Thus, I'd always do this (unless I'm the one owning the QString):
> |
> | char mybuf[512];
> | strncpy(mybuf, selectedFile().latin1(), sizeof(mybuf) - 1);
> | mybuf[sizeof(mybuf) - 1] = 0;
> | // sizeof()-1 so that the mybuf will always be zero-terminated
> | // even if latin1() returns a 512- or longer string
>
> So QString does not have a copy function? Like std::string does

It does have copy function to another QString. Yet, the pointer that latin1() 
or data() returns is alive only as long as:
1. that QString exists, and
2. nobody else changed the string and called latin1()/data() on it

So, it's always safe to copy it somewhere ASAP.

Alas, if you're using std::string, then obviously
std::string str = selectedFile().latin1() works all right.

Cheers, Kuba Ober