"Anders F Björklund" <afb@algonet.se> wrote in message news:daunef$245r$1@digitaldaemon.com...
> I think there was a major difference between C++ and D almost at once, he wants to use the standard library while Walter wants to build it in:
>
> See "Rationale for Builtins" http://www.digitalmars.com/d/builtin.html

Yes, although many C++ programmers think this is a wider gulf between C++ and D than it actually is. C++ has core strings and core arrays, for example, they just work so poorly one is motiviated to do a library replacement. Unfortunately, those replacements don't work well either.

"Walter" <newshound@digitalmars.com> wrote in message news:db114l$16o3$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dauv5e$2b1f$1@digitaldaemon.com...
>> Any memory safety has its own price. Pretty frequently
>> (at least in my cases) this mandatory price is not acceptable.
>> That's it.
>
> True. D doesn't eliminate the potential for memory corruption. What it
> does
> try to do, however, is reduce the probability of them by 1) providing less
> error-prone ways to get the functionality, such as using out and inout
> parameters rather than pointers and 2) adding runtime checks such as array
> bounds overflow checking and contract programming.
>

True.

Except one: I just don't understand - how contract programming
helps to increase memory safety.
Currently D's DbC features allows you only check for NULL.

Did I miss something in principle?

"const", as a part of DbC, will definitely help more here. This is true.

"Walter" <newshound@digitalmars.com> wrote in message news:db114m$16o3$2@digitaldaemon.com...
>
> "Anders F Björklund" <afb@algonet.se> wrote in message news:daunef$245r$1@digitaldaemon.com...
>> I think there was a major difference between C++ and D almost at once, he wants to use the standard library while Walter wants to build it in:
>>
>> See "Rationale for Builtins" http://www.digitalmars.com/d/builtin.html
>
> Yes, although many C++ programmers think this is a wider gulf between C++ and D than it actually is. C++ has core strings and core arrays, for example, they just work so poorly one is motiviated to do a library replacement. Unfortunately, those replacements don't work well either.
>

Walter, sorry for beating this horse again but D does not yet have strings
either.
Very convenient character arrays and slices - yes. But strings (as value
type) -
not yet. String  is an immutable value and has no analogues in D.
D's char[] is just a StringBuffer/StringBuilder. And this is main concern
for Java/C#
enterprise developers. They just get used to such String robustness.
BTW: modern java.lang.String implementation is capable to represent string
slices too.

Andrew Fedoniouk wrote:
>...
> Walter, sorry for beating this horse again but D does not yet have strings either.
> Very convenient character arrays and slices - yes. But strings (as value type) -
> not yet. String  is an immutable value and has no analogues in D.
> D's char[] is just a StringBuffer/StringBuilder. And this is main concern for Java/C#
> enterprise developers. They just get used to such String robustness.
> BTW: modern java.lang.String implementation is capable to represent string slices too.

Perhaps allowing Java terminology to define things isn't exactly fair.  Many languages have had mutable strings (often, admittedly, by accident).  Being mutable DOESN'T mean it isn't a string, it means it's not a Java String class, which nobody ever claimed it was.

OTOH, a char[] isn't really a full fledged string, even with slicing.  It's quite close, but not quite there.  To get to String status you need to do something like importing std.string.  But char[]'s really build in most features that need to be built in.  Basically what should be added is some special magic so that if you import std.string, the std.string methods are all available as methods of variables/literals of type char[], so you would be able to do things like:
j = "This is a test".rfind("is");

Even that isn't quite perfect.  It would be nice to be able to do things like:
s = "This is a test";
s.removechars("/is/");  //   N.B.:  Note the /'s this should mean
                        //       "interpret this as a pattern"
Notice that the syntax has changed a bit from the current usage as this is now a method invocation rather than a function call. Also notice that this function would need to realize that it's arguments couldn't be const's. (A standard requirement, but another change from the current approach.)

This might even be a reasonable approach, given that already char[]'s need to be converted to Stringz if one wants to use them in C.

OTTH (or is this the fourth hand), perhaps this extension is better handled with a library.  I don't even think it would be a hard one to write...the sole problem is method invocation off of string literals, to which I see no solution without direct intervention in the compiler.

Dejan Lekic wrote:
> No, I do not defend C++ - If I was so deeply in love in it I would not use
> other languages, notably Modula-3, D or C# (i've excluded some scripting
> languages from the list)... I just dislike common anti-c++ articles, even
> if they make sense, because we, developers, use what we are familiar with,
> and what "does the job" (TM). :)
> 
OTOH, while there are occasions where one wants to disable or replace the garbage collection, they are (or should be) the exceptional cases.  As it is most C/C++ programmers have no access to ANY garbage collection.  You may say "Well, if they just...", but the answer has to be "They don't".  I have heard it seriously asserted that the largest improvement in computer languages over the last 20 years was the common inclusion of garbage collectors.  I don't know on what basis this assertion was made, but the person making it was widely respected and definitely believed it.  Apparently dangling pointers, invalid array references, etc. were sufficiently common that just getting rid of them was a bigger improvement than either Object oriented programming or even structured programming (but perhaps that was more than 20 years ago?).  Of course, it may also have had a bit of hyperbole in it, but don't write off the importance of Garbage Collection just because it's occasionally imperfect.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:db3s4k$tn9$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>>...
>> Walter, sorry for beating this horse again but D does not yet have
>> strings either.
>> Very convenient character arrays and slices - yes. But strings (as value
>> type) -
>> not yet. String  is an immutable value and has no analogues in D.
>> D's char[] is just a StringBuffer/StringBuilder. And this is main concern
>> for Java/C#
>> enterprise developers. They just get used to such String robustness.
>> BTW: modern java.lang.String implementation is capable to represent
>> string slices too.
>
> Perhaps allowing Java terminology to define things isn't exactly fair. Many languages have had mutable strings (often, admittedly, by accident). Being mutable DOESN'T mean it isn't a string, it means it's not a Java String class, which nobody ever claimed it was.

String is an immutable value.

Consider this:

char [] key = "one";
int [char[] ] map;
map[ key ] = 1;
key[0] = 'a';

This will ruin your map, isn't it?


> Perhaps allowing Java terminology to define things isn't exactly fair.

I am using String not only as Java string but as entity describing "immutable string value":

In C you have char* and const char*
In C++ you have std::string and const std::string
In Java you have String and StringBuffer
In C# - String and StringBuilder
In Delphi you also able to use const Strings (limitied cases)

>
> OTOH, a char[] isn't really a full fledged string, even with slicing.
> It's quite close, but not quite there.  To get to String status you need
> to do something like importing std.string. But char[]'s really build in
> most features that need to be built in.  Basically what should be added is
> some special magic so that if you import std.string, the std.string
> methods are all available as methods of variables/literals of type char[],
> so you would be able to do things like:
> j = "This is a test".rfind("is");

Try to write it:
"This is a test".rfind("is");

It should run flawlessly. By some accident D allows to do such trick with array parameters.


>
> Even that isn't quite perfect.  It would be nice to be able to do things
> like:
> s = "This is a test";
> s.removechars("/is/");  //   N.B.:  Note the /'s this should mean
>                         //       "interpret this as a pattern"
> Notice that the syntax has changed a bit from the current usage as this is
> now a method invocation rather than a function call.

As I mentioned if  removechars is declared as
void removechars(char[],char[]) then you can call it as

s.removechars("/is/");

I wouldn't rely on this behavior though as it is not specified - "D's hidden treasure"

> Also notice that this function would need to realize that it's arguments couldn't be const's. (A standard requirement, but another change from the current approach.)
>
> This might even be a reasonable approach, given that already char[]'s need to be converted to Stringz if one wants to use them in C.
>
> OTTH (or is this the fourth hand), perhaps this extension is better handled with a library.  I don't even think it would be a hard one to write...the sole problem is method invocation off of string literals, to which I see no solution without direct intervention in the compiler.

BTW: Compiler should assign char[]# ( or const char[] )  type to string
literals
as they are immutable by nature.

In article <db3slk$u4n$1@digitaldaemon.com>, Charles Hixson says...

>OTOH, while there are occasions where one wants to disable or replace the garbage collection, they are (or should be) the exceptional cases.  As it is most C/C++ programmers have no access to ANY garbage collection.  You may say "Well, if they

I posted a GC question today is is not fully answered but enough to say:

Every C/C++ programmer have as much GC at there hand as a D programmer.

They just need to link in Boehms GC , then you need just a few lines of code to replace the standart new/delete/delete[] and a one liner for each class that should have a finalizer call (which is not so much typing overhead).

In article <db3slk$u4n$1@digitaldaemon.com>, Charles Hixson says...
>
>I have heard it seriously asserted that the largest improvement in computer languages over the last 20 years was the common inclusion of garbage collectors. [...] Apparently dangling pointers, invalid array references, etc. were sufficiently common that just getting rid of them was a bigger improvement than either Object oriented programming or even structured programming (but perhaps that was more than 20 years ago?).

SP is *way* more than 20 years old. OO is coming up on 40 (since Simula inroduced it in '67). So I'm not sure what improvements the speaker was comparing GC to. STL-style generics, maybe?

>don't write off the importance of Garbage Collection just because it's occasionally imperfect.

Oh, I don't. There's no question at all about programmer productivity in GC languages, and I'm slowly coming round to accept that for long-lived objects the benefits might outweight the nasty unpredictability drawbacks.

I'm still convinced that GC is massive overkill for local-scoped class variables and (to a lesser extent) simple value-like class members. C++'s default stack allocation is a far better story than D on this front.

Andrew Fedoniouk wrote:

> I am using String not only as Java string but as entity describing
> "immutable string value":
> 
> In C you have char* and const char*
> In C++ you have std::string and const std::string
> In Java you have String and StringBuffer
> In C# - String and StringBuilder
> In Delphi you also able to use const Strings (limitied cases)

And in D you have char[] and char[]
Some people find that confusing :-)

Seriously, D does have two types of strings too - it is "just"
that the compiler doesn't enforce any difference between them,
so one just has the Gentlemen's Agreement to honor the C-o-w*.

(*See http://en.wikipedia.org/wiki/Copy-on-write, or Phobos doc)

And just like you (and several others) I think it would be very
nice if there was some addition to the language to make it able
to separate between them, and enforce the (default) immutability.

But it still needs some nice new D syntax...
Maybe: "char [inout]", or "mutable char[]" ?

--anders

PS.
Inspired by NSString/NSMutableString and NSArray/NSMutableArray,
and their other similar friends, from NeXTSTEP and Objective-C :
http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Classes/NSString.html

But "mutable" does have the issues with the local variables raised
by Walter, basically them being something of a pain to add there ?
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096

Still seems like the lesser evil to me, but that's up to Walter...

Anders F Björklund wrote:

> Seriously, D does have two types of strings too - it is "just"
> that the compiler doesn't enforce any difference between them,
> so one just has the Gentlemen's Agreement to honor the C-o-w*.
> 
> (*See http://en.wikipedia.org/wiki/Copy-on-write, or Phobos doc)
> 

Actually, the Wikipedia entry on COW disagrees with D's take on COW. From Wikipedia "This fiction can be maintained until a caller tries to modify its "copy" of the resource, at which point a true private copy is created to prevent the changes becoming visible to everyone else. All of this happens transparently to the callers."

The key thing being "all this happens transparently to callers", in D's take on COW the callers must explicitly manage their own COW.
Now, as a thought experiment imagine that COW in D was transparent. Imagine that when you returned an array in D it acted just as it does now, except that when you wrote to it, the D compiler/runtime automatically duped it and you wrote to your own array.  Would this make a difference to how we programed?  Certainly it would make the idea that we needed immutable strings go away (all arrays are effectively immutable).  Now of course we would need some mechanism for actually returning a modifiable array.  Thoughts?

Brad