www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Java String vs wchar[] Was: Re: inner classes

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Are you going to have string constants castable to String, BTW?
 Or any other class? That would be nice...


 Walter asks:

 What advantage does java.lang.String have? Why does string need to be a
 class?

string does not need to be a class. It is nice to be able to declare methods for it though. At least for the sake of Java-2-D tool or so. java.lang.String class has a) methods b) String owns buffer - it controls buffer. In D is possible: int[char[]] map; char[] s = "something"; map[s] = 1; s[0] = '?'; // I have no idea what result will be. sure not good. And you can bump into such problem quite easily in D. I personally did many times. And too hard to find source sometimes. In Java such collision is not possible in principle: String is final and immutable. Java strings more (I would say - too) greedy but more robust. In D I tried to create something like String but declarations like str = new String("real string"); or with structs str = String("mmmm"); are just boring and aestheticlly disastrous. For Java guys such D strings will be just a source of permanent errors. To prevent collisions Mango library (nice one!) uses two versions of classes e.g. Dictionary/MutableDictionary - a bit overkill, imho, but works. Ideally in D it should be possible to reproduce at least std::string. (I am yet silent about copy-on-write version) I tried four times - did not find yet reliable solution. I am pretty sure - it is impossible to implement the same abstarction in D and with the same overhead. struct was good candiadate for such wrapper but no copying ctor. class needs allocation. Only dup so far. But solution with dup is even worse than in Java. See: class Url { char[] _hostname; ... char[] hostname() { return _hostname.dup; } // Doh! } if( url.hostname == "terrainformatica.com" ) // 32 bytes less in memory, just to compare it! .... Ideal from many points of view would be a solution with const class Url { char[] _hostname; const char[] hostname() { return _hostname; } // Yep! this exactly what we need. } I think that it would be just enough to be able to declare as const variables of simple types - array and pointers. Generally speaking const does not imply better assembler code. But const helps to build optimal and fast systems where GC spends 1% of time and not 20%. Andrew.
May 30 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 30 May 2005 22:50:29 -0700, Andrew Fedoniouk wrote:


[snip]
 
 In D is possible:
 int[char[]] map;
 char[] s = "something";
 map[s] = 1;
 s[0] = '?'; // I have no idea what result will be. sure not good.
 
 And you can bump into such problem quite easily in D. I personally
 did many times. And too hard to find source sometimes.

I'm sure you already know this, but for the benefit of others, you can avoid this trap by coding ... int[char[]] map; char[] s = "something"; map[s.dup] = 1; // NB: .dup call. s[0] = '?'; // Does not mess up the index to map. -- Derek Melbourne, Australia 31/05/2005 4:05:26 PM
May 30 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1p5feg14mh412.1x6qgemuugouf$.dlg 40tude.net...
 On Mon, 30 May 2005 22:50:29 -0700, Andrew Fedoniouk wrote:


 [snip]

 In D is possible:
 int[char[]] map;
 char[] s = "something";
 map[s] = 1;
 s[0] = '?'; // I have no idea what result will be. sure not good.

 And you can bump into such problem quite easily in D. I personally
 did many times. And too hard to find source sometimes.

I'm sure you already know this, but for the benefit of others, you can avoid this trap by coding ... int[char[]] map; char[] s = "something"; map[s.dup] = 1; // NB: .dup call. s[0] = '?'; // Does not mess up the index to map.

Thanks, Derek. But shall I put you recomendation into comments for each function returning string? Don't store, don't modify, etc? If you put my string into your map always do its dup, etc. This is not that I am considering as technically correct solution. Andrew.
May 31 2005
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7gtvf$qs0$1 digitaldaemon.com...
 java.lang.String class has a) methods b) String owns buffer - it controls
 buffer.

 In D is possible:
 int[char[]] map;
 char[] s = "something";
 map[s] = 1;
 s[0] = '?'; // I have no idea what result will be. sure not good.

 And you can bump into such problem quite easily in D. I personally
 did many times. And too hard to find source sometimes.

 In Java such collision is not possible in principle: String is final and
 immutable.

A number of languages use the immutable string idiom, and its corollary "always implicitly copy the string when writing to it". They all share another common characteristic - they're slow, and they're slow in a manner that is *not fixable*. And they're not just slower by a factor, many algorithms run *exponentially* slower because of the copying. D must be fast, and the only way to be fast with strings (and arrays) is to not have the language implicitly copy them, but to allow the programmer the flexibility to copy or not copy. To know when to copy, use the Copy On Write principle (COW). That is, if you're not *sure* you've got the only copy of a string, .dup it before modifying it. So why isn't that just as bad as the languages that implicitly copy on write? The answer is that often, you know that you are the sole owner, such as: char[] s = new char[10]; for (i = 0; i < 10; i++) s[i] = 'c'; Those other languages are doomed to make 10 copies of s. The D programmer needs to make 0 copies. As to your example above, when you pass a reference to a string to an associative array, then you aren't the sole owner of that string anymore. Don't change it. .dup it.
May 31 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d7h4rf$1345$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gtvf$qs0$1 digitaldaemon.com...
 java.lang.String class has a) methods b) String owns buffer - it controls
 buffer.

 In D is possible:
 int[char[]] map;
 char[] s = "something";
 map[s] = 1;
 s[0] = '?'; // I have no idea what result will be. sure not good.

 And you can bump into such problem quite easily in D. I personally
 did many times. And too hard to find source sometimes.

 In Java such collision is not possible in principle: String is final and
 immutable.

A number of languages use the immutable string idiom, and its corollary "always implicitly copy the string when writing to it". They all share another common characteristic - they're slow, and they're slow in a manner that is *not fixable*. And they're not just slower by a factor, many algorithms run *exponentially* slower because of the copying. D must be fast, and the only way to be fast with strings (and arrays) is to not have the language implicitly copy them, but to allow the programmer the flexibility to copy or not copy. To know when to copy, use the Copy On Write principle (COW). That is, if you're not *sure* you've got the only copy of a string, .dup it before modifying it. So why isn't that just as bad as the languages that implicitly copy on write? The answer is that often, you know that you are the sole owner, such as: char[] s = new char[10]; for (i = 0; i < 10; i++) s[i] = 'c'; Those other languages are doomed to make 10 copies of s. The D programmer needs to make 0 copies. As to your example above, when you pass a reference to a string to an associative array, then you aren't the sole owner of that string anymore. Don't change it. .dup it.

Gotcha. And what will be your advice then for: class Url { char[] _hostname; char[] hostname() { return _hostname; } } _hostname should not be changeable nor intentionally nor accidentally. hostname access pattern is primarily read. But it could possibly be passed in some third party functions. I am serious. I really want to know how to design it better. I've made an ugly struct string { wchar[] chars; bool mutable; } But this not working in 15% of cases. I am remebering old good days of C programming with these char[]s. Damned fast but not maintainable. In C++ I have my own nice tool::string with reliable copy-on-write..... sigh. Andrew.
May 31 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:

 And what will be your advice then for:
 
 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }
 
 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.
 
 I am serious. I really want to know how to design it better.

Magic Eight Ball says: ___ / \ / \ / ASK \ / AGAIN \ / LATER \ \___________/ My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-) For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
 I am remebering old good days of C programming with these char[]s.
 Damned fast but not maintainable.

That's where we are at now, I suppose. I've already run into some things regarding string literals. And that was even before any potential class library user... Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along. --anders
May 31 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:d7ha36$18df$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 And what will be your advice then for:

 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }

 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.

 I am serious. I really want to know how to design it better.

Magic Eight Ball says: ___ / \ / \ / ASK \ / AGAIN \ / LATER \ \___________/ My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-) For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
 I am remebering old good days of C programming with these char[]s.
 Damned fast but not maintainable.

That's where we are at now, I suppose. I've already run into some things regarding string literals. And that was even before any potential class library user... Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along.

Yep, Anders, seems like we are on the same track with you. The thing is: I really don't know of a good style of library/component design in D. If I am writing all code in one EXE by myself - fine - I am genetleman with myself. Well... even with myself... 'Today me' and 'yesterday me' frequently different persons. But! If I am desisginig library of common use.... I can imagine: documentation starts from: "For gentlemen only...."
May 31 2005
parent reply "Kris" <fu bar.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote ...
 "Anders F Björklund" <afb algonet.se> wrote in message
 news:d7ha36$18df$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 And what will be your advice then for:

 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }

 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.

 I am serious. I really want to know how to design it better.

Magic Eight Ball says: ___ / \ / \ / ASK \ / AGAIN \ / LATER \ \___________/ My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-) For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
 I am remebering old good days of C programming with these char[]s.
 Damned fast but not maintainable.

That's where we are at now, I suppose. I've already run into some things regarding string literals. And that was even before any potential class library user... Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along.

Yep, Anders, seems like we are on the same track with you.

Aye. There's a fair number of people who share this concern, and we all seem to be asking for the same thing. I think/hope it's a matter of time rather than legitimacy.
 The thing is: I really don't know of a good style of
 library/component design in D.

FWIW: I've been forced down the path of the Gentleman's agreement, with the expectation that 'readonly' will materialize in some form. It is possible to minimise the occurence of such things, but it doesn't always provide the most lightweight implementation (as you noted elsewhere).
 If I am writing all code in one EXE by myself -
 fine - I am genetleman with myself. Well... even with
 myself... 'Today me' and 'yesterday me' frequently
 different persons.

 But! If I am desisginig library of common use....

 I can imagine: documentation starts from:

 "For gentlemen only...."

Good one! Perhaps we should come up with a GLA: "Gentleman's License Agreement" :-)
May 31 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d7ic55$2df4$1 digitaldaemon.com>, Kris says...
FWIW: I've been forced down the path of the Gentleman's agreement, with the
expectation that 'readonly' will materialize in some form. It is possible to
minimise the occurence of such things, but it doesn't always provide the
most lightweight implementation (as you noted elsewhere).

FWIW, logical const behavior can *almost* be modeled decently using a sort of honor system as well: # Object # { # bit mutable = true; # ... # } # # class C # { # int read() # { # return 0; # } # # void write( int val ) # in # { # assert( mutable ); # } # body # { # # } # } # # void read( C val ) # in # { # val.mutable = false; # } # out # { # // this can 'restore' to the wrong state # val.mutable = true; # } # body # { # # } # # void write( C val ) # { # # } The obvious problems with the above are that (1) it requires a lot of cooperation and (2) the read function has no easy way of storing whether C was mutable *before* the function was called, so it may 'restore' the wrong state (though this issue could be solved with thread local storage, as the expense of added complexity). Sean
May 31 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Sean Kelly wrote:
 In article <d7ic55$2df4$1 digitaldaemon.com>, Kris says...
 
FWIW: I've been forced down the path of the Gentleman's agreement, with the
expectation that 'readonly' will materialize in some form. It is possible to
minimise the occurence of such things, but it doesn't always provide the
most lightweight implementation (as you noted elsewhere).

FWIW, logical const behavior can *almost* be modeled decently using a sort of honor system as well: # Object # { # bit mutable = true; # ... # } # # class C # { # int read() # { # return 0; # } # # void write( int val ) # in # { # assert( mutable ); # } # body # { # # } # } # # void read( C val ) # in # { # val.mutable = false; # } # out # { # // this can 'restore' to the wrong state # val.mutable = true; # } # body # { # # } # # void write( C val ) # { # # } The obvious problems with the above are that (1) it requires a lot of cooperation and (2) the read function has no easy way of storing whether C was mutable *before* the function was called, so it may 'restore' the wrong state (though this issue could be solved with thread local storage, as the expense of added complexity). Sean

arrays? With classes, is it possible for the compiler to generate accessors for all members automatically? That would ease implementation details. Perhaps a template could be created so that class code could look like class C { bit mutable; mixin constcapable!(int) someInt; } Brad
May 31 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d7ifkp$2goj$1 digitaldaemon.com...
 Sean Kelly wrote:
 In article <d7ic55$2df4$1 digitaldaemon.com>, Kris says...

FWIW: I've been forced down the path of the Gentleman's agreement, with 
the
expectation that 'readonly' will materialize in some form. It is possible 
to
minimise the occurence of such things, but it doesn't always provide the
most lightweight implementation (as you noted elsewhere).

FWIW, logical const behavior can *almost* be modeled decently using a sort of honor system as well: # Object # { # bit mutable = true; # ... # } # # class C # { # int read() # { # return 0; # } # # void write( int val ) # in # { # assert( mutable ); # } # body # { # # } # } # # void read( C val ) # in # { # val.mutable = false; # } # out # { # // this can 'restore' to the wrong state # val.mutable = true; # } # body # { # # } # # void write( C val ) # { # # } The obvious problems with the above are that (1) it requires a lot of cooperation and (2) the read function has no easy way of storing whether C was mutable *before* the function was called, so it may 'restore' the wrong state (though this issue could be solved with thread local storage, as the expense of added complexity). Sean

arrays? With classes, is it possible for the compiler to generate accessors for all members automatically? That would ease implementation details. Perhaps a template could be created so that class code could look like class C { bit mutable; mixin constcapable!(int) someInt; } Brad

The main problem that for basic types there are no solution in principle. At least I did not find proper idiom. I've ended up with a "solution" to patch std.internals and to add readonly flag to arrays. But this is not working for pointers. The only feasible solution is const - checks at compile time and not in runtime. Andrew.
May 31 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <d7ifkp$2goj$1 digitaldaemon.com>, Brad Beveridge says...
Do you have any ideas on how this could work with basic data types and 
arrays?

I don't know that this is worth doing for POD types because they're copied when passed as 'in' parameters anyway. But I suppose strings could be an issue. One possibility would be to fingerprint the memory using a checksum and verify that fingerprint in the out clause. Perhaps someone has a better suggestion?
With classes, is it possible for the compiler to generate 
accessors for all members automatically?

Certainly. If DBC became a popular means for verifying const correctness I'd suggest that the compiler offer a means to do this. I don't think it would be too terribly complicated, but I haven't given it much thought.
That would ease implementation 
details.  Perhaps a template could be created so that class code could 
look like
class C
{
	bit mutable;
	mixin constcapable!(int) someInt;
}

Definately a possibility. My only concern with the DBC method is that it requires the library writer to build stuff in to support it to keep the code clean. The client could do the switching instead: c.mutable = false; func( c, d ); c.mutable = true; but this is obviously pretty clunky. It might be possible to do this with auto classes: # auto class SetConst(T) # { # this( T obj ) # { # m_mutable = obj.mutable; # m_obj = obj; # m_obj.mutable = false; # printf( "ctor\n" ); # } # # ~this() # { # m_obj.mutable = m_mutable; # printf( "dtor\n" ); # } # # T opCast() { return m_obj; } # # private: # bit m_mutable; # T m_obj; # } # # void func( C val ) # { # # } # # void main() # { # C c = new C(); # printf( "pre\n" ); # func( cast(C)(new SetConst!(C)( c )) ); # printf( "post\n" ); # } but this is very clunky and doesn't even offer the potential to streamline it because of auto lifetime rules, though it's worth noting that the above example prints this: pre ctor post dtor and wrapping the function call in its own scope doesn't help: { func( cast(C)(new SetConst!(C)( c )) ); } it's little things like this that has me cursing the restriction that structs can't have ctors. Not only does the above code require a completely pointless memory allocation, but the lifetime of the class isn't even what it should be (though I'd consider this latter issue to be a bug). Sean
May 31 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Kris" <fu bar.com> wrote in message news:d7ic55$2df4$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote ...
 "Anders F Björklund" <afb algonet.se> wrote in message
 news:d7ha36$18df$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 And what will be your advice then for:

 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }

 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.

 I am serious. I really want to know how to design it better.

Magic Eight Ball says: ___ / \ / \ / ASK \ / AGAIN \ / LATER \ \___________/ My own prediction is that we argue about it for a few months more, and then Walter caves in and adds a "readonly" keyword to D... :-) For the time being, I think returning the string and asking others to be nice is better than using a Class or a struct ?
 I am remebering old good days of C programming with these char[]s.
 Damned fast but not maintainable.

That's where we are at now, I suppose. I've already run into some things regarding string literals. And that was even before any potential class library user... Copy on Write is currently just a Gentlemen's Agreement. And it needs the client using Url.hostname to play along.

Yep, Anders, seems like we are on the same track with you.

Aye. There's a fair number of people who share this concern, and we all seem to be asking for the same thing. I think/hope it's a matter of time rather than legitimacy.
 The thing is: I really don't know of a good style of
 library/component design in D.

FWIW: I've been forced down the path of the Gentleman's agreement, with the expectation that 'readonly' will materialize in some form. It is possible to minimise the occurence of such things, but it doesn't always provide the most lightweight implementation (as you noted elsewhere).
 If I am writing all code in one EXE by myself -
 fine - I am genetleman with myself. Well... even with
 myself... 'Today me' and 'yesterday me' frequently
 different persons.

 But! If I am desisginig library of common use....

 I can imagine: documentation starts from:

 "For gentlemen only...."

Good one! Perhaps we should come up with a GLA: "Gentleman's License Agreement" :-)

Cool! :) My variation: "Dgentleman's License Agreement" Andrew.
May 31 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7h66r$14s5$1 digitaldaemon.com...
 And what will be your advice then for:

 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }

 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.

 I am serious. I really want to know how to design it better.

Third party functions should follow the COW principle too. They should not modify strings that they don't know they are the owner of. Look at std.string.tolower for an example of this.
 I am remebering old good days of C programming with these char[]s.
 Damned fast but not maintainable.
 In C++ I have my own nice tool::string with reliable
 copy-on-write..... sigh.

The C++ std::string is slower than D strings. www.digitalmars.com/d/cppstrings.html C++ strings have another serious problem (that D doesn't have): you have to keep track of who the owner is, so it can be deleted (else you get a memory leak). In my experience, that is a LOT harder to get right than adhering to COW. Trying to absolutely determine ownership, like C++ does, is much harder than just being able to assume you don't own it.
May 31 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 19:37:03 -0700, Walter wrote:

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7h66r$14s5$1 digitaldaemon.com...
 And what will be your advice then for:

 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }

 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.

 I am serious. I really want to know how to design it better.

Third party functions should follow the COW principle too. They should not modify strings that they don't know they are the owner of.

Yes, and cyclists shouldn't run red lights either. We have to code in a world in which many people using our libraries don't care about what they 'should' do; they use anything that seems like an expedient idea at the time. Yes I know that not following the CoW rules is dangerous, but its not as dangerous as cyclists running red lights and they continue to do that. -- Derek Melbourne, Australia 1/06/2005 12:56:20 PM
May 31 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:7aqw8u524dge$.1hmvgp4jz3dvc.dlg 40tude.net...
 On Tue, 31 May 2005 19:37:03 -0700, Walter wrote:

 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7h66r$14s5$1 digitaldaemon.com...
 And what will be your advice then for:

 class Url {
   char[] _hostname;
   char[] hostname() { return _hostname; }
 }

 _hostname should not be changeable nor intentionally
 nor accidentally.
 hostname access pattern is primarily read. But it could possibly be
 passed in some third party functions.

 I am serious. I really want to know how to design it better.

Third party functions should follow the COW principle too. They should not modify strings that they don't know they are the owner of.

Yes, and cyclists shouldn't run red lights either. We have to code in a world in which many people using our libraries don't care about what they 'should' do; they use anything that seems like an expedient idea at the time. Yes I know that not following the CoW rules is dangerous, but its not as dangerous as cyclists running red lights and they continue to do that.

hmm. around here it isn't the cyclists that run red lights - it's the things with 4 wheels and that unused pedal called the "brake". :-P But more to topic I'm with Walter that when you look at the big picture COW is a reasonable balance of trade-offs. The only suggestion I have is to put COW more front-and-center in the array help so that people see it from the start and it becomes second nature. Compiler protection against malicious code isn't that important to me since people will go out of their way to write malicious code no matter what the compiler does. I'm more worried about the accidental D-newbie who doesn't know about arrays or COW. For those cases talking about COW right away in the doc will decrease the likelihood of newbie errors.
May 31 2005
parent reply kris <fu bar.org> writes:
Ben Hinkle wrote:
And what will be your advice then for:

class Url {
  char[] _hostname;
  char[] hostname() { return _hostname; }
}

_hostname should not be changeable nor intentionally
nor accidentally.
hostname access pattern is primarily read. But it could possibly be
passed in some third party functions.

I am serious. I really want to know how to design it better.

Third party functions should follow the COW principle too. They should not modify strings that they don't know they are the owner of.

Yes, and cyclists shouldn't run red lights either. We have to code in a world in which many people using our libraries don't care about what they 'should' do; they use anything that seems like an expedient idea at the time. Yes I know that not following the CoW rules is dangerous, but its not as dangerous as cyclists running red lights and they continue to do that.

hmm. around here it isn't the cyclists that run red lights - it's the things with 4 wheels and that unused pedal called the "brake". :-P But more to topic I'm with Walter that when you look at the big picture COW is a reasonable balance of trade-offs. The only suggestion I have is to put COW more front-and-center in the array help so that people see it from the start and it becomes second nature. Compiler protection against malicious code isn't that important to me since people will go out of their way to write malicious code no matter what the compiler does. I'm more worried about the accidental D-newbie who doesn't know about arrays or COW. For those cases talking about COW right away in the doc will decrease the likelihood of newbie errors.

Ben; Walter; I think perhaps you're missing a significant point being made? CoW is not the issue at stake ~ instead, what's being asked for is a mechanism to /enforce/ CoW. For example: the little example above should not be dup'ing the content before return, if it's only being used for reference (read-only) purposes by both parties (caller and callee). I think we can all agree on that? Yes? What's being asked for is a means whereby the compiler will 'prohibit' some other caller from using the returned array as a writable lValue; at compile time. That is, the CoW should be performed by the caller (not the callee), /if and when the caller needs to perform a write upon it/. And only at that time. Again, CoW is not being questioned. It's the total lack of enforcement that would be good to do something about. The compiler goes out of its way to catch out-of-bounds errors WRT arrays ~ we're asking for something similar here to avoid a source of silly, easily preventable, and hard to track down bugs. It would add some noticable weight to any story regarding robustness. Turn things around for a minute, and assume such a facility was available. It's not hard to see how this would be viewed in a most favourable light. And there's no downside for the code, or for the developer. Best of all worlds?
May 31 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"kris" <fu bar.org> wrote in message news:d7jemq$k2n$1 digitaldaemon.com...
 Ben Hinkle wrote:
And what will be your advice then for:

class Url {
  char[] _hostname;
  char[] hostname() { return _hostname; }
}

_hostname should not be changeable nor intentionally
nor accidentally.
hostname access pattern is primarily read. But it could possibly be
passed in some third party functions.

I am serious. I really want to know how to design it better.

Third party functions should follow the COW principle too. They should not modify strings that they don't know they are the owner of.

Yes, and cyclists shouldn't run red lights either. We have to code in a world in which many people using our libraries don't care about what they 'should' do; they use anything that seems like an expedient idea at the time. Yes I know that not following the CoW rules is dangerous, but its not as dangerous as cyclists running red lights and they continue to do that.

hmm. around here it isn't the cyclists that run red lights - it's the things with 4 wheels and that unused pedal called the "brake". :-P But more to topic I'm with Walter that when you look at the big picture COW is a reasonable balance of trade-offs. The only suggestion I have is to put COW more front-and-center in the array help so that people see it from the start and it becomes second nature. Compiler protection against malicious code isn't that important to me since people will go out of their way to write malicious code no matter what the compiler does. I'm more worried about the accidental D-newbie who doesn't know about arrays or COW. For those cases talking about COW right away in the doc will decrease the likelihood of newbie errors.

Ben; Walter; I think perhaps you're missing a significant point being made? CoW is not the issue at stake ~ instead, what's being asked for is a mechanism to /enforce/ CoW. For example: the little example above should not be dup'ing the content before return, if it's only being used for reference (read-only) purposes by both parties (caller and callee). I think we can all agree on that? Yes? What's being asked for is a means whereby the compiler will 'prohibit' some other caller from using the returned array as a writable lValue; at compile time. That is, the CoW should be performed by the caller (not the callee), /if and when the caller needs to perform a write upon it/. And only at that time.

*exactly*.
 Again, CoW is not being questioned. It's the total lack of enforcement 
 that would be good to do something about. The compiler goes out of its way 
 to catch out-of-bounds errors WRT arrays ~ we're asking for something 
 similar here to avoid a source of silly, easily preventable, and hard to 
 track down bugs. It would add some noticable weight to any story regarding 
 robustness.

 Turn things around for a minute, and assume such a facility was available. 
 It's not hard to see how this would be viewed in a most favourable light. 
 And there's no downside for the code, or for the developer. Best of all 
 worlds?

proposed const costs nothing in runtime. Even better - it helps to reduce unnecessary allocations. Let's take a look in some code fragments of Phobos: module std.openrj ----------------------------------- class Record { Field[] fields() { return m_fields.dup; } // just in case? // probably following is better? // const Field[] fields() { return m_fields; } } class Database { Record[] records() { return m_records.dup; } // the same Field[] fields() { return m_fields.dup; } } std.file---------------------------------------------- class FileException : Exception { this(char[] name, uint errno) { char* s = strerror(errno); // I have no idea this(name, std.string.toString(s).dup); // what is going on here. this.errno = errno; } } void listdir(char[] pathname, bool delegate(char[] filename) callback) { .... int len = std.string.strlen(fdata.d_name); if (!callback(fdata.d_name[0 .. len].dup)) // is dup really needed here??? // allocation of new string on each entry! Doh! .... } std.loader ---------------------------------------------- public class ExeModuleException : Exception { this(uint errcode) { super(std.string.toString(strerror(errcode)).dup); // why? } } std.socket ---------------------------------------------- void populate(protoent* proto) { type = cast(ProtocolType)proto.p_proto; name = std.string.toString(proto.p_name).dup; // why? .... aliases = new char[][i]; for(i = 0; i != aliases.length; i++) { aliases[i] = std.string.toString(proto.p_aliases[i]).dup; // what for? } .... } ---------------------------------------- etc.
Jun 05 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
[snip]
Let's take a look in some code fragments of Phobos:

module std.openrj -----------------------------------

class Record
{
    Field[] fields() { return m_fields.dup;  } // just in case?
    // probably following is better?
    // const Field[] fields() { return m_fields;  }
}

class Database
{
    Record[]  records()  {   return m_records.dup;   } // the same
    Field[]      fields()      {   return m_fields.dup;  }
}

std.file----------------------------------------------

class FileException : Exception
{
    this(char[] name, uint errno)
    { char* s = strerror(errno);             //  I have no idea
 this(name, std.string.toString(s).dup); //  what is going on here.
 this.errno = errno;
    }
}

void listdir(char[] pathname, bool delegate(char[] filename) callback)
{
 ....
     int len = std.string.strlen(fdata.d_name);
     if (!callback(fdata.d_name[0 .. len].dup)) // is dup really needed 
here???
             // allocation of new string on each entry! Doh!

 ....
}

std.loader ----------------------------------------------
public class ExeModuleException : Exception
{
    this(uint errcode)
    {
 super(std.string.toString(strerror(errcode)).dup); // why?
    }
}

std.socket ----------------------------------------------

void populate(protoent* proto)
 {
  type = cast(ProtocolType)proto.p_proto;
  name = std.string.toString(proto.p_name).dup; // why?
....
   aliases = new char[][i];
   for(i = 0; i != aliases.length; i++)
   {
    aliases[i] = std.string.toString(proto.p_aliases[i]).dup; // what for?
   }
....

}
----------------------------------------
etc.

Are the comments in the code above editorial by you or are they actually in the code? I'd say someone needs to look at phobos to clean up the dups. If you've already done the sweep then sending Walter the fixes would be helpful. Phobos can contain non-D programming styles occasionally - each module has a strong indication of the author's attitudes IMHO. ps - for kicks this weekend I've been adding a parameter to the MinTL containers to indicate read-only vs read-write. For example struct List(Value, bit ReadOnly = false) { static if (!ReadOnly) { void addTail(Value v){...} .. other functions that modify the list ... } .. functions that don't modify the list ... } You get a read-only view of a container by using the "readonly" property. I'll be finishing this stuff up soon and post to D.dtl later in the week.
Jun 05 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <Ben_member pathlink.com> wrote in message 
news:d80fq2$2gfv$1 digitaldaemon.com...
 [snip]
Let's take a look in some code fragments of Phobos:

module std.openrj -----------------------------------

class Record
{
    Field[] fields() { return m_fields.dup;  } // just in case?
    // probably following is better?
    // const Field[] fields() { return m_fields;  }
}

class Database
{
    Record[]  records()  {   return m_records.dup;   } // the same
    Field[]      fields()      {   return m_fields.dup;  }
}

std.file----------------------------------------------

class FileException : Exception
{
    this(char[] name, uint errno)
    { char* s = strerror(errno);             //  I have no idea
 this(name, std.string.toString(s).dup); //  what is going on here.
 this.errno = errno;
    }
}

void listdir(char[] pathname, bool delegate(char[] filename) callback)
{
 ....
     int len = std.string.strlen(fdata.d_name);
     if (!callback(fdata.d_name[0 .. len].dup)) // is dup really needed
here???
             // allocation of new string on each entry! Doh!

 ....
}

std.loader ----------------------------------------------
public class ExeModuleException : Exception
{
    this(uint errcode)
    {
 super(std.string.toString(strerror(errcode)).dup); // why?
    }
}

std.socket ----------------------------------------------

void populate(protoent* proto)
 {
  type = cast(ProtocolType)proto.p_proto;
  name = std.string.toString(proto.p_name).dup; // why?
....
   aliases = new char[][i];
   for(i = 0; i != aliases.length; i++)
   {
    aliases[i] = std.string.toString(proto.p_aliases[i]).dup; // what for?
   }
....

}
----------------------------------------
etc.

Are the comments in the code above editorial by you or are they actually in the code? I'd say someone needs to look at phobos to clean up the dups. If you've already done the sweep then sending Walter the fixes would be helpful. Phobos can contain non-D programming styles occasionally - each module has a strong indication of the author's attitudes IMHO.

Yes, comments are mine. I took a look again: 1) std.socket is fine: std.string.toString(proto.p_aliases[i]).dup is really needed as proto.p_aliases[i] is temporary string coming from system (sockets) 2) strerror(errcode)).dup probably make sense, as string there is coming from extern (C) char* strerror(int); 3) For std.openrj I don't really know Matthew intention. Seems like he needs such implementation for some reasons or he is following .dup advices for library module safe implementation. No idea to be short. const will help in such cases. 4) std.file -> void listdir(char[] pathname, bool delegate(char[] filename) callback) the way it is implemented and without const char[] filename seems like only reliable way of how to accomplish this as fdata.d_name coming from system static buffer. Other option would be to create temp buffer on stack, copy string value there and pass this buffer reference. But this is a copy on each iteration. With const such string can be passed 'as is'.
 ps - for kicks this weekend I've been adding a parameter to the MinTL 
 containers
 to indicate read-only vs read-write. For example
 struct List(Value, bit ReadOnly = false) {
 static if (!ReadOnly) {
 void addTail(Value v){...}
 .. other functions that modify the list ...
 }
 .. functions that don't modify the list ...
 }
 You get a read-only view of a container by using the "readonly" property. 
 I'll
 be finishing this stuff up soon and post to D.dtl later in the week.

(no offence, just wondering) I really don't know how such static flag would work. Suppose I declared: List(int, true /*ReadOnly*/) readOnlyList; How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right? My perception is that just something like const_iterator needs to be designed. Or ConstList without modification methods which will have sole ctor ConstList(List data). Andrew.
Jun 05 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 ps - for kicks this weekend I've been adding a parameter to the MinTL
 containers
 to indicate read-only vs read-write. For example
 struct List(Value, bit ReadOnly = false) {
 static if (!ReadOnly) {
 void addTail(Value v){...}
 .. other functions that modify the list ...
 }
 .. functions that don't modify the list ...
 }
 You get a read-only view of a container by using the "readonly" property. 
 I'll
 be finishing this stuff up soon and post to D.dtl later in the week.

(no offence, just wondering) I really don't know how such static flag would work. Suppose I declared: List(int, true /*ReadOnly*/) readOnlyList; How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right?

That's what the "readonly" property does. For example void foo(List!(int,ReadOnly) y) { ... } List!(int) x; x.add(10,20,30); foo(x.readonly); The 'ReadOnly' in the code above is a constant defined to be true. I think it improves readability of the code. If one wants to "cast away the const" I also added a property x.readwrite.
 My perception is that just something like const_iterator
 needs to be designed. Or ConstList without modification
 methods which will have sole ctor ConstList(List data).

Those are equivalent to iterator!(true) where iterator(bit Const = false) and List!(true) where List(bit Const = false). The "constness" becomes part of the type just like the types List/ConstList or iterator/const_iterator.
Jun 06 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d81fb2$7el$1 digitaldaemon.com...
 ps - for kicks this weekend I've been adding a parameter to the MinTL
 containers
 to indicate read-only vs read-write. For example
 struct List(Value, bit ReadOnly = false) {
 static if (!ReadOnly) {
 void addTail(Value v){...}
 .. other functions that modify the list ...
 }
 .. functions that don't modify the list ...
 }
 You get a read-only view of a container by using the "readonly" 
 property. I'll
 be finishing this stuff up soon and post to D.dtl later in the week.

(no offence, just wondering) I really don't know how such static flag would work. Suppose I declared: List(int, true /*ReadOnly*/) readOnlyList; How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right?

That's what the "readonly" property does. For example void foo(List!(int,ReadOnly) y) { ... } List!(int) x; x.add(10,20,30); foo(x.readonly); The 'ReadOnly' in the code above is a constant defined to be true. I think it improves readability of the code. If one wants to "cast away the const" I also added a property x.readwrite.
 My perception is that just something like const_iterator
 needs to be designed. Or ConstList without modification
 methods which will have sole ctor ConstList(List data).

Those are equivalent to iterator!(true) where iterator(bit Const = false) and List!(true) where List(bit Const = false). The "constness" becomes part of the type just like the types List/ConstList or iterator/const_iterator.

Jun 06 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:d81fb2$7el$1 digitaldaemon.com...
 ps - for kicks this weekend I've been adding a parameter to the MinTL
 containers
 to indicate read-only vs read-write. For example
 struct List(Value, bit ReadOnly = false) {
 static if (!ReadOnly) {
 void addTail(Value v){...}
 .. other functions that modify the list ...
 }
 .. functions that don't modify the list ...
 }
 You get a read-only view of a container by using the "readonly" 
 property. I'll
 be finishing this stuff up soon and post to D.dtl later in the week.

(no offence, just wondering) I really don't know how such static flag would work. Suppose I declared: List(int, true /*ReadOnly*/) readOnlyList; How to fill this list then? You will need some mechanism allowing to do mutable->immutable conversion, right?

That's what the "readonly" property does. For example void foo(List!(int,ReadOnly) y) { ... } List!(int) x; x.add(10,20,30); foo(x.readonly); The 'ReadOnly' in the code above is a constant defined to be true. I think it improves readability of the code. If one wants to "cast away the const" I also added a property x.readwrite.
 My perception is that just something like const_iterator
 needs to be designed. Or ConstList without modification
 methods which will have sole ctor ConstList(List data).

Those are equivalent to iterator!(true) where iterator(bit Const = false) and List!(true) where List(bit Const = false). The "constness" becomes part of the type just like the types List/ConstList or iterator/const_iterator.

Yep. It will work. It will increase size of generated code twice as you need second instantiation of the template (readonly version). But such specialized wrapper is definitely a solution for containers for places where robustness and modulraity is main requirements. Wish it will be possible to say something like char[].readonly or so for primary containers and pointers. As in most cases they are pretty sufficient and more effective. I took a look in compiler code. Seems I can implement constness for array and pointers pretty easily as everything is already there. Another option would be in implementation of extended/selected typedef notation: typedef char[] cstring: opSlice, opIndexAssign; // list of operations derived from base type. A bit ugly but would work. Andrew.
Jun 06 2005
prev sibling next sibling parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
How about immutable final String for general stuff end StringBuffer (or
whatever) for performance needs.

ubau

In article <d7h4rf$1345$1 digitaldaemon.com>, Walter says...
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7gtvf$qs0$1 digitaldaemon.com...
 java.lang.String class has a) methods b) String owns buffer - it controls
 buffer.

 In D is possible:
 int[char[]] map;
 char[] s = "something";
 map[s] = 1;
 s[0] = '?'; // I have no idea what result will be. sure not good.

 And you can bump into such problem quite easily in D. I personally
 did many times. And too hard to find source sometimes.

 In Java such collision is not possible in principle: String is final and
 immutable.

A number of languages use the immutable string idiom, and its corollary "always implicitly copy the string when writing to it". They all share another common characteristic - they're slow, and they're slow in a manner that is *not fixable*. And they're not just slower by a factor, many algorithms run *exponentially* slower because of the copying. D must be fast, and the only way to be fast with strings (and arrays) is to not have the language implicitly copy them, but to allow the programmer the flexibility to copy or not copy. To know when to copy, use the Copy On Write principle (COW). That is, if you're not *sure* you've got the only copy of a string, .dup it before modifying it. So why isn't that just as bad as the languages that implicitly copy on write? The answer is that often, you know that you are the sole owner, such as: char[] s = new char[10]; for (i = 0; i < 10; i++) s[i] = 'c'; Those other languages are doomed to make 10 copies of s. The D programmer needs to make 0 copies. As to your example above, when you pass a reference to a string to an associative array, then you aren't the sole owner of that string anymore. Don't change it. .dup it.

May 31 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
U.Baumanis wrote:

 How about immutable final String for general stuff end StringBuffer (or
 whatever) for performance needs.

If you want some Java-like string classes, I hacked some stuff together: http://www.algonet.se/~afb/d/dcaf/html/class_string.html http://www.algonet.se/~afb/d/dcaf/html/class_string_buffer.html That doesn't change the "readonly" (was: const) needs of the built-in string types of D (code unit arrays) ? Just something of a workaround. Kris has a much nicer wrapper (with ICU features) under the Mango Tree. --anders
May 31 2005
parent reply U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <d7hagf$194p$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
U.Baumanis wrote:

 How about immutable final String for general stuff end StringBuffer (or
 whatever) for performance needs.

If you want some Java-like string classes, I hacked some stuff together: http://www.algonet.se/~afb/d/dcaf/html/class_string.html http://www.algonet.se/~afb/d/dcaf/html/class_string_buffer.html That doesn't change the "readonly" (was: const) needs of the built-in string types of D (code unit arrays) ? Just something of a workaround. Kris has a much nicer wrapper (with ICU features) under the Mango Tree. --anders

Thanks! It would be nice to have it in std.string. Well, better somewhere than nowhere. :-) -- ubau
May 31 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
U.Baumanis wrote:

If you want some Java-like string classes, I hacked some stuff together:

That doesn't change the "readonly" (was: const) needs of the built-in
string types of D (code unit arrays) ? Just something of a workaround.
Kris has a much nicer wrapper (with ICU features) under the Mango Tree.

Thanks! It would be nice to have it in std.string. Well, better somewhere than nowhere. :-)

Don't misunderstand me, I do not think that D needs a String class... (it was just a small example on how one could implement such a beast) The default D string type is still "char[]". Just wished there was a simple way to preserve the readonly-ness of it, without resorting to using a fullblown wrapper class - like Java does ? Something like: readonly char[] s = "hello"; --anders PS. Name "const" has been renamed for political reasons. Kinda like typedef, which changed name into "alias".
May 31 2005
parent U.Baumanis <U.Baumanis_member pathlink.com> writes:
In article <d7hl28$1ikj$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
U.Baumanis wrote:

If you want some Java-like string classes, I hacked some stuff together:

That doesn't change the "readonly" (was: const) needs of the built-in
string types of D (code unit arrays) ? Just something of a workaround.
Kris has a much nicer wrapper (with ICU features) under the Mango Tree.

Thanks! It would be nice to have it in std.string. Well, better somewhere than nowhere. :-)

Don't misunderstand me, I do not think that D needs a String class... (it was just a small example on how one could implement such a beast) The default D string type is still "char[]". Just wished there was a simple way to preserve the readonly-ness of it, without resorting to using a fullblown wrapper class - like Java does ? Something like: readonly char[] s = "hello"; --anders PS. Name "const" has been renamed for political reasons. Kinda like typedef, which changed name into "alias".

You are right! I forgot why i wanted a String class... May be because I have to use Java at work. ;-) -- ubau
May 31 2005
prev sibling next sibling parent reply Eugene Pelekhay <pelekhay gmail.com> writes:
Walter wrote:
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gtvf$qs0$1 digitaldaemon.com...
 
java.lang.String class has a) methods b) String owns buffer - it controls
buffer.

In D is possible:
int[char[]] map;
char[] s = "something";
map[s] = 1;
s[0] = '?'; // I have no idea what result will be. sure not good.

And you can bump into such problem quite easily in D. I personally
did many times. And too hard to find source sometimes.

In Java such collision is not possible in principle: String is final and
immutable.

A number of languages use the immutable string idiom, and its corollary "always implicitly copy the string when writing to it". They all share another common characteristic - they're slow, and they're slow in a manner that is *not fixable*. And they're not just slower by a factor, many algorithms run *exponentially* slower because of the copying. D must be fast, and the only way to be fast with strings (and arrays) is to not have the language implicitly copy them, but to allow the programmer the flexibility to copy or not copy. To know when to copy, use the Copy On Write principle (COW). That is, if you're not *sure* you've got the only copy of a string, .dup it before modifying it. So why isn't that just as bad as the languages that implicitly copy on write? The answer is that often, you know that you are the sole owner, such as: char[] s = new char[10]; for (i = 0; i < 10; i++) s[i] = 'c';

May be I'm dummy, but I don't see in this example why this other languages must copy it 10 times. For my implementation of reference counted string in my C++ project, copy will be performed also 0 times. And if there is more then 1 reference to instance exsits it's only one copy operation will be performed. I see only one advantage in current implementation of string - not need to check or increment/decrement reference counter, but instead of this string duplication is required
 
 Those other languages are doomed to make 10 copies of s. The D programmer
 needs to make 0 copies.
 
 As to your example above, when you pass a reference to a string to an
 associative array, then you aren't the sole owner of that string anymore.
 Don't change it. .dup it.
 
 

May 31 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Eugene Pelekhay" <pelekhay gmail.com> wrote in message
news:d7hfuh$1ejl$1 digitaldaemon.com...
 May be I'm dummy, but I don't see in this example why this other
 languages must copy it 10 times. For my implementation of reference
 counted string in my C++ project, copy will be performed also 0 times.
 And if there is more then 1 reference to instance exsits it's only one
 copy operation will be performed. I see only one advantage in current
 implementation of string - not need to check or increment/decrement
 reference counter, but instead of this string duplication is required

You're right that you can avoid excessive copying by doing ref counting. Reference counting carries with it other penalties - storage must be allocated for the ref count, every copy increments the count, and every reference that goes out of scope must decrement the count. Add in exception handling, and the price is high (although C++'s mechanisms hide that price from you). Ref counting would make it impractical to do D's array slices. Furthermore, in the presence of garbage collection, layering on top a reference counting mechanism probably means you'll want to ditch the gc and go with a full ref counting architecture for every object. In my experience, such is slower than using mark/sweep gc.
May 31 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d7j6na$d2f$1 digitaldaemon.com...
 "Eugene Pelekhay" <pelekhay gmail.com> wrote in message
 news:d7hfuh$1ejl$1 digitaldaemon.com...
 May be I'm dummy, but I don't see in this example why this other
 languages must copy it 10 times. For my implementation of reference
 counted string in my C++ project, copy will be performed also 0 times.
 And if there is more then 1 reference to instance exsits it's only one
 copy operation will be performed. I see only one advantage in current
 implementation of string - not need to check or increment/decrement
 reference counter, but instead of this string duplication is required

You're right that you can avoid excessive copying by doing ref counting. Reference counting carries with it other penalties - storage must be allocated for the ref count, every copy increments the count, and every reference that goes out of scope must decrement the count. Add in exception handling, and the price is high (although C++'s mechanisms hide that price from you). Ref counting would make it impractical to do D's array slices. Furthermore, in the presence of garbage collection, layering on top a reference counting mechanism probably means you'll want to ditch the gc and go with a full ref counting architecture for every object. In my experience, such is slower than using mark/sweep gc.

Yes, GC does good job. In some places. In other places ref-counting is better. Ideal language shall allow to use both. Dot. Everything has its own price: as much objects allocated (your .dup advice) as slow their scanning will be by GC. And I am not sure what is faster in fact in big picture - ref-counting for strings or GC. So far Java and C# are not demonstrating nothing spectacular here - it is rather defeat. At least in real life projects I can test by hands. But in abstract tests - everything is just perfect. I know only one: as less GC cycle as better. As it locks everything and at unpredictable moment. ref-counting has price but this price is acceptable as it is predictable and accountible and equally spreaded. The best solution is as always - in the middle - in the balance between GC and not-GC. If I have vector of passive elements (chars) I would go with ref-countng for creating envelope safe to pass back and forth. If I have container of active elements (objects) with complex and sometimes unknown system of relationship I'll go with GC to avoid headaches with cyclic references and so on and broken pointers. Strings are strange types, they are both : wave and particle - scalar and aggregate at the same time. String as a wrapper-owner of character buffer allows somehow (not ideally!) to work with the string using its both forms, balancing between str1 = str2, str1 == str2 and str1.ptr == str2.ptr. Back to const. Having bultin arrays and slicing now creates *prerequisites* of optimal or suboptimal string handling. But e.g. slicing is just nothing without const ( for strings especially). See: I've found some string fragment and passed it to some function. This function does something and is passing it further. All these functions were built with good intentions and good programmers. But these programmers live in 12 hours timezone shift . The only one feasible way for them is self documenting code. Someone thinked that this particular string is safe to zero terminate it. Everything is ruined. To find source of it is not trivial. I bet that second time when it will happen D will be dead for the project. When it happened for me first time I've decided to do a string wrapper emulating constness. JUST NO WAY IN D. not technically nor theoretically. Neither '=' overload (to implement ownership and refcounting) nor const. Nothing. Dead corner. char[] is not a string - it is array of chars. Pattern of string use is quite different from array. As a rule array is a heart of some container and pretty frequently already wrapped. But strings are flying everywhere. D shall have const for arrays and pointers to be considered as a language for teams and serious projects. IMHO.
Jun 01 2005
parent reply Kramer <Kramer_member pathlink.com> writes:
Well put.  Again, I think a point has been made for having a facility in the
language to say "this thing shouldn't change value".  I understand that some
devious programmer can find a way to change something that the compiler verified
shouldn't be changed.  But I think that programmer is in the minority and the
majority of programmers could use some self-documenting help from the
language/compiler (and the devious programmer is specifically and intentionally
going outside of the program specification, which I'd reckon could somehow be
done in any language).

Again, my $0.02.  But I think many have put in their $0.02 and will continue to
do so because many believe it's an important concept.  When will all the $0.02
contributions add up to be enough?

-Kramer

In article <d7li3v$2psu$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Walter" <newshound digitalmars.com> wrote in message 
news:d7j6na$d2f$1 digitaldaemon.com...
 "Eugene Pelekhay" <pelekhay gmail.com> wrote in message
 news:d7hfuh$1ejl$1 digitaldaemon.com...
 May be I'm dummy, but I don't see in this example why this other
 languages must copy it 10 times. For my implementation of reference
 counted string in my C++ project, copy will be performed also 0 times.
 And if there is more then 1 reference to instance exsits it's only one
 copy operation will be performed. I see only one advantage in current
 implementation of string - not need to check or increment/decrement
 reference counter, but instead of this string duplication is required

You're right that you can avoid excessive copying by doing ref counting. Reference counting carries with it other penalties - storage must be allocated for the ref count, every copy increments the count, and every reference that goes out of scope must decrement the count. Add in exception handling, and the price is high (although C++'s mechanisms hide that price from you). Ref counting would make it impractical to do D's array slices. Furthermore, in the presence of garbage collection, layering on top a reference counting mechanism probably means you'll want to ditch the gc and go with a full ref counting architecture for every object. In my experience, such is slower than using mark/sweep gc.

Yes, GC does good job. In some places. In other places ref-counting is better. Ideal language shall allow to use both. Dot. Everything has its own price: as much objects allocated (your .dup advice) as slow their scanning will be by GC. And I am not sure what is faster in fact in big picture - ref-counting for strings or GC. So far Java and C# are not demonstrating nothing spectacular here - it is rather defeat. At least in real life projects I can test by hands. But in abstract tests - everything is just perfect. I know only one: as less GC cycle as better. As it locks everything and at unpredictable moment. ref-counting has price but this price is acceptable as it is predictable and accountible and equally spreaded. The best solution is as always - in the middle - in the balance between GC and not-GC. If I have vector of passive elements (chars) I would go with ref-countng for creating envelope safe to pass back and forth. If I have container of active elements (objects) with complex and sometimes unknown system of relationship I'll go with GC to avoid headaches with cyclic references and so on and broken pointers. Strings are strange types, they are both : wave and particle - scalar and aggregate at the same time. String as a wrapper-owner of character buffer allows somehow (not ideally!) to work with the string using its both forms, balancing between str1 = str2, str1 == str2 and str1.ptr == str2.ptr. Back to const. Having bultin arrays and slicing now creates *prerequisites* of optimal or suboptimal string handling. But e.g. slicing is just nothing without const ( for strings especially). See: I've found some string fragment and passed it to some function. This function does something and is passing it further. All these functions were built with good intentions and good programmers. But these programmers live in 12 hours timezone shift . The only one feasible way for them is self documenting code. Someone thinked that this particular string is safe to zero terminate it. Everything is ruined. To find source of it is not trivial. I bet that second time when it will happen D will be dead for the project. When it happened for me first time I've decided to do a string wrapper emulating constness. JUST NO WAY IN D. not technically nor theoretically. Neither '=' overload (to implement ownership and refcounting) nor const. Nothing. Dead corner. char[] is not a string - it is array of chars. Pattern of string use is quite different from array. As a rule array is a heart of some container and pretty frequently already wrapped. But strings are flying everywhere. D shall have const for arrays and pointers to be considered as a language for teams and serious projects. IMHO.

Jun 01 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 ....for having a facility in the
 language to say "this thing shouldn't change value".

exactly. It is enough to have const T[] and const T* as distinct types from just T[] and T* . const T[] type has no opIndexAssign, length(int) and cannot be lvalue at all. Simple as 1-2-3. I really don't understand what is the motivation to do not have them. String literals are const char[] by definition. Andrew. "Kramer" <Kramer_member pathlink.com> wrote in message news:d7ljra$2qvj$1 digitaldaemon.com...
 Well put.  Again, I think a point has been made for having a facility in 
 the
 language to say "this thing shouldn't change value".  I understand that 
 some
 devious programmer can find a way to change something that the compiler 
 verified
 shouldn't be changed.  But I think that programmer is in the minority and 
 the
 majority of programmers could use some self-documenting help from the
 language/compiler (and the devious programmer is specifically and 
 intentionally
 going outside of the program specification, which I'd reckon could somehow 
 be
 done in any language).

 Again, my $0.02.  But I think many have put in their $0.02 and will 
 continue to
 do so because many believe it's an important concept.  When will all the 
 $0.02
 contributions add up to be enough?

 -Kramer

 In article <d7li3v$2psu$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Walter" <newshound digitalmars.com> wrote in message
news:d7j6na$d2f$1 digitaldaemon.com...
 "Eugene Pelekhay" <pelekhay gmail.com> wrote in message
 news:d7hfuh$1ejl$1 digitaldaemon.com...
 May be I'm dummy, but I don't see in this example why this other
 languages must copy it 10 times. For my implementation of reference
 counted string in my C++ project, copy will be performed also 0 times.
 And if there is more then 1 reference to instance exsits it's only one
 copy operation will be performed. I see only one advantage in current
 implementation of string - not need to check or increment/decrement
 reference counter, but instead of this string duplication is required

You're right that you can avoid excessive copying by doing ref counting. Reference counting carries with it other penalties - storage must be allocated for the ref count, every copy increments the count, and every reference that goes out of scope must decrement the count. Add in exception handling, and the price is high (although C++'s mechanisms hide that price from you). Ref counting would make it impractical to do D's array slices. Furthermore, in the presence of garbage collection, layering on top a reference counting mechanism probably means you'll want to ditch the gc and go with a full ref counting architecture for every object. In my experience, such is slower than using mark/sweep gc.

Yes, GC does good job. In some places. In other places ref-counting is better. Ideal language shall allow to use both. Dot. Everything has its own price: as much objects allocated (your .dup advice) as slow their scanning will be by GC. And I am not sure what is faster in fact in big picture - ref-counting for strings or GC. So far Java and C# are not demonstrating nothing spectacular here - it is rather defeat. At least in real life projects I can test by hands. But in abstract tests - everything is just perfect. I know only one: as less GC cycle as better. As it locks everything and at unpredictable moment. ref-counting has price but this price is acceptable as it is predictable and accountible and equally spreaded. The best solution is as always - in the middle - in the balance between GC and not-GC. If I have vector of passive elements (chars) I would go with ref-countng for creating envelope safe to pass back and forth. If I have container of active elements (objects) with complex and sometimes unknown system of relationship I'll go with GC to avoid headaches with cyclic references and so on and broken pointers. Strings are strange types, they are both : wave and particle - scalar and aggregate at the same time. String as a wrapper-owner of character buffer allows somehow (not ideally!) to work with the string using its both forms, balancing between str1 = str2, str1 == str2 and str1.ptr == str2.ptr. Back to const. Having bultin arrays and slicing now creates *prerequisites* of optimal or suboptimal string handling. But e.g. slicing is just nothing without const ( for strings especially). See: I've found some string fragment and passed it to some function. This function does something and is passing it further. All these functions were built with good intentions and good programmers. But these programmers live in 12 hours timezone shift . The only one feasible way for them is self documenting code. Someone thinked that this particular string is safe to zero terminate it. Everything is ruined. To find source of it is not trivial. I bet that second time when it will happen D will be dead for the project. When it happened for me first time I've decided to do a string wrapper emulating constness. JUST NO WAY IN D. not technically nor theoretically. Neither '=' overload (to implement ownership and refcounting) nor const. Nothing. Dead corner. char[] is not a string - it is array of chars. Pattern of string use is quite different from array. As a rule array is a heart of some container and pretty frequently already wrapped. But strings are flying everywhere. D shall have const for arrays and pointers to be considered as a language for teams and serious projects. IMHO.


Jun 01 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.this-is.spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Fedoniouk schrieb am Wed, 1 Jun 2005 17:55:04 -0700:
 ....for having a facility in the
 language to say "this thing shouldn't change value".

exactly. It is enough to have const T[] and const T* as distinct types from just T[] and T* . const T[] type has no opIndexAssign, length(int) and cannot be lvalue at all. Simple as 1-2-3. I really don't understand what is the motivation to do not have them. String literals are const char[] by definition.

Sadly it's not that simple. The content of the string literals are known at compile time and can thus be placed in an OS-protected memory area. If the array content is mutable by default, the const attribute for arrays is a mere suggestion. Do a bit of pointer math or store arrays as elements in other arrays and the const attribute loses it's effect. If the array content is by default immutable - that is, once an element is set it can't be changed - the "mutable" attribute could be used to allow the editing of array element. In difference to the current system the compiler could only allow those cases where it can _prove_ that the array is mutable. What happens if you store pointers/object references in the array?! In addition this has some negative impact for mixed closed-open source projects as the compiler would have to treat all arrays comming from the closed source part as immutable. The third way is to allow only assigning and not changeing any var. It's neat but pointer math gets in the way again. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCnsBx3w+/yD4P9tIRAj+BAKCZTrUBYd4ARfWuxMcmN9126dyVmQCcDI5/ St2gvmZjNrzBbITklIQYb+g= =WdJv -----END PGP SIGNATURE-----
Jun 02 2005
next sibling parent reply kris <fu bar.org> writes:
Thomas Kuehne wrote:
 If the array content is by default immutable - that is, once an element
 is set it can't be changed - the "mutable" attribute could be used to
 allow the editing of array element. 

Now there's a different idea. Talk about CoW enforcement :-)
 In difference to the current system
 the compiler could only allow those cases where it can _prove_ that the
 array is mutable. What happens if you store pointers/object
 references in the array?!

Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas? Aliases upon the array still have to go through the same type-matching procedure; Yes? If you cast an immutable type to a mutable type, then all bets are off; just as they are with *cast(void *)0 = 0;
 In addition this has some negative impact for mixed closed-open
 source projects as the compiler would have to treat all arrays comming
 from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?
Jun 02 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"kris" <fu bar.org> wrote in message news:d7mbac$c2d$1 digitaldaemon.com...
 Thomas Kuehne wrote:
 If the array content is by default immutable - that is, once an element
 is set it can't be changed - the "mutable" attribute could be used to
 allow the editing of array element.

Now there's a different idea. Talk about CoW enforcement :-)
 In difference to the current system
 the compiler could only allow those cases where it can _prove_ that the
 array is mutable. What happens if you store pointers/object
 references in the array?!

Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas? Aliases upon the array still have to go through the same type-matching procedure; Yes?

Thanks, Kris. This is exactly what I have in my mind.
 If you cast an immutable type to a mutable type, then all bets are off; 
 just as they are with *cast(void *)0 = 0;

 In addition this has some negative impact for mixed closed-open
 source projects as the compiler would have to treat all arrays comming
 from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?

This "all arrays comming from the closed source part as immutable." sounds like Ride of the Valkyries from Wagner. I can feel two layers of sense there but only managed to get one :). Thomas, for the D sake, what it was all about? Andrew.
Jun 02 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.this-is.spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:51:30 -0700:
 In addition this has some negative impact for mixed closed-open
 source projects as the compiler would have to treat all arrays comming
 from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?

This "all arrays comming from the closed source part as immutable." sounds like Ride of the Valkyries from Wagner. I can feel two layers of sense there but only managed to get one :). Thomas, for the D sake, what it was all about?

If mutability is a "suggestion" than there is no problem with open source projects that use close source libs. However if mutability is to be strictly enforced, we would either need runtime checks or would have to treat the arrays from the closed source part as immutable. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCnuJO3w+/yD4P9tIRApxdAJ9f/18fE6/lblc/VPVItHbhkR9JXQCdGW/E IUXVTD7HHXPJy0qhpHxFfLE= =b0Hv -----END PGP SIGNATURE-----
Jun 02 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.this-is.spam.cn> wrote in message 
news:eb43n2-na4.ln1 lnews.kuehne.cn...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:51:30 -0700:
 In addition this has some negative impact for mixed closed-open
 source projects as the compiler would have to treat all arrays comming
 from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?

This "all arrays comming from the closed source part as immutable." sounds like Ride of the Valkyries from Wagner. I can feel two layers of sense there but only managed to get one :). Thomas, for the D sake, what it was all about?

If mutability is a "suggestion" than there is no problem with open source projects that use close source libs. However if mutability is to be strictly enforced, we would either need runtime checks or would have to treat the arrays from the closed source part as immutable. Thomas

I think I see now what you mean ... Thanks, Thomas.
Jun 02 2005
prev sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Here are my thoughts - if people would like to hear them :)

1) Everyone that has posted to this thread agrees that there needs to be 
a language feature that prevents code from changing the value of a 
variable/array.  Call it readonly, const, whatever.

2) There have been no suggestions on how to actually enforce 
immutability in a manner that is 100% correct - there are always 
loopholes that a devious programmer can go through.  From my point of 
view, the only truely correct way of enforcing constness is to place the 
memory in question under the protection of the hardware MMU - which IMHO 
will be very wasteful on memory & probably non-trivial to implement.

3) C++ errors at compile time for const violations and that is generally 
what people would like from D also.

I think that we need to face reality - there is no easy solution that is 
actually 100% correct.  However, since D is a practical language we 
don't need to be 100% correct, we only need enough protection to prevent 
accidental bugs.  Given a language that allows pointers, a programmer 
will be able to break constness.  If you need to write a completely 
robust library that malicious programmers will _try_ to break, then 
relying on const will never cut it.  You must add your own protection 
mechanisms - like always duping memory before returning it.  But I would 
say that this kind of environment is extremely rare.

So I think that a simple const mechanism that aims only to help prevent 
bugs, and offers no actual assurances about true constness, ought to be 
enough to satisfy most people.

I am sure that I don't grasp the full implications of how to implement 
this, but honestly it doesn't sound that hard.  I've attached a simple 
example that very nearly does simple protection by only using the 
built-in type system.  If you could implicitly promote char -> 
const_char then this would pretty much work.

Does this sound workable - or am I being totally naive?

Brad

import std.stdio;

typedef char const_char;

int main (char[][] arg)
{
     char[] plain = "This is a plain char string";
     const_char[] strange = cast(const_char[])"This is a const_char string";

     plain = foo(plain);
     strange = foo(strange);

     // no implicit casting, so the below doesn't work
     //char[] test = strange;
     //const_char[] test2 = plain;
     return 0;
}

char[] foo(char[] f)
{
     // normally, writefln would only take const_char[]'s
     // but char[] would be allowed to be implicitly promoted to 
const_char[]
     writefln ("char[] is ", f);
     return f;
}

const_char[] foo(const_char[] f)
{
     // normally, writefln would only take const_char[]'s - so
     // wouldn't need to cast
     writefln ("const_char[] is ", cast(char[])f);
     return f;
}
Jun 02 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d7nbhs$1p2o$1 digitaldaemon.com...
 Here are my thoughts - if people would like to hear them :)

 1) Everyone that has posted to this thread agrees that there needs to be a 
 language feature that prevents code from changing the value of a 
 variable/array.  Call it readonly, const, whatever.

 2) There have been no suggestions on how to actually enforce immutability 
 in a manner that is 100% correct - there are always loopholes that a 
 devious programmer can go through.  From my point of view, the only truely 
 correct way of enforcing constness is to place the memory in question 
 under the protection of the hardware MMU - which IMHO will be very 
 wasteful on memory & probably non-trivial to implement.

 3) C++ errors at compile time for const violations and that is generally 
 what people would like from D also.

 I think that we need to face reality - there is no easy solution that is 
 actually 100% correct.  However, since D is a practical language we don't 
 need to be 100% correct, we only need enough protection to prevent 
 accidental bugs.  Given a language that allows pointers, a programmer will 
 be able to break constness.  If you need to write a completely robust 
 library that malicious programmers will _try_ to break, then relying on 
 const will never cut it.  You must add your own protection mechanisms - 
 like always duping memory before returning it.  But I would say that this 
 kind of environment is extremely rare.

 So I think that a simple const mechanism that aims only to help prevent 
 bugs, and offers no actual assurances about true constness, ought to be 
 enough to satisfy most people.

Exactly. And again, we don't need it at the scale it made in C++ . Classes can be protected "by hands", and in fact protection for class instnaces is already there: setter/getters, private/public, etc. Again just need const for T[] and T*. See: char[] is atomic type in terms of that it is builtin in D. But they are implemented differently from other scalars- they are references to some memory locations. And this referencing adds one more 'dimension' requirement - readonlyness. This is exactly as function parameter attributes: in, out. Walter said A but is shy to say B. Or I don't understand something. Andrew.
 I am sure that I don't grasp the full implications of how to implement 
 this, but honestly it doesn't sound that hard.  I've attached a simple 
 example that very nearly does simple protection by only using the built-in 
 type system.  If you could implicitly promote char -> const_char then this 
 would pretty much work.

 Does this sound workable - or am I being totally naive?

 Brad

 import std.stdio;

 typedef char const_char;

 int main (char[][] arg)
 {
     char[] plain = "This is a plain char string";
     const_char[] strange = cast(const_char[])"This is a const_char 
 string";

     plain = foo(plain);
     strange = foo(strange);

     // no implicit casting, so the below doesn't work
     //char[] test = strange;
     //const_char[] test2 = plain;
     return 0;
 }

 char[] foo(char[] f)
 {
     // normally, writefln would only take const_char[]'s
     // but char[] would be allowed to be implicitly promoted to 
 const_char[]
     writefln ("char[] is ", f);
     return f;
 }

 const_char[] foo(const_char[] f)
 {
     // normally, writefln would only take const_char[]'s - so
     // wouldn't need to cast
     writefln ("const_char[] is ", cast(char[])f);
     return f;
 } 

Jun 02 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d7nbhs$1p2o$1 digitaldaemon.com>, Brad Beveridge says...
I think that we need to face reality - there is no easy solution that is 
actually 100% correct.  However, since D is a practical language we 
don't need to be 100% correct, we only need enough protection to prevent 
accidental bugs.

So I think that a simple const mechanism that aims only to help prevent 
bugs, and offers no actual assurances about true constness, ought to be 
enough to satisfy most people.

My impression of Walter is that he doesn't like solutions that are just okay, particularly if they add significant compiler complexity. And while I think this is probably feasible for arrays, it's a slippery slope from there to logical const-ness for user defined objects. Personally, I'll take anything I can get, but I think the likelihood we'll see this for 1.0 is quite slim. Sean
Jun 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d7nkra$22fh$1 digitaldaemon.com...
 In article <d7nbhs$1p2o$1 digitaldaemon.com>, Brad Beveridge says...
I think that we need to face reality - there is no easy solution that is
actually 100% correct.  However, since D is a practical language we
don't need to be 100% correct, we only need enough protection to prevent
accidental bugs.

So I think that a simple const mechanism that aims only to help prevent
bugs, and offers no actual assurances about true constness, ought to be
enough to satisfy most people.

My impression of Walter is that he doesn't like solutions that are just okay, particularly if they add significant compiler complexity.

Ummm... Is it in fact so complex? I think everything needed is already there.
 And while I think
 this is probably feasible for arrays, it's a slippery slope from there to
 logical const-ness for user defined objects.

Don't need this for UDO. Such objects have all needed for encapsulation/ protection already. Basic types in contrary are naked now. You cannot define methods/envelopes for them. const is not 100% solution in terms of real protection. But there are no 100% solutions at all, even in D. It is a compromise and a good one - it costs nothing in runtime and almost nothing in compile time.
Personally, I'll take anything I
 can get, but I think the likelihood we'll see this for 1.0 is quite slim.

Too bad if we will have not this in 1.0. Without const for arrays and pointers D feature set is incomplete. You can write word counters spanning two three pages but for serious projects with many developers involved const (especially for strings) is must have feature. I am managing GUI projects last 10 years and I am certain. Fighting with three bugs in Harmonia took me one week. Two of them was about stirng/array corruptions. And I was designing it by myself! I don't want to share this experience with other team members where probability of such things is higher. Again D is a good language. I would say D is near perfect especially for GUI. But this particular area (constness of builtin types) is not finished - as there are no workarounds at all to protect references. Advices to spread .dups everywhere I will left for .NET/Java community - there they will be accepted. Andrew.
Jun 02 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d7nmto$24n4$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Sean Kelly" <sean f4.ca> wrote in message 
news:d7nkra$22fh$1 digitaldaemon.com...
 In article <d7nbhs$1p2o$1 digitaldaemon.com>, Brad Beveridge says...
I think that we need to face reality - there is no easy solution that is
actually 100% correct.  However, since D is a practical language we
don't need to be 100% correct, we only need enough protection to prevent
accidental bugs.

So I think that a simple const mechanism that aims only to help prevent
bugs, and offers no actual assurances about true constness, ought to be
enough to satisfy most people.

My impression of Walter is that he doesn't like solutions that are just okay, particularly if they add significant compiler complexity.

Ummm... Is it in fact so complex? I think everything needed is already there.

I don't think it is complex. I was thinking of object const-ness when I wrote this. Sorry for the confusion.
 And while I think
 this is probably feasible for arrays, it's a slippery slope from there to
 logical const-ness for user defined objects.

Don't need this for UDO. Such objects have all needed for encapsulation/ protection already. Basic types in contrary are naked now. You cannot define methods/envelopes for them. const is not 100% solution in terms of real protection. But there are no 100% solutions at all, even in D. It is a compromise and a good one - it costs nothing in runtime and almost nothing in compile time.

I disagree that UDO have what's needed in terms of protection. Though logical const-ness is far from simple to implement. Sean
Jun 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d7nod5$263o$1 digitaldaemon.com...
 In article <d7nmto$24n4$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Sean Kelly" <sean f4.ca> wrote in message
news:d7nkra$22fh$1 digitaldaemon.com...
 In article <d7nbhs$1p2o$1 digitaldaemon.com>, Brad Beveridge says...
I think that we need to face reality - there is no easy solution that is
actually 100% correct.  However, since D is a practical language we
don't need to be 100% correct, we only need enough protection to prevent
accidental bugs.

So I think that a simple const mechanism that aims only to help prevent
bugs, and offers no actual assurances about true constness, ought to be
enough to satisfy most people.

My impression of Walter is that he doesn't like solutions that are just okay, particularly if they add significant compiler complexity.

Ummm... Is it in fact so complex? I think everything needed is already there.

I don't think it is complex. I was thinking of object const-ness when I wrote this. Sorry for the confusion.

Why sorry? Anyway...
 And while I think
 this is probably feasible for arrays, it's a slippery slope from there 
 to
 logical const-ness for user defined objects.

Don't need this for UDO. Such objects have all needed for encapsulation/ protection already. Basic types in contrary are naked now. You cannot define methods/envelopes for them. const is not 100% solution in terms of real protection. But there are no 100% solutions at all, even in D. It is a compromise and a good one - it costs nothing in runtime and almost nothing in compile time.

I disagree that UDO have what's needed in terms of protection. Though logical const-ness is far from simple to implement.

In user defined objects at least you can say 'protect'. Protect some operations and functions from outside This is compile time protection and not runtime! . In runtime you can relatively easy get a pointer to private variable and change it outside. Following logic that we cannot reach 100% protection we shall remove this 'private', 'package' etc. What for they were introduced? They are not 100% protecting!. You can do dynamic protection for UDO : you can naturally implement: "in this particular state of object this particular property is immutable, etc." Right? What we all want to have is simple: "by using const for arrays and pointers we want to make some methods of const types 'private' - not accessible". This is it.
 Sean

 

Jun 02 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Ok, side question, assume we're going to use 'const' (or any keyword) for  
array contents (something I've asked for in the past), how do we write it?

As it stands:
   const char[] bob;

'currently' makes the "array reference" constant. Would we then need:
   char[] const bob;

or perhaps
   char[const] bob;

or maybe as it's const it has to have an initialiser:
   char[] bob = "test";

(assuming of course that "test" is automatically constant)
or would that give an error and require the const keyword somewhere, as in  
one of the first two ideas.

Regan

On Thu, 2 Jun 2005 13:48:06 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
 news:d7nod5$263o$1 digitaldaemon.com...
 In article <d7nmto$24n4$1 digitaldaemon.com>, Andrew Fedoniouk says...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:d7nkra$22fh$1 digitaldaemon.com...
 In article <d7nbhs$1p2o$1 digitaldaemon.com>, Brad Beveridge says...
 I think that we need to face reality - there is no easy solution  
 that is
 actually 100% correct.  However, since D is a practical language we
 don't need to be 100% correct, we only need enough protection to  
 prevent
 accidental bugs.

 So I think that a simple const mechanism that aims only to help  
 prevent
 bugs, and offers no actual assurances about true constness, ought to  
 be
 enough to satisfy most people.

My impression of Walter is that he doesn't like solutions that are just okay, particularly if they add significant compiler complexity.

Ummm... Is it in fact so complex? I think everything needed is already there.

I don't think it is complex. I was thinking of object const-ness when I wrote this. Sorry for the confusion.

Why sorry? Anyway...
 And while I think
 this is probably feasible for arrays, it's a slippery slope from there
 to
 logical const-ness for user defined objects.

Don't need this for UDO. Such objects have all needed for encapsulation/ protection already. Basic types in contrary are naked now. You cannot define methods/envelopes for them. const is not 100% solution in terms of real protection. But there are no 100% solutions at all, even in D. It is a compromise and a good one - it costs nothing in runtime and almost nothing in compile time.

I disagree that UDO have what's needed in terms of protection. Though logical const-ness is far from simple to implement.

In user defined objects at least you can say 'protect'. Protect some operations and functions from outside This is compile time protection and not runtime! . In runtime you can relatively easy get a pointer to private variable and change it outside. Following logic that we cannot reach 100% protection we shall remove this 'private', 'package' etc. What for they were introduced? They are not 100% protecting!. You can do dynamic protection for UDO : you can naturally implement: "in this particular state of object this particular property is immutable, etc." Right? What we all want to have is simple: "by using const for arrays and pointers we want to make some methods of const types 'private' - not accessible". This is it.
 Sean


Jun 02 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Regan Heath wrote:
 Ok, side question, assume we're going to use 'const' (or any keyword) 
 for  array contents (something I've asked for in the past), how do we 
 write it?
 

const char[] bob; since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes. In D "const char[] bob", means that the contents of bob cannot be altered, the reference can't be changed, and you cannot slice out a chunk of bob unless you are slicing into another const char[]. Well it could mean that :) It could also mean anything else! Brad
Jun 02 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d7ntg7$2b5e$1 digitaldaemon.com...
 Regan Heath wrote:
 Ok, side question, assume we're going to use 'const' (or any keyword) for 
 array contents (something I've asked for in the past), how do we write 
 it?

const char[] bob; since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes. In D "const char[] bob", means that the contents of bob cannot be altered, the reference can't be changed, and you cannot slice out a chunk of bob unless you are slicing into another const char[]. Well it could mean that :) It could also mean anything else! Brad

Yep, only one: "the reference can't be changed" I think this is too strict. const char[] Dolli = "McArtur"; // fine /// mariage happens Dolli = "O'Connor"; // shoud be also fine. /// but attempt to break Dolli's "private parts" ((C) Booch) - to change /// value iself will be an erro:r Dolli[0] = '\0'; /// ERROR
Jun 02 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 2 Jun 2005 14:40:33 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 "Brad Beveridge" <brad somewhere.net> wrote in message
 news:d7ntg7$2b5e$1 digitaldaemon.com...
 Regan Heath wrote:
 Ok, side question, assume we're going to use 'const' (or any keyword)  
 for
 array contents (something I've asked for in the past), how do we write
 it?

const char[] bob; since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes. In D "const char[] bob", means that the contents of bob cannot be altered, the reference can't be changed, and you cannot slice out a chunk of bob unless you are slicing into another const char[]. Well it could mean that :) It could also mean anything else! Brad

Yep, only one: "the reference can't be changed" I think this is too strict. const char[] Dolli = "McArtur"; // fine /// mariage happens Dolli = "O'Connor"; // shoud be also fine. /// but attempt to break Dolli's "private parts" ((C) Booch) - to change /// value iself will be an erro:r Dolli[0] = '\0'; /// ERROR

I don't understand what you're saying. Which of these, if any, do you think we need to be able to do: 1 - have a constant reference, to non-constant data 2 - have a non-constant reference, to constant data 3 - have a constant reference, to constant data Bear in mind, when I say: "constant reference" I mean a char[] which cannot be assigned to, or it's length changed. eg. char[] foo = "bar"; foo = foo[1..3]; //illegal foo.length = foo.length + 10; //illegal foo[0] = 'a' //ok "constant data" I mean a char[] whose referenced data cannot be modified, eg. char[] foo = "bar"; foo = foo[1..3]; //ok foo.length = foo.length + 10; //ok foo[0] = 'a' //illegal Regan
Jun 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsrrjkrfx23k2f5 nrage.netwin.co.nz...
 On Thu, 2 Jun 2005 14:40:33 -0700, Andrew Fedoniouk 
 <news terrainformatica.com> wrote:
 "Brad Beveridge" <brad somewhere.net> wrote in message
 news:d7ntg7$2b5e$1 digitaldaemon.com...
 Regan Heath wrote:
 Ok, side question, assume we're going to use 'const' (or any keyword) 
 for
 array contents (something I've asked for in the past), how do we write
 it?

const char[] bob; since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes. In D "const char[] bob", means that the contents of bob cannot be altered, the reference can't be changed, and you cannot slice out a chunk of bob unless you are slicing into another const char[]. Well it could mean that :) It could also mean anything else! Brad

Yep, only one: "the reference can't be changed" I think this is too strict. const char[] Dolli = "McArtur"; // fine /// mariage happens Dolli = "O'Connor"; // shoud be also fine. /// but attempt to break Dolli's "private parts" ((C) Booch) - to change /// value iself will be an erro:r Dolli[0] = '\0'; /// ERROR

I don't understand what you're saying. Which of these, if any, do you think we need to be able to do: 1 - have a constant reference, to non-constant data 2 - have a non-constant reference, to constant data 3 - have a constant reference, to constant data

I mean #2. As #1 ( and #3 ) you can protect by exisiting mechanisms in D - you can always wrap references in something. Or you can choose to use in, inout, etc to passing references. But values they are referring to are not protected. There are no ways to implement #2 in D now . Makes sense?
 Bear in mind, when I say:

 "constant reference" I mean a char[] which cannot be assigned to, or it's 
 length changed. eg.

 char[] foo = "bar";
 foo = foo[1..3]; //illegal
 foo.length = foo.length + 10; //illegal
 foo[0] = 'a' //ok

 "constant data" I mean a char[] whose referenced data cannot be modified, 
 eg.

 char[] foo = "bar";
 foo = foo[1..3]; //ok
 foo.length = foo.length + 10; //ok
 foo[0] = 'a' //illegal

 Regan 

Jun 02 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 2 Jun 2005 15:16:00 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsrrjkrfx23k2f5 nrage.netwin.co.nz...
 I don't understand what you're saying. Which of these, if any, do you
 think we need to be able to do:

 1 - have a constant reference, to non-constant data
 2 - have a non-constant reference, to constant data
 3 - have a constant reference, to constant data

I mean #2. As #1 ( and #3 ) you can protect by exisiting mechanisms in D - you can always wrap references in something. Or you can choose to use in, inout, etc to passing references.

Yet 'in' does not prevent you from changing the parameter (a copy of the real reference) so you often get bugs where the programmer has desired change, implemented it, seen no errors from the compiler, and yet it fails. It would be nice to prevent this. It seems a simple change to have the compiler treat 'in' as 'const in' erroring on changes to the parameter itself.
 But values they are referring to are not protected.
 There are no ways to implement #2 in D now .

 Makes sense?

Perfect. I'm just not convinced we don't want all 3, yet. Regan
Jun 02 2005
prev sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:

 
 Yep, only one:
 "the reference can't be changed"
 I think this is too strict.
 
 const char[] Dolli = "McArtur"; // fine
 /// mariage happens
                    Dolli = "O'Connor"; // shoud be also fine.
 /// but attempt  to break Dolli's "private parts" ((C) Booch) - to change
 /// value iself will be an erro:r
                      Dolli[0] = '\0'; /// ERROR

Assume for a moment that "const" in D means the simplest thing - the reference cannot be changed and the data cannot be changed. Your example can be rewritten as: char[] Dolli = "McArtur"; const char[] safeDolli = Dolli; // do things that aren't allowed to change safeDolli // Dolli gets married Dolli = "O'Connor"; // safeDolli also is now "O'Connor" I am all for things being simple, and to me the simplest use of const is to make both the reference and the data immutable. Brad
Jun 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d7o3d9$2fqb$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 Yep, only one:
 "the reference can't be changed"
 I think this is too strict.

 const char[] Dolli = "McArtur"; // fine
 /// mariage happens
                    Dolli = "O'Connor"; // shoud be also fine.
 /// but attempt  to break Dolli's "private parts" ((C) Booch) - to change
 /// value iself will be an erro:r
                      Dolli[0] = '\0'; /// ERROR

Assume for a moment that "const" in D means the simplest thing - the reference cannot be changed and the data cannot be changed. Your example can be rewritten as: char[] Dolli = "McArtur"; const char[] safeDolli = Dolli; // do things that aren't allowed to change safeDolli // Dolli gets married Dolli = "O'Connor"; // safeDolli also is now "O'Connor" I am all for things being simple, and to me the simplest use of const is to make both the reference and the data immutable.

Take a look on this: for( const int* p = ...; p < end; ++p ) { } You can enumerate but you cannot change. Again, there are mechanisms for practical implementations of const references in D now e.g.: in, inout, out for parameters but there are no convenient and effective ways to protect reference values. Also if you have const ref on const data then you will not be able to do: foo( out const char[] ) which is rare but desireable use case. Andrew.
 Brad 

Jun 02 2005
parent Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:

 You can enumerate but you cannot change.
 
 Again, there are mechanisms for practical implementations of const 
 references in D now
 e.g.: in, inout, out for parameters
 
 but there are no convenient and effective ways to protect reference values.
 
 Also if you have const ref on const data then you will not be able to do:
 
 foo( out const char[]  ) which is rare but desireable use case.
 

Const reference + const data is too simplistic. Brad
Jun 02 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 02 Jun 2005 14:25:28 -0700, Brad Beveridge <brad somewhere.net>  
wrote:
 Regan Heath wrote:
 Ok, side question, assume we're going to use 'const' (or any keyword)  
 for  array contents (something I've asked for in the past), how do we  
 write it?

const char[] bob; since we aren't C++, I don't think that we should split hairs quite so much about where the const (or readonly) keyword goes.

I wasn't concerned so much with 'where' to type the keyword, but rather whether we need to be able to: 1 - have a constant reference, to non-constant data 2 - have a non-constant reference, to constant data 3 - have a constant reference, to constant data If we need all of them, then: "const char[] bob" - to me, means const ref (as it currently does in D) "char[const] bob" - (my fav suggestion so far) to me, means const data "const char[const] bob" - const ref, const data
 In D "const char[] bob", means that the contents of bob cannot be  
 altered, the reference can't be changed

So, you believe we only need option #3 above?
 , and you cannot slice out a chunk of bob unless you are slicing into  
 another const char[].

That would be illegal, surely? "another const char[]" is a constant reference, so you cannot change it - unless you were thinking we might lift this restriction at initialisation time, eg. const char[] abc = "abc"; const char[] bob = abc[0..2];
 Well it could mean that :)  It could also mean anything else!

Yeah, but we do have to make some temporary decisions in order to come to a temporary solution/idea in order to test it, before we can make any decisions. Regan
Jun 02 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Regan Heath wrote:

 1 - have a constant reference, to non-constant data
 2 - have a non-constant reference, to constant data
 3 - have a constant reference, to constant data
 
 If we need all of them, then:
 
 "const char[] bob" - to me, means const ref (as it currently does in D)
 "char[const] bob"  - (my fav suggestion so far) to me, means const data
 "const char[const] bob" - const ref, const data
 
 In D "const char[] bob", means that the contents of bob cannot be  
 altered, the reference can't be changed

So, you believe we only need option #3 above?

that we need #1. Sorry, I don't like "char[const] bob", simply because I feel it is too close to the AA syntax, eg, what is "char[const int] bob" going to do?
 
 , and you cannot slice out a chunk of bob unless you are slicing into  
 another const char[].

That would be illegal, surely? "another const char[]" is a constant reference, so you cannot change it - unless you were thinking we might lift this restriction at initialisation time, eg.

const char[] str = "This is a string"; void foo (const char[] f){...} void foo (char[] f){...} foo(str[0..4]); // slices and calls the foo(const char[]) func Brad
Jun 02 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 02 Jun 2005 15:07:42 -0700, Brad Beveridge <brad somewhere.net>  
wrote:
 Regan Heath wrote:

 1 - have a constant reference, to non-constant data
 2 - have a non-constant reference, to constant data
 3 - have a constant reference, to constant data
  If we need all of them, then:
  "const char[] bob" - to me, means const ref (as it currently does in D)
 "char[const] bob"  - (my fav suggestion so far) to me, means const data
 "const char[const] bob" - const ref, const data

 In D "const char[] bob", means that the contents of bob cannot be   
 altered, the reference can't be changed


that we need #1.

I cannot think of a specific use off the top of my head for #1, but, I would err on the side of caution and, presuming no reason against, make it possible.
 Sorry, I don't like "char[const] bob", simply because I feel it is too  
 close to the AA syntax, eg, what is "char[const int] bob" going to do?

Good question. Options are AFAICS: - illegal (raising the question of how to define constant data for an AA) - keys to AA are const (not sure what that might mean yet) I don't like either option myself.. So, exploring a syntax for enabling all 3 options, it looks like we have: #1 const char[] x #2 char[] const y; #3 const char[] const z; Presuming we need all 3, any problems with this syntax? If not, the next question this raises is how/when is 'y' initialised. I recall Matthew (I think - don't quote me) asking for a 'const' that would allow initialisation in a constructor (class, or static module).
 , and you cannot slice out a chunk of bob unless you are slicing into   
 another const char[].

"another const char[]" is a constant reference, so you cannot change it - unless you were thinking we might lift this restriction at initialisation time, eg.

const char[] str = "This is a string"; void foo (const char[] f){...} void foo (char[] f){...} foo(str[0..4]); // slices and calls the foo(const char[]) func

Ahh, that is in fact the same thing :) The slice is creating a new array, which is then initialised. So the rule might be "const arrays can be assigned only when they are initialised." The passing of the new const char[] into the function would follow normal rules from then on, as in, it's a const array so it's fine. Aside: AS non const char[] could be passed to this function, as non const can implicitly be promoted to const (but not vice-versa). Regan
Jun 02 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 03 Jun 2005 10:20:53 +1200, Regan Heath wrote:

[snip]

 So, exploring a syntax for enabling all 3 options, it looks like we have:
 
 #1 const char[] x
 #2 char[] const y;
 #3 const char[] const z;

I'm getting confused now; sorry. Are these three things mean ... #1 I can't modify the reference but I can modify the data. #2 I can modify the reference but I can't modify the data. #3 I can't modify the reference and I can't modify the data. -- Derek Melbourne, Australia 3/06/2005 8:53:25 AM
Jun 02 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 3 Jun 2005 08:55:55 +1000, Derek Parnell <derek psych.ward> wrote:
 On Fri, 03 Jun 2005 10:20:53 +1200, Regan Heath wrote:

 [snip]

 So, exploring a syntax for enabling all 3 options, it looks like we  
 have:

 #1 const char[] x
 #2 char[] const y;
 #3 const char[] const z;

I'm getting confused now; sorry. Are these three things mean ... #1 I can't modify the reference but I can modify the data. #2 I can modify the reference but I can't modify the data. #3 I can't modify the reference and I can't modify the data.

Yep. Assuming we need all 3 of them. Regan
Jun 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsrrmmoii23k2f5 nrage.netwin.co.nz...
 On Fri, 3 Jun 2005 08:55:55 +1000, Derek Parnell <derek psych.ward> wrote:
 On Fri, 03 Jun 2005 10:20:53 +1200, Regan Heath wrote:

 [snip]

 So, exploring a syntax for enabling all 3 options, it looks like we 
 have:

 #1 const char[] x
 #2 char[] const y;
 #3 const char[] const z;

I'm getting confused now; sorry. Are these three things mean ... #1 I can't modify the reference but I can modify the data. #2 I can modify the reference but I can't modify the data. #3 I can't modify the reference and I can't modify the data.

Yep. Assuming we need all 3 of them. Regan

Let's just have #1 I can't modify the reference but I can modify the data. It is quite enough. cases when you need #2 and #3 are very rare in C++ and always can be expressed by other methods . E.g. in D if you want to have non-changeable reference field in the class you can always do class Foo { private char[] _bar; const char[] bar() { return _bar; } } and this is it.
Jun 02 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:d7o4tf$2h13$1 digitaldaemon.com...
 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsrrmmoii23k2f5 nrage.netwin.co.nz...
 On Fri, 3 Jun 2005 08:55:55 +1000, Derek Parnell <derek psych.ward> 
 wrote:
 On Fri, 03 Jun 2005 10:20:53 +1200, Regan Heath wrote:

 [snip]

 So, exploring a syntax for enabling all 3 options, it looks like we 
 have:

 #1 const char[] x
 #2 char[] const y;
 #3 const char[] const z;

I'm getting confused now; sorry. Are these three things mean ... #1 I can't modify the reference but I can modify the data. #2 I can modify the reference but I can't modify the data. #3 I can't modify the reference and I can't modify the data.

Yep. Assuming we need all 3 of them. Regan

Let's just have #1 I can't modify the reference but I can modify the data.

Sorry, above shall be read as: #2 I can modify the reference but I can't modify the data.
 It is quite enough.

 cases when you need #2 and #3 are very rare in C++ and
 always can be expressed by other methods .

 E.g. in D if you want to have non-changeable reference field in the class
 you can always do

 class Foo
 {
    private char[] _bar;

    const char[] bar() { return _bar; }
 }

 and this is it.






 

Jun 02 2005
prev sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Regan Heath wrote:
 So, exploring a syntax for enabling all 3 options, it looks like we have:
 
 <snip />
 
 1 - have a constant reference, to non-constant data
 2 - have a non-constant reference, to constant data
 3 - have a constant reference, to constant data 

What about: #1 char const[] x; #2 const char[] y; #3 const char const[] z; It's consistent with the way D declarations are parsed by myBrain(tm) -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 02 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d7nra6$291a$1 digitaldaemon.com>, Andrew Fedoniouk says...
In user defined objects at least you can say 'protect'. Protect
some operations and functions from outside
This is compile time protection and not runtime! . In runtime you can
relatively easy get a pointer to private variable and change it outside.

Following logic that we cannot reach 100% protection we shall remove
this 'private', 'package' etc. What for they were introduced? They
are not 100% protecting!.

I was thinking more of something like this: # class C # { # int getVal() { return val; } # void setVal( int v ) { val = v; } # private: # int val; # } # # void doNotChangeC( C c ) # { # c.setVal( 5 ); # } 'val' might be protected, but it can still be altered by calling setVal. Since D has no concept of logical const-ness, there is no way to verify at compile-time that doNotChangeC actually did not change C. Though as I demonstrated in another thread, it is possible to verify this somewhat at compile-time using DBC.
You can do dynamic protection for UDO : you can naturally
implement:"in this particular state of object
this particular property is immutable, etc." Right?

Along those lines, I suppose this is an option: # class C # { # this() { mutable = true; } # # void setMutable( bit m ) { mutable = m; } # bit isMutable() { return mut; } # # int getVal() { return val; } # void setVal( int v ) # in { assert( isMutable() ); } # body { val = v; } # private: # int val; # bit mut; # } # # void doNotChangeC( C c ) # { # c.setVal( 5 ); # } # # c.setMutable( false ); # doNotChangeC( c ); # c.setMutable( true );
What we all want to have is simple:
"by using const for arrays and pointers we want to make
some methods of const types 'private' - not accessible". This is it.

True enough. And this shouldn't be very hard to do. Sean
Jun 02 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <d7nra6$291a$1 digitaldaemon.com>, Andrew Fedoniouk says...
What we all want to have is simple:
"by using const for arrays and pointers we want to make
some methods of const types 'private' - not accessible". This is it.

Actually, this would work for classes as well. Sean
Jun 02 2005
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.this-is.spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kris schrieb am Thu, 02 Jun 2005 00:15:46 -0700:
 Thomas Kuehne wrote:
 If the array content is by default immutable - that is, once an element
 is set it can't be changed - the "mutable" attribute could be used to
 allow the editing of array elements. 

Now there's a different idea. Talk about CoW enforcement :-)
 In difference to the current system
 the compiler could only allow those cases where it can _prove_ that the
 array is mutable. What happens if you store pointers/object
 references in the array?!

Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas?

This isn't sufficent. class C{ <immutable> int i; } void bugger(){ C c = new C; c.i = 2; // **ok** <mutable> int* i = &c.i; *i = 1; // ***bug** }
 Aliases upon the array still have to go through the 
 same type-matching procedure; Yes?

In the sense that "<mutable> t" and "<immutable> t" are two distinct types.
 If you cast an immutable type to a mutable type, then all bets are off; 
 just as they are with *cast(void *)0 = 0;

How about enforcing that immutable types can only be casted to immutable types? <immutable> type[] a; <immutable> void* b = cast(<immutable> void*) a; // legal, the target is immutable <mutable> void* c = cast(<mutable> void*) a; // illegal, the target is mutable. This isn't sufficent. Let's rewrite the sample. class C{ <immutable> int i; } void bugger2(){ C c = new C; c.i = 2; // **ok** <immutable> size_t ptrI = cast(<immutabe> size_t)(cast(<immutable> void*)) &c.i); <mutable> size_t ptrM = ptrI; <mutable> void* v = cast(<mutable> void*) ptrM; <mutable> int* i = cast(<mutable> int*) v; *i = 1; // **bug, but legal if mutability is a plain attribute** }
 In addition this has some negative impact for mixed closed-open
 source projects as the compiler would have to treat all arrays comming
 from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?

This would reduce the the protection to a suggestion. As can be seen: a simple <mutable> attribute isn't a sufficent protection. The compiler would have to do a quite extensive flow analysis to provide even very limited mutable access. If the "default <immutable>" is limited to arrays, how deep would the array be protected? What about pointers as array elements? class D{ <mutable> int i; } <immutable> D[] o; o.length=1; o[0]= new D; // **ok** o[0]= new D; // **bug** o[0].i = 1; // legal or illegal? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCnt1K3w+/yD4P9tIRAuebAKCAgW0XGeL7/5QkZ+GmZnwefI+hzQCfdv6B isJeMx63fCvqJgoxpQhzKAk= =Q3ak -----END PGP SIGNATURE-----
Jun 02 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.this-is.spam.cn> wrote in message 
news:a333n2-t84.ln1 lnews.kuehne.cn...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 kris schrieb am Thu, 02 Jun 2005 00:15:46 -0700:
 Thomas Kuehne wrote:
 If the array content is by default immutable - that is, once an element
 is set it can't be changed - the "mutable" attribute could be used to
 allow the editing of array elements.

Now there's a different idea. Talk about CoW enforcement :-)
 In difference to the current system
 the compiler could only allow those cases where it can _prove_ that the
 array is mutable. What happens if you store pointers/object
 references in the array?!

Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas?

This isn't sufficent. class C{ <immutable> int i; } void bugger(){ C c = new C; c.i = 2; // **ok** <mutable> int* i = &c.i; *i = 1; // ***bug** }
 Aliases upon the array still have to go through the
 same type-matching procedure; Yes?

In the sense that "<mutable> t" and "<immutable> t" are two distinct types.
 If you cast an immutable type to a mutable type, then all bets are off;
 just as they are with *cast(void *)0 = 0;

How about enforcing that immutable types can only be casted to immutable types? <immutable> type[] a; <immutable> void* b = cast(<immutable> void*) a; // legal, the target is immutable <mutable> void* c = cast(<mutable> void*) a; // illegal, the target is mutable. This isn't sufficent. Let's rewrite the sample. class C{ <immutable> int i; } void bugger2(){ C c = new C; c.i = 2; // **ok**

 <immutable> size_t ptrI = cast(<immutabe> size_t)(cast(<immutable> void*)) 
 &c.i);
 <mutable> size_t ptrM = ptrI;
 <mutable> void* v = cast(<mutable> void*) ptrM;
 <mutable> int* i = cast(<mutable> int*) v;
 *i = 1; // **bug, but legal if mutability is a plain attribute**
 }

class C { const int i = 20; // works now and perfectly. it is a compile time // constant and such variable may not have even // location in runtime. } The only one: <immutable> int* ptrI = &someintvar; *ptrI = 20 ; // here compiler must generate error - is not an l-value. And this is it. Enough for most cases. Casting, slicing and dicing to remove constness shall be also possible for masochistic use cases. We shall help good people instead of fighting with bad ones. Only in this case we will have a chance to see transformation of bad guys into good guys. ( Pure Canadian statement :-) Andrew.
 In addition this has some negative impact for mixed closed-open
 source projects as the compiler would have to treat all arrays comming
 from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?

This would reduce the the protection to a suggestion. As can be seen: a simple <mutable> attribute isn't a sufficent protection. The compiler would have to do a quite extensive flow analysis to provide even very limited mutable access. If the "default <immutable>" is limited to arrays, how deep would the array be protected? What about pointers as array elements? class D{ <mutable> int i; } <immutable> D[] o; o.length=1; o[0]= new D; // **ok** o[0]= new D; // **bug** o[0].i = 1; // legal or illegal? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCnt1K3w+/yD4P9tIRAuebAKCAgW0XGeL7/5QkZ+GmZnwefI+hzQCfdv6B isJeMx63fCvqJgoxpQhzKAk= =Q3ak -----END PGP SIGNATURE-----

Jun 02 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.this-is.spam.cn> wrote in message 
news:hsr2n2-ic3.ln1 lnews.kuehne.cn...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Andrew Fedoniouk schrieb am Wed, 1 Jun 2005 17:55:04 -0700:
 ....for having a facility in the
 language to say "this thing shouldn't change value".

exactly. It is enough to have const T[] and const T* as distinct types from just T[] and T* . const T[] type has no opIndexAssign, length(int) and cannot be lvalue at all. Simple as 1-2-3. I really don't understand what is the motivation to do not have them. String literals are const char[] by definition.

Sadly it's not that simple. The content of the string literals are known at compile time and can thus be placed in an OS-protected memory area. If the array content is mutable by default, the const attribute for arrays is a mere suggestion. Do a bit of pointer math or store arrays as elements in other arrays and the const attribute loses it's effect. If the array content is by default immutable - that is, once an element is set it can't be changed - the "mutable" attribute could be used to allow the editing of array element. In difference to the current system the compiler could only allow those cases where it can _prove_ that the array is mutable. What happens if you store pointers/object references in the array?! In addition this has some negative impact for mixed closed-open source projects as the compiler would have to treat all arrays comming from the closed source part as immutable. The third way is to allow only assigning and not changeing any var. It's neat but pointer math gets in the way again. Thomas

Thomas, I am not proposing here any flags changeable in runtime or existing there. I was thinking aloud before about them but not in this message. I did tests already with flags - indeed they do not work in some cases. Let's forget about them and focus on just a const type modifier const T[] and T[] has exactly the same binary layout in runtime. The only difference is on compiler level (as in C++). Lets imagine that we have const char[] t = some_other_array; uint find( const char[] where, const char[] what) { ..... } uint replace( char[] where, const char[] from, const char[] to) { ..... } find(t, "hello"); // fine replace( t, "c++", "d" ); // bang! compile time error : cannot change const value. const type modifier is not to much complicated currently it is supported for scalars. We need to extend it to arrays and pointers with slightly modified meaning. Close to what C++ has. But not exactly. I thing we don't need to go to const methods or so they are too shaky even in C++. Just a type modifer for POD types (as currently) and for arrays and pointers which are generally speaking for D are also POD types. This is it. Not a rocket science. Andrew.
Jun 02 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.this-is.spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:38:54 -0700:
<snip>
 Thomas, I am not proposing here any flags changeable in runtime or existing 
 there.
 I was thinking aloud before about them but not in this message.
 I did tests already with flags - indeed they do not work in some cases.

The only way I am aware of to enforce const at runtime could be compared to Java's String pool...
 Let's forget about them and focus on just a const type modifier

 const T[] and T[] has exactly the same binary layout in runtime.

 The only difference is on compiler level (as in C++).
 Lets imagine that we have

 const char[] t = some_other_array;

 uint find( const char[] where, const char[] what)
 {
 .....
 }

 uint replace( char[] where, const char[] from, const char[] to)
 {
 .....
 }

 find(t, "hello"); // fine
 replace( t, "c++", "d" ); // bang! compile time error : cannot change const 
 value.

 const type modifier is not to much complicated
 currently it is supported for scalars. We need to extend it
 to arrays and pointers with slightly modified meaning.
 Close to what C++ has. But not exactly.

Now that is the tricky part. ;) What would be the const rules for arrays and pointers/references? How/When would those rules be checked and/or enfored? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCnuIR3w+/yD4P9tIRApaoAKCfmszRUHdzY+D1ZqBE28fWkQ1cBQCcDouw Jjmq2a1Wkah6dhYchFArC+g= =VHXo -----END PGP SIGNATURE-----
Jun 02 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.this-is.spam.cn> wrote in message 
news:h943n2-na4.ln1 lnews.kuehne.cn...
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:38:54 -0700:
 <snip>
 Thomas, I am not proposing here any flags changeable in runtime or 
 existing
 there.
 I was thinking aloud before about them but not in this message.
 I did tests already with flags - indeed they do not work in some cases.

The only way I am aware of to enforce const at runtime could be compared to Java's String pool...
 Let's forget about them and focus on just a const type modifier

 const T[] and T[] has exactly the same binary layout in runtime.

 The only difference is on compiler level (as in C++).
 Lets imagine that we have

 const char[] t = some_other_array;

 uint find( const char[] where, const char[] what)
 {
 .....
 }

 uint replace( char[] where, const char[] from, const char[] to)
 {
 .....
 }

 find(t, "hello"); // fine
 replace( t, "c++", "d" ); // bang! compile time error : cannot change 
 const
 value.

 const type modifier is not to much complicated
 currently it is supported for scalars. We need to extend it
 to arrays and pointers with slightly modified meaning.
 Close to what C++ has. But not exactly.

Now that is the tricky part. ;) What would be the const rules for arrays and pointers/references? How/When would those rules be checked and/or enfored?

When: In compile time. How: by generating compile time error. How be checked? Exactly as right now. Imagine that const char[] is just a typedefed char[]. Can compiler check casting problems of typedefed types now? Yes. This is it. Don't need anything more here. The only one thing: string literals are const char arrays by their nature and definition. See I am clearly expressing my intentions - defining contracts on parameters: -------------------------------- foo(char[] ms) foo(const char[] ims) -------------------------------- const char[] s1 = url.hostname; char[] s2 = url.hostname; // compile time error - cast to non-const but this should be possible too (my guess): char[] s2 = cast(char[]) url.hostname; // const is recomendation, not more! better to have constcast() for such cases but we can live without that. Andrew.
Jun 02 2005
prev sibling parent Eugene Pelekhay <pelekhay gmail.com> writes:
Walter wrote:
 "Eugene Pelekhay" <pelekhay gmail.com> wrote in message
 news:d7hfuh$1ejl$1 digitaldaemon.com...
 
May be I'm dummy, but I don't see in this example why this other
languages must copy it 10 times. For my implementation of reference
counted string in my C++ project, copy will be performed also 0 times.
And if there is more then 1 reference to instance exsits it's only one
copy operation will be performed. I see only one advantage in current
implementation of string - not need to check or increment/decrement
reference counter, but instead of this string duplication is required

You're right that you can avoid excessive copying by doing ref counting. Reference counting carries with it other penalties - storage must be allocated for the ref count, every copy increments the count, and every reference that goes out of scope must decrement the count. Add in exception handling, and the price is high (although C++'s mechanisms hide that price from you).

others it is a reasonable price to be sure that my application will not freeze for some time to perform garbage collection. Another thing which is significant for me it is destructor calls from garbage collector. I don't care when memory will be released, but i won't be sure that destructor is called as soon as all references to object are gone. If last is not guaranteed then my code will look like in Java, with enormous amount of *try finally* blocks with forced call to cleanup methods. IMHO to be successful D language must reduce development cycle and this is only reason big bosses will understand.
 
 Ref counting would make it impractical to do D's array slices.

in C is also very nice feature I use quite often (in binary exchange protocol between my devices). This is all about constness and CoW and without it I only see hardly findable errors in code (if code is not just simple one page test.d). Don't think I'm against this nice feature.
 
 Furthermore, in the presence of garbage collection, layering on top a
 reference counting mechanism probably means you'll want to ditch the gc and
 go with a full ref counting architecture for every object. In my experience,
 such is slower than using mark/sweep gc.
  

of them: 1) real time systems programming (gc is not acceptable if it is not deterministic) 2) game with extensive usage of latest hardware (freezing for for some time in unpredictable moments. Who will play such game?) 3) embedded systems (resources in most cases are limited, so You need to utilize all resources You have) 4) scientific calculations As You see high performance requirements often go hand in hand with deterministic execution time, which is not guaranteed in the case of GC or at least existing implementation. PS: For whom who see this post and thinks he wont to rip D language, I'm not. I'm praying last ~5 years for success of D and I'm here to bring all my experience to make it successful. I'm not starting flame war here 'cause I really like the language
Jun 02 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 00:46:35 -0700, Walter wrote:


[snip]
 
 A number of languages use the immutable string idiom, and its corollary
 "always implicitly copy the string when writing to it". They all share
 another common characteristic - they're slow, and they're slow in a manner
 that is *not fixable*. And they're not just slower by a factor, many
 algorithms run *exponentially* slower because of the copying.
 
 D must be fast, and the only way to be fast with strings (and arrays) is to
 not have the language implicitly copy them, but to allow the programmer the
 flexibility to copy or not copy. To know when to copy, use the Copy On Write
 principle (COW). That is, if you're not *sure* you've got the only copy of a
 string, .dup it before modifying it.

I think there are two distinct aspects that are sometimes being confused or mingled. One is the idea that the compiler must *prevent* read-only variables from being modified, and the other is that the compiler must *report* when it detects (during compilation) code that attempts (i.e would attempt at run time) to write to a read-only item. The first idea is the subject of the CoW proposition above; that D takes the position that the compiler is not responsible for this but that the coder is. But I still think that we haven't heard Walter's final position on the second idea. So Walter, what if we could indicate which items we would like to be read-only and if the compiler detects code which is writing to them, it issues an error message? I know this would not cause these items to be read-only, but it may help prevent silly coding errors such as the other silly coding errors you've already added protection for in D. -- Derek Parnell Melbourne, Australia 31/05/2005 11:02:10 PM
May 31 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:djl0rio88ubd$.1v38dy1thwnze.dlg 40tude.net...
 On Tue, 31 May 2005 00:46:35 -0700, Walter wrote:


 [snip]

 A number of languages use the immutable string idiom, and its corollary
 "always implicitly copy the string when writing to it". They all share
 another common characteristic - they're slow, and they're slow in a 
 manner
 that is *not fixable*. And they're not just slower by a factor, many
 algorithms run *exponentially* slower because of the copying.

 D must be fast, and the only way to be fast with strings (and arrays) is 
 to
 not have the language implicitly copy them, but to allow the programmer 
 the
 flexibility to copy or not copy. To know when to copy, use the Copy On 
 Write
 principle (COW). That is, if you're not *sure* you've got the only copy 
 of a
 string, .dup it before modifying it.

I think there are two distinct aspects that are sometimes being confused or mingled. One is the idea that the compiler must *prevent* read-only variables from being modified, and the other is that the compiler must *report* when it detects (during compilation) code that attempts (i.e would attempt at run time) to write to a read-only item. The first idea is the subject of the CoW proposition above; that D takes the position that the compiler is not responsible for this but that the coder is. But I still think that we haven't heard Walter's final position on the second idea. So Walter, what if we could indicate which items we would like to be read-only and if the compiler detects code which is writing to them, it issues an error message? I know this would not cause these items to be read-only, but it may help prevent silly coding errors such as the other silly coding errors you've already added protection for in D.

Derek, this is exactly what const does in C++. It does one more thing in fact. char[] and const char[] are distinct types so you can do: void foo( char[] s) { ... } void foo( const char[] s) { ... } This also allows you to clear show your intentions and so on.
 -- 
 Derek Parnell
 Melbourne, Australia
 31/05/2005 11:02:10 PM 

May 31 2005
prev sibling parent Jan-Eric Duden <jeduden whisset.com> writes:
Walter wrote:
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d7gtvf$qs0$1 digitaldaemon.com...
 
java.lang.String class has a) methods b) String owns buffer - it controls
buffer.

In D is possible:
int[char[]] map;
char[] s = "something";
map[s] = 1;
s[0] = '?'; // I have no idea what result will be. sure not good.

And you can bump into such problem quite easily in D. I personally
did many times. And too hard to find source sometimes.

In Java such collision is not possible in principle: String is final and
immutable.

A number of languages use the immutable string idiom, and its corollary "always implicitly copy the string when writing to it". They all share another common characteristic - they're slow, and they're slow in a manner that is *not fixable*. And they're not just slower by a factor, many algorithms run *exponentially* slower because of the copying. D must be fast, and the only way to be fast with strings (and arrays) is to not have the language implicitly copy them, but to allow the programmer the flexibility to copy or not copy. To know when to copy, use the Copy On Write principle (COW). That is, if you're not *sure* you've got the only copy of a string, .dup it before modifying it. So why isn't that just as bad as the languages that implicitly copy on write? The answer is that often, you know that you are the sole owner, such as: char[] s = new char[10]; for (i = 0; i < 10; i++) s[i] = 'c'; Those other languages are doomed to make 10 copies of s. The D programmer needs to make 0 copies. As to your example above, when you pass a reference to a string to an associative array, then you aren't the sole owner of that string anymore. Don't change it. .dup it.

The string class would implement immutable strings without COW. That's what you need in 99% of all applications. Applications that are an exeception to the rule should use char arrays with dup if needed. That's a win win situation - and no performance hit. The only thing that people need to get used to is that "normal" strings are immutable, but that's not really hard to accept. Cheers, Jan
Jun 03 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 30 May 2005 22:50:29 -0700, Andrew Fedoniouk wrote:


[snip]

 class Url
 {
    char[] _hostname;
    ...
    char[] hostname() { return _hostname.dup; } // Doh!
 }
 
 if( url.hostname == "terrainformatica.com" )
 // 32 bytes less in memory, just to compare it!
   ....
 
 Ideal from many points of view would be a solution with const
 
 class Url {
   char[] _hostname;
 
   const char[] hostname() { return _hostname; } // Yep! this exactly what we 
 need.
 
 }
 

Given the current semantics of D, could a workaround be that we give the caller the choice, thus making them take explicit responsibility for their usage. class Url { private char[] _hostname; ... char[] hostname_unsafe() { return _hostname; } char[] hostname() { return _hostname.dup; } } char[] a; char[] b; a = url.hostname; // Gets a string with safety b = url.hostname_unsafe; // Gets a string without safety <offtopic> Of course, if we had return type function matching this would be a whole lot easier and legible. typedef char[] safe_string; class Url { private char[] _hostname; ... char[] hostname() { return _hostname; } safe_string hostname() { return cast(safe_string)_hostname.dup; } } safe_string a; char[] b; a = url.hostname; // Gets a string with safety b = url.hostname; // Gets a string without safety But I should wake up from this dream now ... -) </offtopic> -- Derek Melbourne, Australia 2/06/2005 10:12:16 AM
Jun 01 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:lktv44kgbu1j.1tp9nxs3uqvmr.dlg 40tude.net...
 On Mon, 30 May 2005 22:50:29 -0700, Andrew Fedoniouk wrote:


 [snip]

 class Url
 {
    char[] _hostname;
    ...
    char[] hostname() { return _hostname.dup; } // Doh!
 }

 if( url.hostname == "terrainformatica.com" )
 // 32 bytes less in memory, just to compare it!
   ....

 Ideal from many points of view would be a solution with const

 class Url {
   char[] _hostname;

   const char[] hostname() { return _hostname; } // Yep! this exactly what 
 we
 need.

 }

Given the current semantics of D, could a workaround be that we give the caller the choice, thus making them take explicit responsibility for their usage. class Url { private char[] _hostname; ... char[] hostname_unsafe() { return _hostname; } char[] hostname() { return _hostname.dup; } }

 char[] a;
 char[] b;
 a = url.hostname; // Gets a string with safety
 b = url.hostname_unsafe; // Gets a string without safety

Derek it is not a choice. Nobody in good mental health will do such double implementation. Easier to switch to C++. const char[] hostname() { return _hostname; } const char[] hostname = url.hostname; const char[] level1 = hostname[$-3..$]; char[] level2 = hostname[0...$-3]; // bang! We do have const for int, double, etc. Why not for arrays and pointers - they are also primitive types builtin in language, right? Yes this is a bit different in implementation but for the sake of consistency? Jees, I am loosing big project for D and Harmonia.... Team is voting for C++. Only const! :( Simply do not have moral rights to insist further. That was really good chance to feed Harmonia....
 <offtopic>
 Of course, if we had return type function matching this would be a whole
 lot easier and legible.

 typedef char[] safe_string;

 class Url
 {
    private char[] _hostname;
    ...
    char[] hostname()      { return _hostname; }
    safe_string hostname() { return cast(safe_string)_hostname.dup; }
 }

 safe_string a;
 char[] b;
 a = url.hostname; // Gets a string with safety
 b = url.hostname; // Gets a string without safety

 But I should wake up from this dream now ... -)
 </offtopic>

 -- 
 Derek
 Melbourne, Australia
 2/06/2005 10:12:16 AM 

Jun 01 2005