libyuni : CustomString now replaces StringBase

Everything related to the code /
Tout ce qui touche au code
Post Reply
milipili
Posts: 545
Joined: Thu Nov 02, 2006 8:52 am
Location: Paris (France)
Contact:

libyuni : CustomString now replaces StringBase

Post by milipili » Tue Dec 14, 2010 8:44 am

In order to tag its first stable version in a few weeks, we need to replace the obsolete class `StringBase` by the new one far more efficient `CustomString`.
It may break a few things. If there any trouble, please let us know, on this forum or directly on the ml dev@libyuni.org.
Damien Gerard
Ta3d & Yuni Developer

User avatar
zuzuf
Administrateur - Site Admin
Posts: 3281
Joined: Mon Oct 30, 2006 8:49 pm
Location: Toulouse, France
Contact:

Re: libyuni : CustomString now replaces StringBase

Post by zuzuf » Sat Dec 18, 2010 3:47 pm

I've been trying CustomString and found that it currently lacks a few things:
  • no substr-like method either for ASCII or UTF8 strings
  • no overloaded operator+ (that could be overcome but it's annoying)
=>;-D Penguin Powered

milipili
Posts: 545
Joined: Thu Nov 02, 2006 8:52 am
Location: Paris (France)
Contact:

Re: libyuni : CustomString now replaces StringBase

Post by milipili » Tue Dec 21, 2010 10:59 pm

The substr like methods will never be provided by the Yuni API. From our point of view, it is a bad habit. It produce useless copies of the string (even when using reference counting). Those methods can always be replaced with the equivalent 'assign' or 'append'.
It is the same way for the operator + (but it was not voluntary this time).

The way of thinking is a bit different of course, perhaps annoying, but this can lead to produce very slow code.
Consider this code :

Code: Select all

String a = "abc";
String b = "def";
String c = "ghi";
String s = a + b + c;
It will produce 2 useless temporary strings, thus 2 malloc + 2 free + 2 memcpy (+ atomic barriers when it involves reference counting). Those expensive operations are wasted.

Code: Select all

String s;
s << a << b << c;
This code won't have such overhead and will produce the same result.

In several cases, it does not matter. However in practice the overhead is not neglectable. As game programming is one of the goals of Yuni, it seems to be a good reason for us.
Damien Gerard
Ta3d & Yuni Developer

Post Reply

Who is online

Users browsing this forum: No registered users and 37 guests