clayasaurus <clayasaurus@gmail.com> wrote:

> http://www.andromeda.com/people/ddyer/topten.html

I never thought of number 9.

-manfred

"Nod" <Nod_member@pathlink.com> wrote in message news:d99ups$osl$1@digitaldaemon.com...
> In article <d99sua$nkm$1@digitaldaemon.com>, pragma says...
>>
>>In article <d99kcq$hd0$1@digitaldaemon.com>, Brad Beveridge says...
>>>
>>>So for me the difference between C/C++ and D is like the difference between driving a Lada and driving a Merceedes - they both get you where you want to do, but one gets you there in style and comfort :)
>>>
>>
>>OT: Living here in the USA, I had no clue what a "Lada" was.
>>
>>So here we go. This is the low-end model on their website:
>>
>>http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html
>>
>>(at today's rate, thats $9634.39 USD.)
>>
>>And the sales pitch:
>>
>>This saloon not only looks good on the outside! Inside it offers spacious
>>accommodation for 5, easily accessed by 4 doors. The generous interior of
>>the
>>LADA 2110 offers even more comfort-from the four electric windows via the
>>remote
>>bootlock to the electronic immobilizer and the automatic heating system.
>>All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW (91hp)
>>and
>>unbeatable value for money!
>>
>>- EricAnderton at yahoo
>
> And here is the more traditional look of the (in)famous Lada:
>
> http://mclellansautomotive.com/photos/B31016.jpg
>

"Russian version of the Fiat 124: the "Zhiguli" (marketed abroad by name "Lada") (on the photo, the first version, called "2101", 1970, I guess). This car was, for the Russians, the "car of the people", like the Citroen 2CV in France, or the VW Beetle in Germany. It remains the best-seller in Russia, because of the essentiality, the low price and the facility of reparation."

And here is Lada "Revolution 2" :)

http://digilander.libero.it/cuoccimix/IMG_revolution2_front.jpg http://digilander.libero.it/cuoccimix/IMG_Revolution2_back.jpg http://digilander.libero.it/cuoccimix/ladatms2.jpg

Andrew.

On Tue, 21 Jun 2005 23:03:15 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> If D is to be used widely, do we need to add something new? Something that
>> no other language can do? (metaprogramming anyone?)

WARNING: for all those who can't stand posts containing opinion and little or no actual argument, stop reading now. I am posting this as a statement of opinion, in response to a statement of opinion. I am not trying to start any of these arguments (again) here and now. If we really want to start any of them up again I suggest a new thread for each one.

> I guess that first D needs features that C++ can do.
> Beg my pardon but this again about: opAssign & co.

I think there is some merit in opAssign for structs. Or, if ctors were added to structs having = call the ctor.

IIRC one of the design patterns/goals for D was that opAssign was not required for classes, instead copy constructors should be used. The idea being the explicit/obvious nature of constructors was preferrable to assignment overloading.

, 'const'

I've read a number of things on const (having never used it myself) to try and understand both sides of the argument. I think we need *something* to solve the desire to protect data and have the compiler help us detect violations to that protection. That said, I don't think we want to implement it exact as exists in C++.

I still believe that the first step is to create/enforce the readonly nature of 'in' arguments. Either compile time, runtime or both. i.e. It can be a runtime DBC feature i.e. disabled by -release mode.

, struct
> ctor/dtor.

IIRC a struct dtor isn't going to be possible without major changes to D. I can't recall why, or even who said it. Something to do with how/when they're called, the nature of structs i.e. a stack type, and the goal of keeping the compiler as simple as possible.

On the other hand a ctor is possible, and I think it'd be useful.

> and remove 'auto' as too controversial.

What's controversial about it?

> Without these it is too hard to C++ (btw and Java) developer to switch to D.

Being primarily a C developer I can't really comment, except to say that I have used C++ and Java and vastly prefer D for a number of reasons.

> Serious development teams where 'const' is a matter of culture and
> tool for collaborative work will definitely stay with C++.

I don't think the fact that it's 'culture' is particularly important. A truly good programming language will form culture, it wont follow it.

> In any case phobos shall include string class/object/whatever allowing
> to use it as std::string or java.lang.String.

I've yet to hear any reason that convinces me a string class is required.

I reckon the only problem at present is that library developers will choose different UTF types and we'll need to transcode string data to/from all our library calls. The only solution I can think of is to compile all libraries 6 times, a debug and release for each char type. This allows the application programmer to decide on the string type to use internally and link the correct libraries. Note, I'm only talking about selecting the 'internal' char type, not the char type of the various data sources your application might read/write.

Regan

In article <d99jqm$h1i$1@digitaldaemon.com>, clayasaurus says...

>Ok, I'm just wondering what people think. We all know to use the right tool for the right job, so when is D the right tool for the job?

A few additions/corrections/comments:

>C++ *******************************************************************
>
>Sucessor to C.
>
>Pros:
>  - object oriented

Optionally. C++ usually describes itself as "multiparadigm" - you can use it for procedural and/or OO and/or generic programming. Plus sort-of-functional if you squint a bit and have a strong stomach. I like OO, but it's not the only game in town, and there are domains for which it's an awkward fit.

>  - customizable

Could you expand on this? Do you mean the ability to specify custom ctor/dtor/assign/copy/conversion/operator semantics for UDTs?

+ Generalized RAII. I can't believe you missed this. It's THE killer feature, and could be made even better given a few tweaks.

+ Much tighter control over memory usage than GC. (Smaller working set, much less risk of unacceptable pauses.) A bit tedious when you don't need it, but irreplaceable when you do, and manageable given RAII. This point alone creates a sizeable niche in which D will _never_ supplant C/C++.

>Cons:

- No ABI. This has greatly hampered component-based development for C++. An awful lot of libraries expose their APIs as C, even if they're written in C++ internally.

>Java *******************************************************************

>Pros:

+ Some very good tools available, esp. IDEs (Eclipse, IDEA)

+ Reflection

>Cons:
>  - slow

Not particularly slow, with a decent JIT.

- Exception specifications were a bad idea with hindsight. Very tedious.

- Controlled by Sun.

>C# *******************************************************************

>Pros:

+ It really does feel like "Java done right". Mostly minor tweaks, but they add up. Earlier versions of D looked a LOT like C#; I think it's going to be tough to differentiate.

>Cons:
>  - it is microsoft only, unless you look at mono

And why wouldn't you look at Mono? From the FAQ:

"Mono today ships with a Just-in-Time compiler for x86, PowerPC, S390 and SPARC-based systems. It is tested regularly on Linux, FreeBSD and Windows (with the XP/NT core). There is also an interpreter, which is slower that runs on the x86, s390, SPARC, HPPA, StrongARM and PowerPC architectures."

C# is an ECMA standard, which makes it rather more "open" than Java. And it produces cross-platform binaries, like Java.

>D *******************************************************************
>
>Successor to C, C++, and Java.
>
>Pros:
>  - design by contract (none other?)

Eiffel pioneered this.

>Pros:

+ Easier binding to C libs than anything else except C++.

>Cons:
>  - not enough exposure / usage

Always a problem for new languages.

>  - not as many libraries as C++ / Java

And is going to look even worse given that language-neutral libraries look set to be the future, probably coalescing around the .NET and Parrot ABIs.

- Few tools as yet.

>So, here is what I am seeing D's niche as being...
>
>* A more powerful and easier to implement on different platforms (palm, etc.)

It's always going to lose out to VM-based languages (Java, C#) on portability.
And bear in mind that both Java (GCJ) and C# (Mono precompiler) can be compiled
to native code if you really want to.

cheers,
Mike

clayasaurus wrote:
> Brad Beveridge wrote:
> 
>> pragma wrote:
>>
>>> In article <d99kcq$hd0$1@digitaldaemon.com>, Brad Beveridge says...
>>
>>
>>
>>>
>>> OT: Living here in the USA, I had no clue what a "Lada" was. So here we go. This is the low-end model on their website:
>>>
>>> http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html
>>>
>>> (at today's rate, thats $9634.39 USD.)
>>>
>>> And the sales pitch:
>>>
>>> This saloon not only looks good on the outside! Inside it offers spacious
>>> accommodation for 5, easily accessed by 4 doors. The generous interior of the
>>> LADA 2110 offers even more comfort-from the four electric windows via the remote
>>> bootlock to the electronic immobilizer and the automatic heating system.
>>> All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW (91hp) and
>>> unbeatable value for money!
>>>
>>> - EricAnderton at yahoo
>>
>>
>>
>> I've recently moved to the USA, but couldn't think of a brand of car that has a poor reputation for comfort, etc :)  I'm originally from New Zealand, and Lada's (although they may be better now) don't have a good reputation there :)
>>
>> Brad
> 
> 
> I think the USA equivilent is the Geo!
> 
> Brand new...
> http://www.canadiandriver.com/articles/jc/images/98metro_cpe.jpg
> 
> What happens when you drive them too much...
> http://www.crh.noaa.gov/ict/wxstory/2001070813_mvc-016s.jpg
> http://www.awsomecar.com/pix/wreckmetro.jpg
> 
> I know someone who has a geo, it looks like crap.


The metro is the Suzuki swift, branded with the geo name.

I had a Geo Storm Gsi (which was basically an Isuzu Impulse) which had a handling package by Lotus, and it was a great car(one of my favorites that I have owned).

-DavidM

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opssrfjcrn23k2f5@nrage.netwin.co.nz...
> On Tue, 21 Jun 2005 23:03:15 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>>> If D is to be used widely, do we need to add something new? Something
>>> that
>>> no other language can do? (metaprogramming anyone?)
>
> WARNING: for all those who can't stand posts containing opinion and little or no actual argument, stop reading now. I am posting this as a statement of opinion, in response to a statement of opinion. I am not trying to start any of these arguments (again) here and now. If we really want to start any of them up again I suggest a new thread for each one.
>
>> I guess that first D needs features that C++ can do.
>> Beg my pardon but this again about: opAssign & co.
>
> I think there is some merit in opAssign for structs. Or, if ctors were added to structs having = call the ctor.
>
> IIRC one of the design patterns/goals for D was that opAssign was not required for classes, instead copy constructors should be used. The idea being the explicit/obvious nature of constructors was preferrable to assignment overloading.

For classes, yes, as variable holding class instance is always reference.
For structs situation is different. As a rule struct variable is holding
value itself. Naturally class builds a safe envelope around its data.
Class a,b; a = b; will not destroy data of a;
Struct does not have such feature. a = b there will overwrite 'a' value
silently.
And D is not helping you here to catch this moment.

Classes do not need opAssign. Morover there are just no such operation for class variables. Assignment  there is always assignment of references (not data)

>
> , 'const'
>
> I've read a number of things on const (having never used it myself) to try and understand both sides of the argument. I think we need *something* to solve the desire to protect data and have the compiler help us detect violations to that protection. That said, I don't think we want to implement it exact as exists in C++.

BTW: 'const' is a part of ANSI C too.

>
> I still believe that the first step is to create/enforce the readonly nature of 'in' arguments. Either compile time, runtime or both. i.e. It can be a runtime DBC feature i.e. disabled by -release mode.

I think it will be enough to be able to construct 'const' value types.

Let's say D will alow us to use keyword const as part of the type name: so I can create:

struct String
{
   private char[] data;
   char opIndex(int i) { ... }
   char opIndexAssign(int i, char c)   {  ...  }
}

struct const String
{
   private char[] data;
   this( char[] d ) { data = d; }
   char opIndex(int i) { ... }
}

And this is a different implementation of 'const' in C/C++.
Remeber that String.data is in fact reference to some memory location.
Having such 'const String' type you can safely return or pass references to
string data.

struct Url
{
    private char[] urlSource;
    const String domain() {  return  const String( urlSource[x..y] ); }
    const String protocol() {  return  const String( urlSource[x..y] ); }
}

The idea is simple: instead of only arryas (like char[] )
D must have another type - const arrays (  like const char[]  )
which are the same types but immutable, e.g.
const char[] type will have not opIndexAssign op available.

>
> , struct
>> ctor/dtor.
>
> IIRC a struct dtor isn't going to be possible without major changes to D. I can't recall why, or even who said it. Something to do with how/when they're called, the nature of structs i.e. a stack type, and the goal of keeping the compiler as simple as possible.

I hope this is the reason (and not because of some religion involved).
But compiler can handle now 'auto' for stack class variables.
I don't think that it will be more difficult to implement calling of struct
dtors
in the same manner.

The only complex thing is struct static initialization/destruction.
Also intitialization of array of structs could be an implementation problem.

>
> On the other hand a ctor is possible, and I think it'd be useful.
>
>> and remove 'auto' as too controversial.
>
> What's controversial about it?

auto A a = new A();
....
a = new A() ; // another A instance in the same var. What will happen
                     // with the first one? etc.

>
>> Without these it is too hard to C++ (btw and Java) developer to switch to D.
>
> Being primarily a C developer I can't really comment, except to say that I have used C++ and Java and vastly prefer D for a number of reasons.
>
>> Serious development teams where 'const' is a matter of culture and tool for collaborative work will definitely stay with C++.
>
> I don't think the fact that it's 'culture' is particularly important. A truly good programming language will form culture, it wont follow it.

Probably D will form a culture. If it would be enough members in
this society. The question is about a critical mass of number of "culture
carriers". And we are speaking about motivations to join the society, right?
'const' is the one.

Non-deterministic GC (the same as in D, btw) is available for C/C++ so
it is not a big motivation. What else? The only thing is 1) better syntax
and 2) set of ready to use builtin types. The latter is definitely not full
without 'const'.
The first is not full without opAssign and ctors/dtors.

>
>> In any case phobos shall include string class/object/whatever allowing to use it as std::string or java.lang.String.
>
> I've yet to hear any reason that convinces me a string class is required.

For your personally and for small projects probably not.

But consider development of components/libraries of a big scale.

char[] s = myobject.name();
int[ char[] ] map;
map[ s ] = 1;
....
// somewhere in myobject far far away somebody
// changed name data to let's say "two".
// and after that:

assert (map[ "one" ] == 1) ;

will throw an error.

Simple assignment of one character is making the whole system fragile.
Consider that you have two developers on East Coast, three on the West
and yourself sitting in lets say Michigan trying to find who and where in
depths of your project
changed such value. With Java/C++ strings such sitations are just
impossible.
Again, D char[] is a character array and not a string (value).

Yes you can always .dup your 'strings'.
The question: is this a real solution?

>
> I reckon the only problem at present is that library developers will choose different UTF types and we'll need to transcode string data to/from all our library calls. The only solution I can think of is to compile all libraries 6 times, a debug and release for each char type. This allows the application programmer to decide on the string type to use internally and link the correct libraries. Note, I'm only talking about selecting the 'internal' char type, not the char type of the various data sources your application might read/write.
>
> Regan

On Wed, 22 Jun 2005 11:56:23 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>>> I guess that first D needs features that C++ can do.
>>> Beg my pardon but this again about: opAssign & co.
>>
>> I think there is some merit in opAssign for structs. Or, if ctors were
>> added to structs having = call the ctor.
>>
>> IIRC one of the design patterns/goals for D was that opAssign was not
>> required for classes, instead copy constructors should be used. The idea
>> being the explicit/obvious nature of constructors was preferrable to
>> assignment overloading.
>
> For classes, yes, as variable holding class instance is always reference.

We agree about classes.

> For structs situation is different. As a rule struct variable is holding
> value itself.

It is a value type.

> Naturally class builds a safe envelope around its data.
> Class a,b; a = b; will not destroy data of a;

> Struct does not have such feature. a = b there will overwrite 'a' value
> silently.

That is the very point of using a struct. A struct is a value type, when you assign something to a value, it assigns that value.

> And D is not helping you here to catch this moment.

Catch what? The fact that you've chosen to assign a value? You may as well ask it to catch the assignment of an 'int', eg "int i = 5;"

I cannot see the need to prevent assignments, at present no assignment is allowed except that of the exact same type (talking about structs) eg.

struct A {}
struct B {}

A a;
B b;
B c;

a=b; //error
b=c; //ok


To prevent assignment to a particular variable you would use const (or whatever we decide the keyword is):

const B b;
B c;

b=c; //error (one would expect)


The only point of opAssign (that I can see) for structs would be to facilitate assignment of other types, eg.

struct A {
  char[] value;
  int opAssign(int rhs) {
    value = std.string.toString(rhs);
  }
}

A a;
a = 5;

>> I still believe that the first step is to create/enforce the readonly
>> nature of 'in' arguments. Either compile time, runtime or both. i.e. It
>> can be a runtime DBC feature i.e. disabled by -release mode.
>
> I think it will be enough to be able to construct 'const' value types.

I think we need both. The reason we need both:

const char[] foo = "regan was here";
mutilate(foo);  //no error, foo is const, mutilate takes an 'in' (so "will not" modify foo).
void mutilate(in char[] victum) {
	victum[0] = 'a';  //error: 'in' parameter not mutable
}

'in' is a contract saying "I will only read this parameter". That contract needs to be enforced.

> Let's say D will alow us to use keyword const as part of the type name:
> so I can create:
>
> struct String
> {
>    private char[] data;
>    char opIndex(int i) { ... }
>    char opIndexAssign(int i, char c)   {  ...  }
> }
>
> struct const String
> {
>    private char[] data;
>    this( char[] d ) { data = d; }
>    char opIndex(int i) { ... }
> }
>
> And this is a different implementation of 'const' in C/C++.
> Remeber that String.data is in fact reference to some memory location.
> Having such 'const String' type you can safely return or pass references to string data.
>
> struct Url
> {
>     private char[] urlSource;
>     const String domain() {  return  const String( urlSource[x..y] ); }
>     const String protocol() {  return  const String( urlSource[x..y] ); }
> }
>
> The idea is simple: instead of only arryas (like char[] )
> D must have another type - const arrays (  like const char[]  )
> which are the same types but immutable, e.g.
> const char[] type will have not opIndexAssign op available.

As a string class is not required in D (still under debate), lets remove it from the example (we'll come back to it later):

struct Url
{
	private char[] urlSource;
	char[] domain()   { return urlSource[a..b]; }
	char[] protocol() { return urlSource[c..d]; }
}

The basic problem is being able to create/return/pass a reference to immutable data. In this case returning a slice of mutable data as immutable data.

Ideally the addition of 'const' or 'readonly' or whatever we decide is a good keyword would be all that is required, eg.

struct Url
{
	private char[] urlSource;
	const char[] domain()   { return urlSource[a..b]; }
	const char[] protocol() { return urlSource[c..d]; }
}

The rules being:

1. immutable(const) data cannot ever be mutable.
2. mutable data is implicitly immutable data when passed as such.

I think to achieve this all the char[] needs is a readonly flag, which once set to true cannot become false again.

This can either be implemented at compile time (compiler uses flag to check for errors), or runtime (runtime checks against flag stored in char[] struct), or both.

This ties in with the 'in' parameter checking, the same flag is used for compile time checking. At runtime it could be done without a flag using an implicit 'out' DBC check against the original (that might not catch a change and change back case however).


Of course the next problem is how to handle immutability on custom types (we're back to the string class or other similar types).

Using 2 example custom types:

struct Bob {}
class Fred {}

we need to be able to indicate they are immutable, ideally in exactly the same way as char[] above, eg.

Fred p;
static this() { p = new Fred(); }
const Fred fooBar() { return p; }

this required that the compiler store the same readonly flag within the class and perform compile/runtime checks on it. The same goes for the struct Bob.

>> , struct
>>> ctor/dtor.
>>
>> IIRC a struct dtor isn't going to be possible without major changes to D.
>> I can't recall why, or even who said it. Something to do with how/when
>> they're called, the nature of structs i.e. a stack type, and the goal of
>> keeping the compiler as simple as possible.
>
> I hope this is the reason (and not because of some religion involved).

I doubt it's a religeon, though I understand your meaning here. Everyone whether they realise it or not will by habit defend preconcieved notions/ideas, the trick is realising that is what you're doing and re-evaluate. Of course, you may come to the same conclusion.

> But compiler can handle now 'auto' for stack class variables.

structs are not classes however, they have no vtable, I believe that is an important part of the problem.

> I don't think that it will be more difficult to implement calling of struct dtors in the same manner.
> The only complex thing is struct static initialization/destruction.
> Also intitialization of array of structs could be an implementation problem.

We'll have to get Walters official word on this again (or find it in the archives).

>> On the other hand a ctor is possible, and I think it'd be useful.
>>
>>> and remove 'auto' as too controversial.
>>
>> What's controversial about it?
>
> auto A a = new A();
> ....
> a = new A() ; // another A instance in the same var. What will happen
>                      // with the first one? etc.

And the controversy is? i.e. what 2 or more answers do people fail to agree on?

I believe this should be an error, after all it's illegal to assign something to an auto variable, which is essentially what you're doing. Breaking the statement into parts we see:

"new A()" construct an A using this()
"a =" assign rhs to reference a;

>>> Serious development teams where 'const' is a matter of culture and
>>> tool for collaborative work will definitely stay with C++.
>>
>> I don't think the fact that it's 'culture' is particularly important. A
>> truly good programming language will form culture, it wont follow it.
>
> Probably D will form a culture. If it would be enough members in
> this society. The question is about a critical mass of number of "culture
> carriers". And we are speaking about motivations to join the society, right?

Yep. D already has plenty of these, see my list below.

> 'const' is the one.

I agree it's important, but, for me D the whole package was 'the one' eg.

- array slicing
- GC
- low level systems languge
- great syntax

I dont really make full use of unittesting, dbc, etc but these are also important to the overall package.

> Non-deterministic GC (the same as in D, btw) is available for C/C++ so
> it is not a big motivation.

By itself, no, but added to all the other (sometimes little) things.. it's the overall package that matters.

IMO D's overall package is great, and getting better by the day. Sure, there are a number of things I want changed, there are a number you want changed, that's normal, name me a programming language that is perfect, you can't or you wouldn't be here. :)

> What else? The only thing is 1) better syntax
> and 2) set of ready to use builtin types. The latter is definitely not full without 'const'.

Perhaps, they're still 'ready to use' they're just missing certain protection attributes like readonly.

> The first is not full without opAssign and ctors/dtors.

The syntax is better (than other languages) with or without this feature.

>>> In any case phobos shall include string class/object/whatever allowing
>>> to use it as std::string or java.lang.String.
>>
>> I've yet to hear any reason that convinces me a string class is required.
>
> For your personally and for small projects probably not.

I'm not talking about experience, I'm talking about argument, no-one has given an argument 'for' a string class that makes sense.

> But consider development of components/libraries of a big scale.
>
> char[] s = myobject.name();
> int[ char[] ] map;
> map[ s ] = 1;
> ....
> // somewhere in myobject far far away somebody
> // changed name data to let's say "two".
> // and after that:
>
> assert (map[ "one" ] == 1) ;
>
> will throw an error.

This is solved by the 'const' ideas I have explained above.

> Simple assignment of one character is making the whole system fragile.

Until we get 'const' as I have described above.

> Consider that you have two developers on East Coast, three on the West
> and yourself sitting in lets say Michigan trying to find who and where in
> depths of your project
> changed such value. With Java/C++ strings such sitations are just
> impossible.

And will be impossible in D when we get 'const'

> Again, D char[] is a character array and not a string (value).

Technically yes, practically it makes no difference (once we have const).

> Yes you can always .dup your 'strings'.
> The question: is this a real solution?

It's part of the solution. For high-performance mutable strings it's what you do, for high-performance immutable strings you use 'const' (when Walter adds it as I have described).

Baiscally, I'm saying, we dont need a string class, we need const. I agree there is a problem. I just prefer my solution to yours, both probably solve the problem, mine seems neater (IMO) and more D like (IMO).

>> I reckon the only problem at present is that library developers will
>> choose different UTF types and we'll need to transcode string data to/from
>> all our library calls. The only solution I can think of is to compile all
>> libraries 6 times, a debug and release for each char type. This allows the
>> application programmer to decide on the string type to use internally and
>> link the correct libraries. Note, I'm only talking about selecting the
>> 'internal' char type, not the char type of the various data sources your
>> application might read/write.

The above is still an issue. I've not heard a better soln than mine above, anyone?

Regan

On Wed, 22 Jun 2005 13:18:00 +0000 (UTC), Mike Capp <mike.capp@gmail.com> wrote:
> + Much tighter control over memory usage than GC. (Smaller working set, much
> less risk of unacceptable pauses.) A bit tedious when you don't need it, but
> irreplaceable when you do, and manageable given RAII. This point alone creates a
> sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content.

Regan

On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:

[snip]
> I'm not talking about experience, I'm talking about argument, no-one has given an argument 'for' a string class that makes sense.

One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing...

  string a;
  char[] b;
  wchar[] c;
  dchar[] d;

  a = b ~ c ~ d;

Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing.

-- 
Derek Parnell
Melbourne, Australia
23/06/2005 8:27:02 AM

On Thu, 23 Jun 2005 08:35:52 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:
>
> [snip]
>> I'm not talking about experience, I'm talking about argument, no-one has
>> given an argument 'for' a string class that makes sense.
>
> One thing that is still a bit of a problem is having a 'string' type that
> is encoding agnostic. It would be very handy to be able to this sort of
> thing...
>
>   string a;
>   char[] b;
>   wchar[] c;
>   dchar[] d;
>
>   a = b ~ c ~ d;
>
> Currently we need to explicitly invoke the UTF conversion functions to do
> this sort of thing.

True, it is a pain.

I once suggested that transcoding (converting from one UTF type to another) could be done implicity. It met with some like and some dislike. The dislike stemmed from the fact that it can be very inefficient where you have several types involved in one statement. Especially as it then happens implicitly and is not obvious.

I have come to agree, it's a bad idea, by itself...

The solution IMO is building all libraries 6 times (one for each char type, release and debug)

If we build all libraries 6 times and link the correct 'internal' char type it means no internal transcoding is done i.e. between libraries, to/from the system (depending on what type you choose). To achieve this everyone would use an alias 'string' where they wanted an encoding agnostic string. 'string' would alias the chosen 'internal' char type.

This means that things like you show above would be limited to input/output of different types. (which would most likely, initially, be the non-utf charsets anyway). There is no way to avoid transcoding these, so we call the transcoding functions. The reason I don't think that is a problem is that:

1. transcoding should be obvious and explicit (that's my opinion of course).
2. it's rare (generally speaking).

More on #2. You'd generally choose an internal char type to match your most common input/output data. Most applications wouldn't need to transcode input or output, i.e. they can use ASCII right thru.

Of course, we could still make transcoding implicit. But IMO only once we remove the bulk of the potential pitfalls resulting in masses of internal transcoding between libraries etc.

Regan