www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.101 release

reply "Walter" <newshound digitalmars.com> writes:
http://www.digitalmars.com/d/changelog.html
Aug 30 2004
next sibling parent h3r3tic <h3r3tic dev.null> writes:
wow!, thanks Walter, you have exterminated all - 1 of my bugs :] but 
this code still doesn't compile :(

void foo()
{
	class Foo
	{
		int x;
	}
}

void bar()
{
	class Foo
	{
		int y;
	}
	
	Foo f = new Foo;
	f.y = 5;
}

void main()
{
}

// foo.d(17): no property 'y' for type 'Foo'
Aug 31 2004
prev sibling next sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <ch0n9t$5k8$1 digitaldaemon.com>, Walter says...
http://www.digitalmars.com/d/changelog.html

"Missing function body after 'in' now diagnosed." I just realized I had the following code lying around (it doesn't compile anymore.) : # abstract double random() # out(result) # { # assert( (0 < result) && (result < 1) ); # }; I know in/out contracts aren't inherited yet, so the out block has no effect. But when inheritance _is_ implemented, shouldn't the above be allowed? Nick
Aug 31 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <ch22l8$qs8$1 digitaldaemon.com>, Nick says...
In article <ch0n9t$5k8$1 digitaldaemon.com>, Walter says...
http://www.digitalmars.com/d/changelog.html

"Missing function body after 'in' now diagnosed." I just realized I had the following code lying around (it doesn't compile anymore.) : # abstract double random() # out(result) # { # assert( (0 < result) && (result < 1) ); # }; I know in/out contracts aren't inherited yet, so the out block has no effect. But when inheritance _is_ implemented, shouldn't the above be allowed?

"abstract" is kind of weird. It's entirely possible to do this right now: # class Test # { # public: # abstract double random() # out(result) # { # assert( (0 < result) && (result < 1) ); # } # body # { # return 0.0; # } # } # # int main() # { # Test d = new Test(); # d.random(); # return 0; # } IMO this should fail to compile with a message like "cannot instantiate abstract class", but it doesn't (ie. I expect abstract functions to work just like pure virtual functions in C++). Still, an easy workaround for your situation is to define a body that returns something that fails the output contract, as I did above. Sean
Aug 31 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message
news:ch22l8$qs8$1 digitaldaemon.com...
 In article <ch0n9t$5k8$1 digitaldaemon.com>, Walter says...
http://www.digitalmars.com/d/changelog.html

"Missing function body after 'in' now diagnosed." I just realized I had the following code lying around (it doesn't compile anymore.) : # abstract double random() # out(result) # { # assert( (0 < result) && (result < 1) ); # };

I'm sure it didn't work before, either.
 I know in/out contracts aren't inherited yet, so the out block has no

 But when inheritance _is_ implemented, shouldn't the above be allowed?

Hmm. I can't think why not.
Aug 31 2004
parent Nick <Nick_member pathlink.com> writes:
In article <ch2ak8$v2k$1 digitaldaemon.com>, Walter says...
 # abstract double random()
 # out(result)
 # {
 #   assert( (0 < result) && (result < 1) );
 # };

I'm sure it didn't work before, either.

It didn't actually _work_, no, but it did compile. I left it there so it would work in the future, when in/out inheritance was implemented. For now I've just commented it out. Nick
Aug 31 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 http://www.digitalmars.com/d/changelog.html

"Function literals can now have same type signature." Same as what? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 01 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Stewart Gordon wrote:

 Walter wrote:
 
 http://www.digitalmars.com/d/changelog.html

"Function literals can now have same type signature." Same as what? Stewart.

Same as each other. I think there was a bug where two function literals in the same scope couldn't have the same signature. So void foo() { x = function int(){...}; y = function int(){...}; } wouldn't compile because of conflicting function names. My guess is that's the bug that got fixed.
Sep 01 2004
parent reply Cappa-Gamma <Cappa-Gamma_member pathlink.com> writes:
Hmmm, compiling this though :

###
module foo;

import std.stream;

void main () 
{
void function() x, y;
x = function void() { stdout.writeLine("X!"); };
y = function void()  { stdout.writeLine("Y!"); };
x();
y();
}

Gives me the error :

c:\dmd\bin\..\..\dm\bin\link.exe foo,,,user32+kernel32/noi;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

foo.obj(foo)  Offset 001B5H Record Type 00C3 
Error 1: Previous Definition Different : _D3foo4main0FZv
--- errorlevel 1

??

Charlie


In article <ch4ehp$25sb$2 digitaldaemon.com>, Ben Hinkle says...
Stewart Gordon wrote:

 Walter wrote:
 
 http://www.digitalmars.com/d/changelog.html

"Function literals can now have same type signature." Same as what? Stewart.

Same as each other. I think there was a bug where two function literals in the same scope couldn't have the same signature. So void foo() { x = function int(){...}; y = function int(){...}; } wouldn't compile because of conflicting function names. My guess is that's the bug that got fixed.

Sep 01 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
worked for me. Did you get dmd-0.101? Run dmd -v to find out.

"Cappa-Gamma" <Cappa-Gamma_member pathlink.com> wrote in message
news:ch513r$2em3$1 digitaldaemon.com...
 Hmmm, compiling this though :

 ###
 module foo;

 import std.stream;

 void main ()
 {
 void function() x, y;
 x = function void() { stdout.writeLine("X!"); };
 y = function void()  { stdout.writeLine("Y!"); };
 x();
 y();
 }

 Gives me the error :

 c:\dmd\bin\..\..\dm\bin\link.exe foo,,,user32+kernel32/noi;
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 foo.obj(foo)  Offset 001B5H Record Type 00C3
 Error 1: Previous Definition Different : _D3foo4main0FZv
 --- errorlevel 1

 ??

 Charlie


 In article <ch4ehp$25sb$2 digitaldaemon.com>, Ben Hinkle says...
Stewart Gordon wrote:

 Walter wrote:

 http://www.digitalmars.com/d/changelog.html

"Function literals can now have same type signature." Same as what? Stewart.

Same as each other. I think there was a bug where two function literals


the same scope couldn't have the same signature. So
void foo() {
 x = function int(){...};
 y = function int(){...};
}
wouldn't compile because of conflicting function names. My guess is


the bug that got fixed.


Sep 01 2004
parent Cappa-Gamma <Cappa-Gamma_member pathlink.com> writes:
Oh no , duh :S.  Hehe it works, sweet!


In article <ch5226$2f0s$1 digitaldaemon.com>, Ben Hinkle says...
worked for me. Did you get dmd-0.101? Run dmd -v to find out.

"Cappa-Gamma" <Cappa-Gamma_member pathlink.com> wrote in message
news:ch513r$2em3$1 digitaldaemon.com...
 Hmmm, compiling this though :

 ###
 module foo;

 import std.stream;

 void main ()
 {
 void function() x, y;
 x = function void() { stdout.writeLine("X!"); };
 y = function void()  { stdout.writeLine("Y!"); };
 x();
 y();
 }

 Gives me the error :

 c:\dmd\bin\..\..\dm\bin\link.exe foo,,,user32+kernel32/noi;
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 foo.obj(foo)  Offset 001B5H Record Type 00C3
 Error 1: Previous Definition Different : _D3foo4main0FZv
 --- errorlevel 1

 ??

 Charlie


 In article <ch4ehp$25sb$2 digitaldaemon.com>, Ben Hinkle says...
Stewart Gordon wrote:

 Walter wrote:

 http://www.digitalmars.com/d/changelog.html

"Function literals can now have same type signature." Same as what? Stewart.

Same as each other. I think there was a bug where two function literals


the same scope couldn't have the same signature. So
void foo() {
 x = function int(){...};
 y = function int(){...};
}
wouldn't compile because of conflicting function names. My guess is


the bug that got fixed.



Sep 01 2004