www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - (OT) Slashdot on the future of C++

reply Nick <Nick_member pathlink.com> writes:
Slashdot just ran a discussion on the future of C++:
http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

Naturally a lot of people came out to vent their misgivings about the language.
Here's some of the stuff I found complaints about:

- No garbage collection
- Member function pointers (ie. no delegates)
- Lack of "abstract" and "typeof" keywords
- No modules, and the namespace system is a hack to try to fix this
- Memory safety and language safety in general
- Too many complicated and unecessary language rules

I think I might know a language that fixes, or improves on, all these :D

Nick
Jul 11 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message 
news:daug61$1tn6$1 digitaldaemon.com...
 Slashdot just ran a discussion on the future of C++:
 http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

 Naturally a lot of people came out to vent their misgivings about the 
 language.
 Here's some of the stuff I found complaints about:

 - No garbage collection
 - Member function pointers (ie. no delegates)
 - Lack of "abstract" and "typeof" keywords
 - No modules, and the namespace system is a hack to try to fix this
 - Memory safety and language safety in general
 - Too many complicated and unecessary language rules

 I think I might know a language that fixes, or improves on, all these :D

Just to be precise: this set of features describes Java/C# and not D. E.g. memory safety is available only in managed environments so far. Andrew.
Jul 11 2005
parent reply AJG <AJG_member pathlink.com> writes:
Also for the record, in C# it is inherently possible to:
1) Call native, unsafe code directly (P/Invoke && DllImport).
2) Use raw pointers and arithmetic (IntPtr).

So it doesn't have complete memory safety either. I don't know about Java.
There's probably a per-platform way of doing that too, if you really wanted to.

I think it's "safe" to say that D has relatively safe memory management, in most
cases. Granted, it's still possible to blow your whole leg off, but you can do
that everywhere, if you set your mind to it ;)

--AJG.

"Nick" <Nick_member pathlink.com> wrote in message 
news:daug61$1tn6$1 digitaldaemon.com...
 Slashdot just ran a discussion on the future of C++:
 http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

 Naturally a lot of people came out to vent their misgivings about the 
 language.
 Here's some of the stuff I found complaints about:

 - No garbage collection
 - Member function pointers (ie. no delegates)
 - Lack of "abstract" and "typeof" keywords
 - No modules, and the namespace system is a hack to try to fix this
 - Memory safety and language safety in general
 - Too many complicated and unecessary language rules

 I think I might know a language that fixes, or improves on, all these :D

Just to be precise: this set of features describes Java/C# and not D. E.g. memory safety is available only in managed environments so far. Andrew.

Jul 11 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:daum5v$22uh$1 digitaldaemon.com...
 Also for the record, in C# it is inherently possible to:
 1) Call native, unsafe code directly (P/Invoke && DllImport).
 2) Use raw pointers and arithmetic (IntPtr).

 So it doesn't have complete memory safety either. I don't know about Java.
 There's probably a per-platform way of doing that too, if you really 
 wanted to.

 I think it's "safe" to say that D has relatively safe memory management, 
 in most
 cases. Granted, it's still possible to blow your whole leg off, but you 
 can do
 that everywhere, if you set your mind to it ;)

Your answer just proves that Java/C# has builtin memory safety but in some exceptional cases like:
 1) Call native, unsafe code directly (P/Invoke && DllImport).
 2) Use raw pointers and arithmetic (IntPtr).

(or using JNI calls in Java) you can break that builtin memory safety rules. I am not against D. I am just trying to be impartial. Any memory safety has its own price. Pretty frequently (at least in my cases) this mandatory price is not acceptable. That's it.
 --AJG.

"Nick" <Nick_member pathlink.com> wrote in message
news:daug61$1tn6$1 digitaldaemon.com...
 Slashdot just ran a discussion on the future of C++:
 http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

 Naturally a lot of people came out to vent their misgivings about the
 language.
 Here's some of the stuff I found complaints about:

 - No garbage collection
 - Member function pointers (ie. no delegates)
 - Lack of "abstract" and "typeof" keywords
 - No modules, and the namespace system is a hack to try to fix this
 - Memory safety and language safety in general
 - Too many complicated and unecessary language rules

 I think I might know a language that fixes, or improves on, all these :D

Just to be precise: this set of features describes Java/C# and not D. E.g. memory safety is available only in managed environments so far. Andrew.


Jul 11 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:dauv5e$2b1f$1 digitaldaemon.com...
 Any memory safety has its own price. Pretty frequently
 (at least in my cases) this mandatory price is not acceptable.
 That's it.

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

True. D doesn't eliminate the potential for memory corruption. What it does try to do, however, is reduce the probability of them by 1) providing less error-prone ways to get the functionality, such as using out and inout parameters rather than pointers and 2) adding runtime checks such as array bounds overflow checking and contract programming.

True. Except one: I just don't understand - how contract programming helps to increase memory safety. Currently D's DbC features allows you only check for NULL. Did I miss something in principle? "const", as a part of DbC, will definitely help more here. This is true.
Jul 12 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:db12la$17to$1 digitaldaemon.com...
 Except one: I just don't understand - how contract programming
 helps to increase memory safety.
 Currently D's DbC features allows you only check for NULL.

 Did I miss something in principle?

You can write the contracts to test for anything you want, not just NULL.
Jul 14 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:db63at$31dn$2 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:db12la$17to$1 digitaldaemon.com...
 Except one: I just don't understand - how contract programming
 helps to increase memory safety.
 Currently D's DbC features allows you only check for NULL.

 Did I miss something in principle?

You can write the contracts to test for anything you want, not just NULL.

Walter, it was all about memory safety and DbC. The only one test available for DbC (runtime DbC test, sic!) now is to test on NULL pointer. What else I can do to verify is it safe to write into this memory or not? Preferably in compile/design time. Andrew.
Jul 14 2005
parent "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:db649h$ob$1 digitaldaemon.com...
 Walter, it was all about memory safety and DbC.

I understand that.
 The only one test available for DbC (runtime DbC test, sic!) now is to

 on NULL pointer.

No, you can test for anything you can express in code. You can, for example, run a consistency check on a free list.
Jul 14 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Nick wrote:

 Slashdot just ran a discussion on the future of C++:
 http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

Actually they linked to an article of Bjarne about the future "C++0x"... (http://www.research.att.com/~bs/rules.pdf) I think there was a major difference between C++ and D almost at once, he wants to use the standard library while Walter wants to build it in: See "Rationale for Builtins" http://www.digitalmars.com/d/builtin.html --anders PS. I must confess I stopped reading somewhere at "C++0x will be almost 100-percent compatible with the existing Standard C++."... Same old ?
Jul 11 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:daunef$245r$1 digitaldaemon.com...
 I think there was a major difference between C++ and D almost at once,
 he wants to use the standard library while Walter wants to build it in:

 See "Rationale for Builtins" http://www.digitalmars.com/d/builtin.html

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

 See "Rationale for Builtins" http://www.digitalmars.com/d/builtin.html

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

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

Perhaps allowing Java terminology to define things isn't exactly fair. Many languages have had mutable strings (often, admittedly, by accident). Being mutable DOESN'T mean it isn't a string, it means it's not a Java String class, which nobody ever claimed it was. OTOH, a char[] isn't really a full fledged string, even with slicing. It's quite close, but not quite there. To get to String status you need to do something like importing std.string. But char[]'s really build in most features that need to be built in. Basically what should be added is some special magic so that if you import std.string, the std.string methods are all available as methods of variables/literals of type char[], so you would be able to do things like: j = "This is a test".rfind("is"); Even that isn't quite perfect. It would be nice to be able to do things like: s = "This is a test"; s.removechars("/is/"); // N.B.: Note the /'s this should mean // "interpret this as a pattern" Notice that the syntax has changed a bit from the current usage as this is now a method invocation rather than a function call. Also notice that this function would need to realize that it's arguments couldn't be const's. (A standard requirement, but another change from the current approach.) This might even be a reasonable approach, given that already char[]'s need to be converted to Stringz if one wants to use them in C. OTTH (or is this the fourth hand), perhaps this extension is better handled with a library. I don't even think it would be a hard one to write...the sole problem is method invocation off of string literals, to which I see no solution without direct intervention in the compiler.
Jul 13 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message 
news:db3s4k$tn9$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:
...
 Walter, sorry for beating this horse again but D does not yet have 
 strings either.
 Very convenient character arrays and slices - yes. But strings (as value 
 type) -
 not yet. String  is an immutable value and has no analogues in D.
 D's char[] is just a StringBuffer/StringBuilder. And this is main concern 
 for Java/C#
 enterprise developers. They just get used to such String robustness.
 BTW: modern java.lang.String implementation is capable to represent 
 string slices too.

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

String is an immutable value. Consider this: char [] key = "one"; int [char[] ] map; map[ key ] = 1; key[0] = 'a'; This will ruin your map, isn't it?
 Perhaps allowing Java terminology to define things isn't exactly fair.

I am using String not only as Java string but as entity describing "immutable string value": In C you have char* and const char* In C++ you have std::string and const std::string In Java you have String and StringBuffer In C# - String and StringBuilder In Delphi you also able to use const Strings (limitied cases)
 OTOH, a char[] isn't really a full fledged string, even with slicing. 
 It's quite close, but not quite there.  To get to String status you need 
 to do something like importing std.string. But char[]'s really build in 
 most features that need to be built in.  Basically what should be added is 
 some special magic so that if you import std.string, the std.string 
 methods are all available as methods of variables/literals of type char[], 
 so you would be able to do things like:
 j = "This is a test".rfind("is");

Try to write it: "This is a test".rfind("is"); It should run flawlessly. By some accident D allows to do such trick with array parameters.
 Even that isn't quite perfect.  It would be nice to be able to do things 
 like:
 s = "This is a test";
 s.removechars("/is/");  //   N.B.:  Note the /'s this should mean
                         //       "interpret this as a pattern"
 Notice that the syntax has changed a bit from the current usage as this is 
 now a method invocation rather than a function call.

As I mentioned if removechars is declared as void removechars(char[],char[]) then you can call it as s.removechars("/is/"); I wouldn't rely on this behavior though as it is not specified - "D's hidden treasure"
 Also notice that this function would need to realize that it's arguments 
 couldn't be const's. (A standard requirement, but another change from the 
 current approach.)

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

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

BTW: Compiler should assign char[]# ( or const char[] ) type to string literals as they are immutable by nature.
Jul 13 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:

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

And in D you have char[] and char[] Some people find that confusing :-) Seriously, D does have two types of strings too - it is "just" that the compiler doesn't enforce any difference between them, so one just has the Gentlemen's Agreement to honor the C-o-w*. (*See http://en.wikipedia.org/wiki/Copy-on-write, or Phobos doc) And just like you (and several others) I think it would be very nice if there was some addition to the language to make it able to separate between them, and enforce the (default) immutability. But it still needs some nice new D syntax... Maybe: "char [inout]", or "mutable char[]" ? --anders PS. Inspired by NSString/NSMutableString and NSArray/NSMutableArray, and their other similar friends, from NeXTSTEP and Objective-C : http://www.gnustep.org/resources/OpenStepSpec/FoundationKit/Classes/NSString.html But "mutable" does have the issues with the local variables raised by Walter, basically them being something of a pain to add there ? digitalmars.D/26096 Still seems like the lesser evil to me, but that's up to Walter...
Jul 13 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Anders F Björklund wrote:

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

Actually, the Wikipedia entry on COW disagrees with D's take on COW. From Wikipedia "This fiction can be maintained until a caller tries to modify its "copy" of the resource, at which point a true private copy is created to prevent the changes becoming visible to everyone else. All of this happens transparently to the callers." The key thing being "all this happens transparently to callers", in D's take on COW the callers must explicitly manage their own COW. Now, as a thought experiment imagine that COW in D was transparent. Imagine that when you returned an array in D it acted just as it does now, except that when you wrote to it, the D compiler/runtime automatically duped it and you wrote to your own array. Would this make a difference to how we programed? Certainly it would make the idea that we needed immutable strings go away (all arrays are effectively immutable). Now of course we would need some mechanism for actually returning a modifiable array. Thoughts? Brad
Jul 13 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Brad Beveridge wrote:

 The key thing being "all this happens transparently to callers", in D's 
 take on COW the callers must explicitly manage their own COW.

Right, it's not that transparent for the routine that modifies a string. (i.e. if you write to it, you need to .dup it - or similar - yourself)
 Now, as a thought experiment imagine that COW in D was transparent. 
 Imagine that when you returned an array in D it acted just as it does 
 now, except that when you wrote to it, the D compiler/runtime 
 automatically duped it and you wrote to your own array.  Would this make 
 a difference to how we programed?  Certainly it would make the idea that 
 we needed immutable strings go away (all arrays are effectively 
 immutable).  Now of course we would need some mechanism for actually 
 returning a modifiable array.  Thoughts?

It would be nice, but is hard to implement outside the MMU sphere... See this old post D/27605 --anders
Jul 13 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Anders F Björklund wrote:
 Brad Beveridge wrote:
 

 
 It would be nice, but is hard to implement outside the MMU sphere...
 See this old post D/27605
 
 --anders

Any particular reason that we need to move outside of the MMU sphere? About the only one that I can think of is the fact that MMUs work with fixed sized pages, so you will loose some memory due to page wastage. I was thinking it should be possible to do something like char[] dynamic = "Thlkjdhlaksdjfj"; char[] locked = dynamic.MMUlock; locked.MMUunlock; MMUlock dupes the array into a new page & uses OS specific functions to lock down the MMU page to read onlyness. MMUunlock is not needed, except to release the page. I don't know if the locked MMU page can be under GC control or not. Also MMUlock would need to be synchronized. In this way you will generate runtime exceptions when people accidentally write to the locked array, and you won't incur any runtime overhead. I might try to implement something like this tonight. Brad
Jul 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Brad Beveridge wrote:

 Any particular reason that we need to move outside of the MMU sphere? 
 About the only one that I can think of is the fact that MMUs work with 
 fixed sized pages, so you will loose some memory due to page wastage.

I don't know, it just sounded like a portability nightmare - much like how the current handling of "null pointer dereferencing" works in D...?
 I might try to implement something like this tonight.

Let us know how it goes, it all brings back memories of doing hacks like "video-on-segfault" to optimize emulator video performance... (Basilisk) --anders
Jul 13 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Anders F Björklund wrote:
 Brad Beveridge wrote:
 
 Any particular reason that we need to move outside of the MMU sphere? 
 About the only one that I can think of is the fact that MMUs work with 
 fixed sized pages, so you will loose some memory due to page wastage.

I don't know, it just sounded like a portability nightmare - much like how the current handling of "null pointer dereferencing" works in D...?
 I might try to implement something like this tonight.

Let us know how it goes, it all brings back memories of doing hacks like "video-on-segfault" to optimize emulator video performance... (Basilisk) --anders

know, all OSes/CPUs that D will run on will support some sort of MMU protection. The actual handling of the exception trap might be a little hairy (as you say, like the null pointer now) - but I think all debuggers will trap the exception if nothing else. Brad
Jul 13 2005
parent reply brad beveridge <brad nowhere.com> writes:
Well, I have done a very simple proof of concept.  It only works under 
linux, and basically memory protecting pages in userspace isn't as nice 
or easy as I would like.  You basically need to create an actual file, 
and them mmap it.  Though I don't think the disk file actually gets 
anything written to.  To implement this properly you would need to be 
able to unlock memory pages, hook into the GC somehow, and reclaim empty 
areas of the memory mapped file.

In short, this is possible to do but pretty ugly to implement, and 
locking/unlocking may be expensive.  Though if the runtime implemented 
it then average joe programmers wouldn't see the ugliness.

Here is the code, do what you will with it :)

Brad

import std.stdio;
import std.c.linux.linuxextern;
import std.c.linux.linux;
import std.string;

int global_fd;

static this ()
{
     char[] junk = "t";
     global_fd = open ("tempfile", O_CREAT | O_RDWR, 0600);
     if (global_fd == -1)
     {
         writefln ("Error 0");
     }
     // don't know why I have to do this, but if the file is empty you
     // cannot write to it after it is mmaped
     write (global_fd,junk, 1);
}

static ~this ()
{
     close (global_fd);
     remove ("tempfile");
}

char[] MMU_lock(char[] array)
{
     void *p;
     void *r;
     char[] readonly;
     p = mmap(null, array.length, PROT_READ | PROT_WRITE, MAP_SHARED, 
global_fd, 0);
     if (p == MAP_FAILED)
     {
         writefln ("Error 1");
         return null;
     }
     writefln ("P is %x", p);
     memcpy (p, array, array.length);

     r = mmap(null, array.length, PROT_READ, MAP_SHARED, global_fd, 0);
     munmap(p, array.length);
     if (r == MAP_FAILED)
     {
         writefln ("Error 2");
         return null;
     }
     writefln ("R is %x", r);
     readonly = cast(char[])r[0 .. array.length];
     return readonly;
}

char[] MMU_unlock(char[] array)
{
}

int main(char[][] args)
{
     char[] stat = "This is a static String";
     char[] d = stat.dup;
     d[0] = 't';
     char[] ro = MMU_lock(d);
     writefln ("ro string is :: %s %d %x", ro, ro.length, ro.ptr);
     writefln ("About to write to ro string");
     ro[0] = 'T';  // this causes a segfault
     writefln ("Done and finished");
     return 1;
}
Jul 13 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"brad beveridge" <brad nowhere.com> wrote in message 
news:db4jab$1gnu$1 digitaldaemon.com...
 Well, I have done a very simple proof of concept.  It only works under 
 linux, and basically memory protecting pages in userspace isn't as nice or 
 easy as I would like.  You basically need to create an actual file, and 
 them mmap it.  Though I don't think the disk file actually gets anything 
 written to.  To implement this properly you would need to be able to 
 unlock memory pages, hook into the GC somehow, and reclaim empty areas of 
 the memory mapped file.

 In short, this is possible to do but pretty ugly to implement, and 
 locking/unlocking may be expensive.  Though if the runtime implemented it 
 then average joe programmers wouldn't see the ugliness.

 Here is the code, do what you will with it :)

 Brad

 import std.stdio;
 import std.c.linux.linuxextern;
 import std.c.linux.linux;
 import std.string;

 int global_fd;

 static this ()
 {
     char[] junk = "t";
     global_fd = open ("tempfile", O_CREAT | O_RDWR, 0600);
     if (global_fd == -1)
     {
         writefln ("Error 0");
     }
     // don't know why I have to do this, but if the file is empty you
     // cannot write to it after it is mmaped
     write (global_fd,junk, 1);
 }

 static ~this ()
 {
     close (global_fd);
     remove ("tempfile");
 }

 char[] MMU_lock(char[] array)
 {
     void *p;
     void *r;
     char[] readonly;
     p = mmap(null, array.length, PROT_READ | PROT_WRITE, MAP_SHARED, 
 global_fd, 0);
     if (p == MAP_FAILED)
     {
         writefln ("Error 1");
         return null;
     }
     writefln ("P is %x", p);
     memcpy (p, array, array.length);

     r = mmap(null, array.length, PROT_READ, MAP_SHARED, global_fd, 0);
     munmap(p, array.length);
     if (r == MAP_FAILED)
     {
         writefln ("Error 2");
         return null;
     }
     writefln ("R is %x", r);
     readonly = cast(char[])r[0 .. array.length];
     return readonly;
 }

 char[] MMU_unlock(char[] array)
 {
 }

 int main(char[][] args)
 {
     char[] stat = "This is a static String";
     char[] d = stat.dup;
     d[0] = 't';
     char[] ro = MMU_lock(d);
     writefln ("ro string is :: %s %d %x", ro, ro.length, ro.ptr);
     writefln ("About to write to ro string");
     ro[0] = 'T';  // this causes a segfault
     writefln ("Done and finished");
     return 1;
 }

Thanks, Brad. Extremely cool. Concept car looked nice but was not moving :) BTW: on Windows you would use VirtualAlloc for that. With the same result, though. And try to imagine that you are passing something like root node of some XML DOM into function designed to return second child node....
Jul 13 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:

 
 Thanks, Brad. Extremely cool.
 Concept car looked nice but was not moving :)
 
 BTW: on Windows you would use VirtualAlloc for that.
 With the same result, though.
 
 And try to imagine that you are passing something
 like root node of some XML DOM into function
 designed to return second child node....
 
 

something could be done - we do after all have an MMU so we should try to use it :) Brad
Jul 14 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:db600b$2to6$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 Thanks, Brad. Extremely cool.
 Concept car looked nice but was not moving :)

 BTW: on Windows you would use VirtualAlloc for that.
 With the same result, though.

 And try to imagine that you are passing something
 like root node of some XML DOM into function
 designed to return second child node....

something could be done - we do after all have an MMU so we should try to use it :)

Yep. But *we* do not have MMU. It is OS who has it. Andrew.
Jul 14 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:

:) That's pretty much what I thought.  But it was worth a shot to see if 
something could be done - we do after all have an MMU so we should try to 
use it :)

Yep. But *we* do not have MMU. It is OS who has it. Andrew.

True. I program device drivers & OS level stuff for a day job, so I tend to think about things as they are close to the hardware. It is a shame that user applications don't have better control of the MMU in modern OSes - but such is life :) Brad
Jul 14 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:db6o65$hug$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

:) That's pretty much what I thought.  But it was worth a shot to see if 
something could be done - we do after all have an MMU so we should try to 
use it :)

Yep. But *we* do not have MMU. It is OS who has it. Andrew.

True. I program device drivers & OS level stuff for a day job, so I tend to think about things as they are close to the hardware. It is a shame that user applications don't have better control of the MMU in modern OSes - but such is life :)

I see you are a bit pessimistic about life... Well, it has good sides too. Just need to take a gaze and you'll see... For example here is a shot named "Furniture for eXtreme Programming. Chair." http://www.terrainformatica.com/screenshots/xpchair.jpg I've made it in my office week ago. Disclaimer: For those who practicing XP - nothing personal. Andrew.
Jul 14 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 13 Jul 2005 15:43:31 -0700, Brad Beveridge <brad somewhere.net>  
wrote:
 Anders F Björklund wrote:

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

Actually, the Wikipedia entry on COW disagrees with D's take on COW. From Wikipedia "This fiction can be maintained until a caller tries to modify its "copy" of the resource, at which point a true private copy is created to prevent the changes becoming visible to everyone else. All of this happens transparently to the callers." The key thing being "all this happens transparently to callers", in D's take on COW the callers must explicitly manage their own COW. Now, as a thought experiment imagine that COW in D was transparent. Imagine that when you returned an array in D it acted just as it does now, except that when you wrote to it, the D compiler/runtime automatically duped it and you wrote to your own array. Would this make a difference to how we programed? Certainly it would make the idea that we needed immutable strings go away (all arrays are effectively immutable). Now of course we would need some mechanism for actually returning a modifiable array. Thoughts?

I think the default case would be mutable, eg char[] foo() {} returns a mutable array, however: readonly char[] foo() {} returns an immutable one. An array declared in the current scope would default to being mutable, eg. char[] bar; it would be mutable and not create a duplicate when you wrote to it (in this scope). Passing it to an 'in' parameter would treat is as immutable, causing a dup on write, eg. void foobar(char[] p) { p[0] = 'a'; } Assigning a mutable reference to an immutable one would make the mutable immutable. eg. immutable char[] p; char[] s; s = p; //s is now immutable. The question is how do you implement this sort of thing. It's essentially an Auto Pointer or Reference Counter, there seem to be 2 choices for implementation: 1. runtime mutable bit flag. (if false dup, set to true on copy) 2. 2 distinct types. (writing to immutable type, creates mutable copy) Though it might be possible for the compiler to determine at compile time the cases where a dup is required and for it to silently insert them into the code during compile. Not sure if that makes sense, just floating the idea. Regan p.s. This is essentially the readonly idea I have posted before. What can I say, I think it works as an idea. The implementation is the difficult part. (as Anders has just posted)
Jul 13 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 I think the default case would be mutable, eg
   char[] foo() {}
 
 returns a mutable array, however:
   readonly char[] foo() {}
 
 returns an immutable one.

I think the default case should be immutable... AFAIK, it already is - although not enforced ? If nothing else, "const char *" is boring to type, and I don't think "readonly char[]" would be less. Better to have readwrite/mutable for "the other 10%", than having a readonly/immutable applied to "most" ? --anders
Jul 13 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 14 Jul 2005 01:30:11 +0200, Anders F Björklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 I think the default case would be mutable, eg
   char[] foo() {}
  returns a mutable array, however:
   readonly char[] foo() {}
  returns an immutable one.

I think the default case should be immutable... AFAIK, it already is - although not enforced ?

Well, COW dictates you should be copying it before you write, so, yes, all arrays are immutable though not enforced. I think it should be mutable because I think if you return something, most of the time it's the only copy, and you're not holding it anywhere i.e. char[] toString(int i); Of course class members might return references or slices to internal data, then you'd use 'readonly'. I don't think this is as common as returning a new array, one that can safely be written to. I might be wrong.
 If nothing else, "const char *" is boring to type,
 and I don't think "readonly char[]" would be less.

True. Which is why I chose 'mutable' as the default, I think it's more common, thus less typing. You obviously disagree. Only code analysis will tell us for sure, and then I suspect different types/areas will show a different result.
 Better to have readwrite/mutable for "the other 10%",
 than having a readonly/immutable applied to "most" ?

I disagree with 10%, and "most", obviously. Regan
Jul 13 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 True. Which is why I chose 'mutable' as the default, I think it's more  
 common, thus less typing. You obviously disagree. Only code analysis 
 will  tell us for sure, and then I suspect different types/areas will 
 show a  different result.

Actually, I think "immutable" is the most common case for parameters. As for local variables, there it is pretty common to want "mutable" ? Too bad that the C++ usage of the keywords "const" and "mutable" have muddied the waters enough to make any discussion about it confusing... Meanwhile, it seems it's back to the usual warnings on the wrapping: "use caution.contents might be hot.slippery when wet.immutable inside" >> Better to have readwrite/mutable for "the other 10%",
 than having a readonly/immutable applied to "most" ?

I disagree with 10%, and "most", obviously.

Obviously. I don't have any numbers to back it up - I just meant it as in the 90/10 rule... (a.k.a. 80/20 rule, etc). As in common/uncommon ? It also assumes that you can do a _whole lot_ of manipulation with immutable strings, just not change the referenced contents directly. i.e. you could still concat strings and use functions to convert it to upper case and so and so forth. (by creating new immutable copies) Actual syntax could probably still need some design work, though. (but I'm supposed to be on summer vacation soon, so I'll leave it) --anders
Jul 14 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 14 Jul 2005 09:46:35 +0200, Anders F Björklund <afb algonet.se>  
wrote:

 Regan Heath wrote:

 True. Which is why I chose 'mutable' as the default, I think it's more   
 common, thus less typing. You obviously disagree. Only code analysis  
 will  tell us for sure, and then I suspect different types/areas will  
 show a  different result.

Actually, I think "immutable" is the most common case for parameters.

I agree. I was talking about return values being mutable.
 As for local variables, there it is pretty common to want "mutable" ?

Yep. That's what I said too.
 Too bad that the C++ usage of the keywords "const" and "mutable" have
 muddied the waters enough to make any discussion about it confusing...

You may have miss-read what I wrote?
 Meanwhile, it seems it's back to the usual warnings on the wrapping:
 "use caution.contents might be hot.slippery when wet.immutable inside"

LOL.
   >> Better to have readwrite/mutable for "the other 10%",
 than having a readonly/immutable applied to "most" ?


Obviously. I don't have any numbers to back it up - I just meant it as in the 90/10 rule... (a.k.a. 80/20 rule, etc). As in common/uncommon ? It also assumes that you can do a _whole lot_ of manipulation with immutable strings, just not change the referenced contents directly. i.e. you could still concat strings and use functions to convert it to upper case and so and so forth. (by creating new immutable copies) Actual syntax could probably still need some design work, though. (but I'm supposed to be on summer vacation soon, so I'll leave it)

Here is a summary of what I expect to be common. return values: mutable local variables: mutable parameters: immutable Regan
Jul 14 2005
parent reply =?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Regan Heath wrote:

 Too bad that the C++ usage of the keywords "const" and "mutable" have
 muddied the waters enough to make any discussion about it confusing...

You may have miss-read what I wrote?

Could be, we seem to be in agreement. (now it's "just the details")
 Here is a summary of what I expect to be common.
 
 return values: mutable
 local variables: mutable
 parameters: immutable

I think e.g. "char[] toString()" should return an immutable string. String literals should definitely be immutable, as well. (local too) But I do need to write more D code, in order to test this out fully. --anders
Jul 14 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 14 Jul 2005 11:25:03 +0200, Anders F Björklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 Too bad that the C++ usage of the keywords "const" and "mutable" have
 muddied the waters enough to make any discussion about it confusing...


Could be, we seem to be in agreement. (now it's "just the details")
 Here is a summary of what I expect to be common.
  return values: mutable
 local variables: mutable
 parameters: immutable

I think e.g. "char[] toString()" should return an immutable string.

Maybe, maybe not, whatever is most common.
 String literals should definitely be immutable, as well. (local too)

Yeah, I agree. You can always .dup for a mutable one.
 But I do need to write more D code, in order to test this out fully.

In cases where it's a class method the return value is more likely to be immutable, for a normal function (unless it's returning static data, as toString does) it's more likely to be mutable, or so I reasoned. Regan
Jul 14 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:db4863$17dt$1 digitaldaemon.com...
 Regan Heath wrote:

 I think the default case would be mutable, eg
   char[] foo() {}

 returns a mutable array, however:
   readonly char[] foo() {}

 returns an immutable one.

I think the default case should be immutable... AFAIK, it already is - although not enforced ? If nothing else, "const char *" is boring to type, and I don't think "readonly char[]" would be less. Better to have readwrite/mutable for "the other 10%", than having a readonly/immutable applied to "most" ? --anders

char[#] is a bit better than readonly char[], huh? :))) Other choices : C99 trigraphs style char[<>], char[:], etc.
Jul 13 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:

 char[#]  is a bit better than readonly char[], huh? :)))

Actually I thought you said "char #[]", maybe you changed it... Alternative: The argument "char[inout]" (contents) would be pretty similar to "inout char[]" (reference), but still a bit hard to decipher ? (that is: the first would be like "const char*", and the second would be like "char* const" BTW; The "readonly" attribute was only a less-loaded const alternative. But it seems like it still burdened by all the Const Correctness... --anders
Jul 14 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:db57bf$27s3$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 char[#]  is a bit better than readonly char[], huh? :)))

Actually I thought you said "char #[]", maybe you changed it... Alternative: The argument "char[inout]" (contents) would be pretty similar to "inout char[]" (reference), but still a bit hard to decipher ? (that is: the first would be like "const char*", and the second would be like "char* const" BTW; The "readonly" attribute was only a less-loaded const alternative. But it seems like it still burdened by all the Const Correctness... --anders

I've already published this proposal, I'll repeat it then: ---------------------------------------------------------- Possible syntax for immutable arrays and pointers. declarations: // arrays char a[]; // RW array/slice char b[#]; // RO array/slice char a[ 100 ] ; // static RW array/slice. char b[# 100 ]; // static RO array/slice. // pointers char * pa; // RW pointer char *# pb; // RO pointer // associative arrays/maps int[ char[] ] a; // RW map int[# char[] ] b; // RO map ---------------------------- Rationale: readonly attribute syntacticaly should be as close as possible to array/pointer designator ( [ ] ), ideally it should be part of it. Andrew. http://terrainformatica.com
Jul 14 2005
prev sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
This is cool, except it's not documented.

Can I assume that this is how native-type-methods are implemented in D?
And is that behaviour intended or is it just a bug? (I'm referring to 
the behaviour that Andrew explained)

Walter? Are you reading this?

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

Try to write it: "This is a test".rfind("is"); It should run flawlessly. By some accident D allows to do such trick with array parameters.
Even that isn't quite perfect.  It would be nice to be able to do things 
like:
s = "This is a test";
s.removechars("/is/");  //   N.B.:  Note the /'s this should mean
                        //       "interpret this as a pattern"
Notice that the syntax has changed a bit from the current usage as this is 
now a method invocation rather than a function call.

As I mentioned if removechars is declared as void removechars(char[],char[]) then you can call it as s.removechars("/is/"); I wouldn't rely on this behavior though as it is not specified - "D's hidden treasure"

Jul 13 2005
prev sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
Nick wrote:

 - No garbage collection
 - Member function pointers (ie. no delegates)
 - Lack of "abstract" and "typeof" keywords
 - No modules, and the namespace system is a hack to try to fix this
 - Memory safety and language safety in general
 - Too many complicated and unecessary language rules

As "many years C++ developer" I can say: 1) IMHO it is a good choice not to give garbage collection to the core language - this way people can use variety of GC implementations, for different purposes... 2) Same as previous - there are thousands of excellent delegate-like libraries, some type-safe, some not - again for all tastes. 3) We (C++) developers do not need an abstract keyword to know that our class is an abstract class. Secondly - there is typeof keyword! 4) If one (developer) writes safe code, follows C++ priciples, basically - disciplined C++ programmer, he'll write more safe program than (IMHO the safest) Modula-3 or ADA programers. 5) Again, You do not need to follow them all - it is UP YOU! :) Kind regards Dejan -- ........... Dejan Lekic http://dejan.lekic.org
Jul 11 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 12 Jul 2005 00:18:01 +0200, Dejan Lekic <leka entropy.tmok.com>  
wrote:
 Nick wrote:

 - No garbage collection
 - Member function pointers (ie. no delegates)
 - Lack of "abstract" and "typeof" keywords
 - No modules, and the namespace system is a hack to try to fix this
 - Memory safety and language safety in general
 - Too many complicated and unecessary language rules


This is not an attack on C++, nor your defence of it.
 As "many years C++ developer" I can say:

 1) IMHO it is a good choice not to give garbage collection to the core
 language - this way people can use variety of GC implementations, for
 different purposes...

If any GC can be plugged in, or completely disabled you've achieved the same end, in a better way.
 2) Same as previous - there are thousands of excellent delegate-like
 libraries, some type-safe, some not - again for all tastes.

Are any as easy to use as a built in solution can be? How many different ways are there to do delegates? I recall recently someone wanting to copy the stack, ideally any difference in goal like this would be customizable with a built in solution. Ideally the language should be powerful enough to allow you to write a library delegate to achieve any goal not already supported by the built in solution.
 3) We (C++) developers do not need an abstract keyword to know that our
 class is an abstract class. Secondly - there is typeof keyword!

Having a keyword is useful, it clearly states the programmers intent - allowing the compiler to verify that intent and it documents to the next developer the intent, again allowing verification. This is a general statement not specific to any particular keyword.
 4) If one (developer) writes safe code, follows C++ priciples, basically  
 -
 disciplined C++ programmer, he'll write more safe program than (IMHO the
 safest) Modula-3 or ADA programers.

I smell a language war brewing. You could remove the word "C++" from the above, change the part which begins "(IMHO.." to read "otherwise" and it would be a much truer statement IMO, eg. "If one (developer) writes safe code, follows priciples, basically disciplined programmer, he'll write more safe program than otherwise" Sure, each language provides more or less in the way of safety but in the end it's the individual developer that matters.
 5) Again, You do not need to follow them all - it is UP YOU! :)

I assume the word "to" is missing from that last statement? ;) Regan
Jul 11 2005
parent reply Dejan Lekic <leka entropy.tmok.com> writes:
No, I do not defend C++ - If I was so deeply in love in it I would not use
other languages, notably Modula-3, D or C# (i've excluded some scripting
languages from the list)... I just dislike common anti-c++ articles, even
if they make sense, because we, developers, use what we are familiar with,
and what "does the job" (TM). :)

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
Jul 11 2005
parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Dejan Lekic wrote:
 No, I do not defend C++ - If I was so deeply in love in it I would not use
 other languages, notably Modula-3, D or C# (i've excluded some scripting
 languages from the list)... I just dislike common anti-c++ articles, even
 if they make sense, because we, developers, use what we are familiar with,
 and what "does the job" (TM). :)
 

replace the garbage collection, they are (or should be) the exceptional cases. As it is most C/C++ programmers have no access to ANY garbage collection. You may say "Well, if they just...", but the answer has to be "They don't". I have heard it seriously asserted that the largest improvement in computer languages over the last 20 years was the common inclusion of garbage collectors. I don't know on what basis this assertion was made, but the person making it was widely respected and definitely believed it. Apparently dangling pointers, invalid array references, etc. were sufficiently common that just getting rid of them was a bigger improvement than either Object oriented programming or even structured programming (but perhaps that was more than 20 years ago?). Of course, it may also have had a bit of hyperbole in it, but don't write off the importance of Garbage Collection just because it's occasionally imperfect.
Jul 13 2005
next sibling parent llothar <llothar_member pathlink.com> writes:
In article <db3slk$u4n$1 digitaldaemon.com>, Charles Hixson says...

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

I posted a GC question today is is not fully answered but enough to say: Every C/C++ programmer have as much GC at there hand as a D programmer. They just need to link in Boehms GC , then you need just a few lines of code to replace the standart new/delete/delete[] and a one liner for each class that should have a finalizer call (which is not so much typing overhead).
Jul 13 2005
prev sibling parent reply Mike Capp <mike.capp gmail.com> writes:
In article <db3slk$u4n$1 digitaldaemon.com>, Charles Hixson says...
I have heard it 
seriously asserted that the largest improvement in computer 
languages over the last 20 years was the common inclusion of 
garbage collectors. [...] Apparently dangling pointers, invalid 
array references, etc. were sufficiently common that just getting 
rid of them was a bigger improvement than either Object oriented 
programming or even structured programming (but perhaps that was 
more than 20 years ago?).

SP is *way* more than 20 years old. OO is coming up on 40 (since Simula inroduced it in '67). So I'm not sure what improvements the speaker was comparing GC to. STL-style generics, maybe?
don't write off the importance of Garbage 
Collection just because it's occasionally imperfect.

Oh, I don't. There's no question at all about programmer productivity in GC languages, and I'm slowly coming round to accept that for long-lived objects the benefits might outweight the nasty unpredictability drawbacks. I'm still convinced that GC is massive overkill for local-scoped class variables and (to a lesser extent) simple value-like class members. C++'s default stack allocation is a far better story than D on this front.
Jul 13 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message
news:db40ld$11b1$1 digitaldaemon.com...
 I'm still convinced that GC is massive overkill for local-scoped class

 and (to a lesser extent) simple value-like class members. C++'s default

 allocation is a far better story than D on this front.

"simple value-like class" object instances in D are called structs and are allocated on the stack.
Jul 14 2005
parent reply Mike Capp <mike.capp gmail.com> writes:
In article <db63at$31dn$3 digitaldaemon.com>, Walter says...
"Mike Capp" <mike.capp gmail.com> wrote 
 GC is massive overkill for local-scoped class variables
 and (to a lesser extent) simple value-like class members. C++'s default
 stack allocation is a far better story than D on this front.

"simple value-like class" object instances in D are called structs and are allocated on the stack.

D structs correspond to C structs or C++ POD types, not to lightweight C++ value types in general. D seems to fall into the same trap as Java in thinking that OO only applies to Big Heavyweight Types, and that lightweight types can't possibly need encapsulation or any of that guff. Take something trivial like a UnitVector3: a vector of three floats with a magnitude of 1. It's smaller than builtins like cdouble, and it's normally going to appear as a temporary, local-scoped variable or member of a larger aggregate type. It's situations like this where GC looks like massive overkill; if you're doing a lot of calculation with these things you're going to get a lot of unnecessary gen0 churn. D structs are no help at all for use cases like this. The interesting part of UnitVector3 is the invariant, and while you can specify an invariant for a D struct, it feels a bit like mocking the poor thing because the struct has no way to establish or preserve that invariant. No constructors, no protection attributes, so what's the point? (Protection atts in structs are accepted by the compiler, and even appear in some doc examples e.g. "Properties", but aren't enforced as of 0.128.) Implementing (and guaranteeing) stack allocation for 'auto' class instances would help a bit, but only a bit, because autos can't be returned or passed around like values. cheers Mike
Jul 14 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message 
news:db6tl0$m1d$1 digitaldaemon.com...
 In article <db63at$31dn$3 digitaldaemon.com>, Walter says...
"Mike Capp" <mike.capp gmail.com> wrote
 GC is massive overkill for local-scoped class variables
 and (to a lesser extent) simple value-like class members. C++'s default
 stack allocation is a far better story than D on this front.

"simple value-like class" object instances in D are called structs and are allocated on the stack.

D structs correspond to C structs or C++ POD types, not to lightweight C++ value types in general. D seems to fall into the same trap as Java in thinking that OO only applies to Big Heavyweight Types, and that lightweight types can't possibly need encapsulation or any of that guff. Take something trivial like a UnitVector3: a vector of three floats with a magnitude of 1. It's smaller than builtins like cdouble, and it's normally going to appear as a temporary, local-scoped variable or member of a larger aggregate type. It's situations like this where GC looks like massive overkill; if you're doing a lot of calculation with these things you're going to get a lot of unnecessary gen0 churn. D structs are no help at all for use cases like this. The interesting part of UnitVector3 is the invariant, and while you can specify an invariant for a D struct, it feels a bit like mocking the poor thing because the struct has no way to establish or preserve that invariant.

Why not? Make the fields private with no setter.
 No constructors,

easily worked around for your example by specifying a init value where one of the fields is 1 (e.g. x) or using either a top-level function or the "static opCall" hack.
 no protection
 attributes, so what's the point? (Protection atts in structs are accepted 
 by the
 compiler, and even appear in some doc examples e.g. "Properties", but 
 aren't
 enforced as of 0.128.)

A bug in dmd.128 shouldn't make one conclude that structs in D (the language) have "no protection".
 Implementing (and guaranteeing) stack allocation for 'auto' class 
 instances
 would help a bit, but only a bit, because autos can't be returned or 
 passed
 around like values.

I would stick with structs.
Jul 14 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi there,

 D structs are no help at all for use cases like this. The interesting part 
 of
 UnitVector3 is the invariant, and while you can specify an invariant for a 
 D
 struct, it feels a bit like mocking the poor thing because the struct has 
 no way
 to establish or preserve that invariant.

Why not? Make the fields private with no setter.

Correct me if I'm wrong, but I believe that the private modifier has no effect on struct variable members. I'm on DMD/Linux 0.127 and I can do this: Foo.d ===== # struct Foo { private int Bar = 42; } Bar.d ===== # import std.string; # import std.stdio; # import Foo; # # void main() { # Foo foo; # writefln(toString(foo.Bar)); # foo.Bar = 1337; # writefln(toString(foo.Bar)); # } # # // Prints 42, then 1337. They're even on separate files to avoid the annoying default "friend" modifier. I don't know if this is a bug or "feature," but for consistency (at the least), I think private should be enforced. Cheers, --AJG.
Jul 14 2005
next sibling parent "Uwe Salomon" <post uwesalomon.de> writes:
 They're even on separate files to avoid the annoying default "friend"  
 modifier.
 I don't know if this is a bug or "feature," but for consistency (at the  
 least),
 I think private should be enforced.

Huh? I didn't know that. I really want to add a strong "Yes!" to that statement. The Indigo containers, for example, are heavily struct-based (nice example to see how much *is* possible with structs, by the way), and they don't like messing up their guts :) Ciao uwe
Jul 14 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:db7hf0$181k$1 digitaldaemon.com...
 Hi there,

 D structs are no help at all for use cases like this. The interesting 
 part
 of
 UnitVector3 is the invariant, and while you can specify an invariant for 
 a
 D
 struct, it feels a bit like mocking the poor thing because the struct 
 has
 no way
 to establish or preserve that invariant.

Why not? Make the fields private with no setter.

Correct me if I'm wrong, but I believe that the private modifier has no effect on struct variable members. I'm on DMD/Linux 0.127 and I can do this:

That's a bug in dmd that will get fixed (as Mike mentioned, too). Don't worry about it.
Jul 15 2005
prev sibling parent Mike Capp <mike.capp gmail.com> writes:
In article <db74df$qk1$1 digitaldaemon.com>, Ben Hinkle says...
 No constructors,

easily worked around for your example by [...] the "static opCall" hack.

Hmm, that hadn't occurred to me. Thanks. Still some unnecessary copies going on, but the compiler backend can probably optimize those away.
A bug in dmd.128 shouldn't make one conclude that structs in D (the 
language) have "no protection".

It's not just a bug in 0.128; the grammar in the doc page for structs (unlike the one for classes) makes no mention at all of protection. I'd be happy to raise it again as a bug, though, if you think it stands any chance of being "fixed". cheers Mike
Jul 15 2005
prev sibling parent M <M_member pathlink.com> writes:
typeof keyword is not in C++ standard (as far as I know), it is add on in some
compilers like gnu c and gnu c++.

In article <dauqod$27hl$1 digitaldaemon.com>, Dejan Lekic says...
Nick wrote:

 - No garbage collection
 - Member function pointers (ie. no delegates)
 - Lack of "abstract" and "typeof" keywords
 - No modules, and the namespace system is a hack to try to fix this
 - Memory safety and language safety in general
 - Too many complicated and unecessary language rules

As "many years C++ developer" I can say: 1) IMHO it is a good choice not to give garbage collection to the core language - this way people can use variety of GC implementations, for different purposes... 2) Same as previous - there are thousands of excellent delegate-like libraries, some type-safe, some not - again for all tastes. 3) We (C++) developers do not need an abstract keyword to know that our class is an abstract class. Secondly - there is typeof keyword! 4) If one (developer) writes safe code, follows C++ priciples, basically - disciplined C++ programmer, he'll write more safe program than (IMHO the safest) Modula-3 or ADA programers. 5) Again, You do not need to follow them all - it is UP YOU! :) Kind regards Dejan -- ........... Dejan Lekic http://dejan.lekic.org

Jul 12 2005