[haiku-development] Re: BString on GCC4
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 20 Apr 2008 04:50:35 +0200
On 2008-04-20 at 02:40:28 [+0200], Rene Gollent <anevilyak@xxxxxxxxx> wrote:
>
> I'm curious, what's the point of this:
>
> // Unchecked char access
> char operator[](int32 index) const;
>
> #if __GNUC__ > 3
> BStringRef operator[](int32 index);
> #else
> char& operator[](int32 index);
> #endif
>
>
> the BStringRef version seems to hide the others for me in practical
> use, as something like: printf("%c", str[i]); now results in a warning
> on gcc4 specifying: "Cannot pass non-POD type BStringRef through ...,
> call will abort at runtime." Also, why both a char and char& version
> of the same operator?
One operator works on a const object. From a quick look at the sources, the
reason behind the BStringRef version seems to be to avoid having to make a
copy of a shared string. The passing through varargs is a little annoying
indeed; you have to explicitly cast to char.
I suppose we should rather get rid of the non-const version completely and
introduce a SetByteAt[Unchecked]() or something like this. Since BStringRef
is not inline, the operator call is unnecessarily expensive.
CU, Ingo
- Follow-Ups:
- [haiku-development] Re: BString on GCC4
- From: Axel Dörfler
- References:
- [haiku-development] BString on GCC4
- From: Rene Gollent
Other related posts:
- » [haiku-development] BString on GCC4
- » [haiku-development] Re: BString on GCC4
- » [haiku-development] Re: BString on GCC4
- [haiku-development] Re: BString on GCC4
- From: Axel Dörfler
- [haiku-development] BString on GCC4
- From: Rene Gollent