stonecobra wrote:

> affinciandos

What was that? :-D

(I guess what you're trying to say what "aficionado").

"stonecobra" <scott@stonecobra.com> wrote in message news:cgu2ia$1vad$1@digitaldaemon.com...
> Walter wrote:
> > "Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cgmr7f$1b90$1@digitaldaemon.com...
> >
> >>UTF-16 is not slower that UTF-8, even for pure ASCII. An app in which
all
> >
> > text
> >
> >>is ASCII is going to be just as fast in UTF-16 as it is in ASCII.
> >
> >
> > While the rest of your post has a great deal of merit, this bit here is
just
> > not true. A pure ASCII app written using UTF-16 will consume twice as
much
> > memory for its data, and there are a lot of operations on that data that will be correspondingly half as fast. Furthermore, you'll start swapping
a
> > lot sooner, and then performance takes a dive.
> >
> > It makes sense for Java, Javascript, and for languages where performance
is
> > not a top priority to standardize on one character type. But if D does
not
> > handle ASCII very efficiently, it will not have a chance at interesting
the
> > very performance conscious C/C++ programmers.
> >
> >
> They won't worry about it, because if they are true performance affinciandos, they will never create an array in D, because of the default initialization.   :)  so, ubyte[] it is <g>
>
> Seriously, is performance a concern for D?  If it truly is, this should be able to be turned off, if I take ownership of the potential consequences, no?

What about having some standard allocator for arrays so we can:

char[] str = new(noinit) char[100];

>
> Scott

Ivan Senji wrote:

> What about having some standard allocator for arrays so we can:
> 
> char[] str = new(noinit) char[100];

I like it!

Arcane Jill wrote:

> In article <cgra2k$udg$1@digitaldaemon.com>, Ben Hinkle says...
> 
> 
>>Why is toString such a hot topic anyway?
> 
> 
> Ask yourself why toString() exists at all. What does D use it for?
> 
> If it's an unnecessary, hardly-used function, then it should be removed from
> Object, because this is OOP, if something doesn't make sense for all Objects
> then it should not be defined for all Objects.
> 
> On the other hand, if it /is/ necessary for all objects, it shouldn't be biased
> one way or the other.

There are a couple of uses I use toString() for (in Java apps):

1: debugging.  Some useful info is derived when going through a
   graphical debugger (hovering over a variable will yield its
   toString() value).
2: easier inclusion in graphical lists.  I might have an object
   encapsulating the ISO-3166 country codes (long name and id),
   but use the toString() to show the long name.  That way in the
   drop down list I have everything I need to serialize the info
   to the DB.

But that's just Java....  D doesn't have decent IDE integration at this
time, nor does it have a standard GUI library that can do the #2
operation.

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:cgs9b4$1c0h$1@digitaldaemon.com...
> >news:cgrsnq$168a$1@digitaldaemon.com...
> >> Let's go back to Walter on this one. Walter - why does Object have a
> >toString()
> >> function? In what way does D require or rely on it? How badly would D
be
> >> affected if it didn't exist at all or if it were an interface?
> >
> >It's so when you pass an object to writef(), there's a way that it can be printed. But Ben is right, I don't see Object.toString() being used to generate very large strings, so any transcoding of it isn't going to be expensive overall.
>
> I don't get it :(
>
> Why isn't it possible to use a Stringizeable interface instead?

It is possible. But I think every Object should have some basic functionality, and one of those is to be able to have itself pretty-printed. This is also nice for a potential D debugger - it can take advantage of toString() to produce a user-friendly representation of the class data.

"stonecobra" <scott@stonecobra.com> wrote in message news:cgu2ia$1vad$1@digitaldaemon.com...
> They won't worry about it, because if they are true performance affinciandos, they will never create an array in D, because of the default initialization.   :)  so, ubyte[] it is <g>
>
> Seriously, is performance a concern for D?  If it truly is, this should be able to be turned off, if I take ownership of the potential consequences, no?

You can allocate them with std.c.stdlib.malloc() or std.c.stdlib.alloca(),
neither of which will do the initialization. Furthermore,
std.c.stdlib.alloca(n), where n is a constant, is handled as a special
optimization case, and will generate storage as part of the stack frame
setup (so it's zero cost).

Walter wrote:

> "stonecobra" <scott@stonecobra.com> wrote in message
> news:cgu2ia$1vad$1@digitaldaemon.com...
> 
>>They won't worry about it, because if they are true performance
>>affinciandos, they will never create an array in D, because of the
>>default initialization.   :)  so, ubyte[] it is <g>
>>
>>Seriously, is performance a concern for D?  If it truly is, this should
>>be able to be turned off, if I take ownership of the potential
>>consequences, no?
> 
> 
> You can allocate them with std.c.stdlib.malloc() or std.c.stdlib.alloca(),
> neither of which will do the initialization. Furthermore,
> std.c.stdlib.alloca(n), where n is a constant, is handled as a special
> optimization case, and will generate storage as part of the stack frame
> setup (so it's zero cost).
> 
> 
So, the C performance geeks will just stay with C, because that's how they'd do it now (no benefit to moving to d)?

Scott

In article <cgva1p$2gep$1@digitaldaemon.com>, Berin Loritsch says...
>
>Arcane Jill wrote:
>
>> In article <cgra2k$udg$1@digitaldaemon.com>, Ben Hinkle says...
>> 
>> 
>>>Why is toString such a hot topic anyway?
>> 
>> 
>> Ask yourself why toString() exists at all. What does D use it for?
>> 
>> If it's an unnecessary, hardly-used function, then it should be removed from Object, because this is OOP, if something doesn't make sense for all Objects then it should not be defined for all Objects.
>> 
>> On the other hand, if it /is/ necessary for all objects, it shouldn't be biased one way or the other.
>
>There are a couple of uses I use toString() for (in Java apps):
>
>1: debugging.  Some useful info is derived when going through a
>    graphical debugger (hovering over a variable will yield its
>    toString() value).
>2: easier inclusion in graphical lists.  I might have an object
>    encapsulating the ISO-3166 country codes (long name and id),
>    but use the toString() to show the long name.  That way in the
>    drop down list I have everything I need to serialize the info
>    to the DB.
>
>But that's just Java....  D doesn't have decent IDE integration at this time, nor does it have a standard GUI library that can do the #2 operation.

(Also refering to the 'most European chars. are ASCII' post just ahead of this
one)

And because of their likely small size, even if they are filled with non-ASCII characters, neither of those uses will realistically cause a performance bottleneck if toString() is UTF-8 by 'default', right?

No matter how efficient the memory management system is, if the 'default' is UTF-16 rather than UTF-8, most apps. will have to carry that extra de/allocation & initialization burden for no reason other than expediency or ignorance on the programmers part. Often twice the work and 1/2 the available memory for many of the same jobs.

UTF-16 used everywhere is probably one reason why heavy-use Java server apps. have the reputation as 'memory-thrashers'. And those runtimes have the benefit of many man-years of development, use-cases and experimentation behind them.

Since UTF-8 is the most efficient and adequate for most of D's currently forseeable uses, I say leave as is and put the 'burden' on the software that needs or benefits from other than UTF-8.

IMO, D really needs to be a general performance winner in order to get a toe-hold in the current market.

Walter wrote:

>> Seriously, is performance a concern for D?  If it truly is, this should be able to be turned off, if I take ownership of the potential consequences, no?
> 
> You can allocate them with std.c.stdlib.malloc() or std.c.stdlib.alloca(),
> neither of which will do the initialization. Furthermore,
> std.c.stdlib.alloca(n), where n is a constant, is handled as a special
> optimization case, and will generate storage as part of the stack frame
> setup (so it's zero cost).

And will they be garbage-collected? (just asking, I don't know.) Anyway it's an ugly interface to do it, maybe as has been suggested more standard allocators could be included for this case.

"Juanjo Álvarez" <juanjuxNO@SPAMyahoo.es> wrote in message news:ch0ajb$4d$1@digitaldaemon.com...
> Walter wrote:
> >> Seriously, is performance a concern for D?  If it truly is, this should be able to be turned off, if I take ownership of the potential consequences, no?
> > You can allocate them with std.c.stdlib.malloc() or
std.c.stdlib.alloca(),
> > neither of which will do the initialization. Furthermore, std.c.stdlib.alloca(n), where n is a constant, is handled as a special optimization case, and will generate storage as part of the stack frame setup (so it's zero cost).
> And will they be garbage-collected? (just asking, I don't know.)

malloc()? No, that will need an explicit call to free().
alloca()? No, that gets deallocated anyway when the function exits

> Anyway it's
> an ugly interface to do it, maybe as has been suggested more standard
> allocators could be included for this case.

You can also overload operators new and delete on a per-class basis, and provide a custom allocator.