www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos "inadequate"? Linux output "bloated"? etc.

reply Def <Def_member pathlink.com> writes:
On http://www.digitalmars.com/d/dcompiler.html it reads:

"The phobos D runtime library is inadequate."

In which way is Phobos "inadequate"? Will it be "fixed"? If so, how?
When? ;-)
And what about the other bugs:
- The compiler sometimes gets the line number wrong on an error.
- The phobos D runtime library is inadequate.
- Need to write a tool to convert C .h files into D imports.
- Array op= operations are not implemented.
- In preconditions and out postconditions for member functions are not
inherited.
- It cannot be run from the IDDE.

And what about the Linux bugs, listed on the same page?
- -g is only implemented for line numbers, not local symbols, because I
haven't figured out how to do it yet. gdb still works, though, at the
global symbol level.
- The code generator output has not been tuned yet, so it can be bloated.
Shared libraries cannot be generated.
- The exception handling is not compatible with the way g++ does it.
I don't know if this is an issue or not.

Def
Mar 08 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Def wrote:
 On http://www.digitalmars.com/d/dcompiler.html it reads:
 
 "The phobos D runtime library is inadequate."
 
 In which way is Phobos "inadequate"? Will it be "fixed"? If so, how?
 When? ;-)
 And what about the other bugs:
 - The compiler sometimes gets the line number wrong on an error.
 - The phobos D runtime library is inadequate.
 - Need to write a tool to convert C .h files into D imports.
 - Array op= operations are not implemented.
 - In preconditions and out postconditions for member functions are not
 inherited.
 - It cannot be run from the IDDE.
 
 And what about the Linux bugs, listed on the same page?
 - -g is only implemented for line numbers, not local symbols, because I
 haven't figured out how to do it yet. gdb still works, though, at the
 global symbol level.
 - The code generator output has not been tuned yet, so it can be bloated.
 Shared libraries cannot be generated.
 - The exception handling is not compatible with the way g++ does it.
 I don't know if this is an issue or not.
 
 Def
 
 

I get the feeling that alot of this is old, maybe Walter can give more specifics though.
Mar 08 2006
prev sibling parent reply Ben Phillips <Ben_member pathlink.com> writes:
In article <dune2o$cu4$1 digitaldaemon.com>, Def says...
 Array op= operations are not implemented.

This has been discussed numerous times and the consensus is that overloading "=" is a bad idea. You must remember that D uses references so if we have a class and two instances ("a" and "b") then "a = b;" makes "a" refer to the same object as "b". The programmer should not be allowed to change this behavior. On the other hand, another operator such as ":=" has been suggested which would be a copy operator rather than an assignment operator
Mar 08 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Ben Phillips wrote:
 In article <dune2o$cu4$1 digitaldaemon.com>, Def says...
 
 Array op= operations are not implemented.

This has been discussed numerous times and the consensus is that overloading "=" is a bad idea. You must remember that D uses references so if we have a class and two instances ("a" and "b") then "a = b;" makes "a" refer to the same object as "b". The programmer should not be allowed to change this behavior. On the other hand, another operator such as ":=" has been suggested which would be a copy operator rather than an assignment operator

It would definitely stand out in code better than a .dup swamped somewhere inconspicuous.
Mar 09 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Georg Wrede wrote:
 Ben Phillips wrote:
 
 In article <dune2o$cu4$1 digitaldaemon.com>, Def says...

 Array op= operations are not implemented.

This has been discussed numerous times and the consensus is that overloading "=" is a bad idea. You must remember that D uses references so if we have a class and two instances ("a" and "b") then "a = b;" makes "a" refer to the same object as "b". The programmer should not be allowed to change this behavior. On the other hand, another operator such as ":=" has been suggested which would be a copy operator rather than an assignment operator

It would definitely stand out in code better than a .dup swamped somewhere inconspicuous.

But you lose all meaning as to if that dup is a shallow copy or deep copy. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M-- V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++ ------END GEEK CODE BLOCK------ James Dunne
Mar 09 2006
parent reply Fredrik Olsson <peylow treyst.se> writes:
James Dunne skrev:
 Georg Wrede wrote:
 Ben Phillips wrote:

 In article <dune2o$cu4$1 digitaldaemon.com>, Def says...

 Array op= operations are not implemented.

This has been discussed numerous times and the consensus is that overloading "=" is a bad idea. You must remember that D uses references so if we have a class and two instances ("a" and "b") then "a = b;" makes "a" refer to the same object as "b". The programmer should not be allowed to change this behavior. On the other hand, another operator such as ":=" has been suggested which would be a copy operator rather than an assignment operator

It would definitely stand out in code better than a .dup swamped somewhere inconspicuous.

But you lose all meaning as to if that dup is a shallow copy or deep copy.

::= deep copy :) But how to solve for example "foo(bar.dup);"? Perhaps not a critical flaw, but something could be useful if you know that foo will corupt the input. "foo(:bar);", and "foo(::bar);" would be the logical answers but not as pretty, or? // Fredrik
Mar 09 2006
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Fredrik Olsson wrote:
 On the other hand, another operator such as ":=" has been suggested
 which would be a copy operator rather than an assignment operator

It would definitely stand out in code better than a .dup swamped somewhere inconspicuous.

But you lose all meaning as to if that dup is a shallow copy or deep copy.

::= deep copy

It's not that simple. There's a good reason to allow the coder to override default (shallow) cloning with a custom one. Not all classes require you to clone all contents. A simple opClone-override would be enough. A := -operator doesn't provide anything amusingly new. You can do this already with foo.dup(). But it looks quite pretty :)
 
 But how to solve for example "foo(bar.dup);"? Perhaps not a critical
 flaw, but something could be useful if you know that foo will corupt the
 input. "foo(:bar);", and "foo(::bar);" would be the logical answers but
 not as pretty, or?

No. C++ coders might get confused here.
Mar 09 2006