www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How can I compile this?

reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit

$ make
bud rdwars \
                -w -op -debug -gc \
                -od.obj \
                -Xstd \
                -L-ldl
map.d(43): enum Direction is forward referenced
make: *** [rdwars] Error 1


PLEASE. I just can't go through ...

Only dmd/phobos + bud should be needed.
Oct 14 2006
next sibling parent rm <roel.mathys gmail.com> writes:
Dawid Ciężarkiewicz wrote:
 $ make
 bud rdwars \
                 -w -op -debug -gc \
                 -od.obj \ 
                 -Xstd \
                 -L-ldl
 map.d(43): enum Direction is forward referenced
 make: *** [rdwars] Error 1
 
 
 PLEASE. I just can't go through ...
 
 Only dmd/phobos + bud should be needed.

moving the enum Direction declaration from map.d to cell/movable.d let's me compile it, but it gives a linker error (dmd v0.169 on Gentoo Linux). rm
Oct 14 2006
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Dawid Ciężarkiewicz wrote:
 $ make
 bud rdwars \
                 -w -op -debug -gc \
                 -od.obj \
                 -Xstd \
                 -L-ldl
 map.d(43): enum Direction is forward referenced
 make: *** [rdwars] Error 1
 
 
 PLEASE. I just can't go through ...
 
 Only dmd/phobos + bud should be needed.

I fixed it by putting Direction in its own module, 'direction' and importing where necessary. This essentially moves the Direction enum out of an import cycle, which seems to be the root of the problem. Actually, cyclic imports can cause many sorts of problems and it's generally wise to avoid them altogether Powodzenia! ;)
Oct 14 2006
parent reply Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Tom S wrote:

 Dawid Ciężarkiewicz wrote:
 $ make
 bud rdwars \
                 -w -op -debug -gc \
                 -od.obj \
                 -Xstd \
                 -L-ldl
 map.d(43): enum Direction is forward referenced
 make: *** [rdwars] Error 1
 
 
 PLEASE. I just can't go through ...
 
 Only dmd/phobos + bud should be needed.

I fixed it by putting Direction in its own module, 'direction' and importing where necessary. This essentially moves the Direction enum out of an import cycle, which seems to be the root of the problem. Actually, cyclic imports can cause many sorts of problems and it's generally wise to avoid them altogether Powodzenia! ;)

Well this sucks. How can you people write real programs? If'd be forced to put every enum in it's own file I'll end up with mess and no hair on my head. I'll do as you told me. But I will not start any new project in D. I'll wait until D is ready. What is the point of having fancy features where simple things are messed up. :/ Dzięki. :) Dalej powinno być z górki ... - oby.
Oct 14 2006
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Dawid Ciężarkiewicz wrote:
 Well this sucks. How can you people write real programs? If'd be forced to
 put every enum in it's own file I'll end up with mess and no hair on my
 head.
 
 I'll do as you told me. But I will not start any new project in D. I'll wait
 until D is ready. What is the point of having fancy features where simple
 things are messed up. :/
 
 Dzięki. :) Dalej powinno być z górki ... - oby.

Or you could put all your enums in the same file. I don't think that cyclic dependencies is such a good idea even when it works, if one finds oneself with that I would merge the modules importing each other together and if the become to big divide the in some way that don't create a cycle.
Oct 14 2006
parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Johan Granberg wrote:
 Or you could put all your enums in the same file.
 I don't think that cyclic dependencies is such a good idea even when it
 works, if one finds oneself with that I would merge the  modules
 importing each other together and if the become to big divide the in
 some way that don't create a cycle.

This is sometimes (quite frequent if you use OOP) just impossible. You got an parent-object, that holds pointers to many children of different type. And each children have only pointer to it's parent-object to interact with it, and not to each other. And modules are for humans, not for compilers. It's programmer who should benefit from dividing things into logical parts (by his and only his reasons). I could just put everything in single module ... or event do it using bash, cat and grep. But this is just ... horrible. In C++ I don't have to think about what is creates cyclic dep. and what does not - I can divide everything into pieces as I like. And I never came to any problems with nesting classes or deps problems. (I just have other terrible problems that C++ features <g>). I can't understand why D users can live with such bugs and even say "I don't think cyclic deps are good idea" (please don't take it personal :) ). Cyclic deps problems are here for a loooooong time and people seems to be happy when something that helps only notation - like array literals - or only templates is added. And for last three months I just feel like intruder that keep saying "cyclic deps. problem have to be fixed". While I can live with local notation problems, and without templates making miracles in compile time, I just can't move on with language that forces me to screw up my program logic because of something that throws forward reference errors each time I'm doing anything.
Oct 14 2006
prev sibling parent reply rm <roel.mathys gmail.com> writes:
Dawid Ciężarkiewicz wrote:
 Tom S wrote:
 
 Dawid Ciężarkiewicz wrote:
 $ make
 bud rdwars \
                 -w -op -debug -gc \
                 -od.obj \
                 -Xstd \
                 -L-ldl
 map.d(43): enum Direction is forward referenced
 make: *** [rdwars] Error 1


 PLEASE. I just can't go through ...

 Only dmd/phobos + bud should be needed.

I fixed it by putting Direction in its own module, 'direction' and importing where necessary. This essentially moves the Direction enum out of an import cycle, which seems to be the root of the problem. Actually, cyclic imports can cause many sorts of problems and it's generally wise to avoid them altogether Powodzenia! ;)

Well this sucks. How can you people write real programs? If'd be forced to put every enum in it's own file I'll end up with mess and no hair on my head. I'll do as you told me. But I will not start any new project in D. I'll wait until D is ready. What is the point of having fancy features where simple things are messed up. :/ Dzięki. :) Dalej powinno być z górki ... - oby.

cyclic dependencies should work agreed, but I couldn't easily follow the dependencies you created in your program. even more, all your import are plain imports :-) you'd better use "private import ..." that prevents symbols imported in a module for it's internal implementation to leak through to other modules. an example: module A import module B module B import module C => all public definitions in module C are now available in module A => the definitions in C are available in B and in A or: module A private import module B module B private import module C => only symbols defined in B are available in A => C symbols are not available in A => you wish C in A, do a new private import I'd say roel
Oct 14 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
rm wrote:

 even more, all your import are plain imports :-)
 you'd better use "private import ..."
 that prevents symbols imported in a module for it's internal
 implementation to leak through to other modules.

Imports are private by default, now. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Oct 14 2006
parent reply rm <roel.mathys gmail.com> writes:
Lars Ivar Igesund wrote:
 rm wrote:
 
 even more, all your import are plain imports :-)
 you'd better use "private import ..."
 that prevents symbols imported in a module for it's internal
 implementation to leak through to other modules.

Imports are private by default, now.

thx, and making them public? public import std.stdio; ??? roel
Oct 14 2006
parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
rm wrote:

 Lars Ivar Igesund wrote:
 rm wrote:
 
 even more, all your import are plain imports :-)
 you'd better use "private import ..."



I tried. Didn't help.
 that prevents symbols imported in a module for it's internal
 implementation to leak through to other modules.

Imports are private by default, now.

thx, and making them public? public import std.stdio; ???

Using public makes them public. :) I use public imports almost only when class is derived from other class. Module that want to use new features of child will probably want to use old ones from it's parent.
Oct 14 2006
prev sibling parent reply Bradley Smith <digitalmars-com baysmith.com> writes:
Dawid Ciężarkiewicz wrote:
 $ make
 bud rdwars \
                 -w -op -debug -gc \
                 -od.obj \
                 -Xstd \
                 -L-ldl
 map.d(43): enum Direction is forward referenced
 make: *** [rdwars] Error 1
 
 
 PLEASE. I just can't go through ...
 
 Only dmd/phobos + bud should be needed.

How about moving the enum Direction above the imports? Like the following snippet: ... module map; enum Direction { UP, DOWN, UP_LEFT, UP_RIGHT, DOWN_LEFT, DOWN_RIGHT } import player; ... For me, this compiles, but then gives link errors. Bradley
Oct 14 2006
parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
Bradley Smith wrote:

 Dawid Ciężarkiewicz wrote:
 $ make
 bud rdwars \
                 -w -op -debug -gc \
                 -od.obj \
                 -Xstd \
                 -L-ldl
 map.d(43): enum Direction is forward referenced
 make: *** [rdwars] Error 1
 
 
 PLEASE. I just can't go through ...
 
 Only dmd/phobos + bud should be needed.

How about moving the enum Direction above the imports? Like the following snippet: ... module map; enum Direction { UP, DOWN, UP_LEFT, UP_RIGHT, DOWN_LEFT, DOWN_RIGHT } import player; ... For me, this compiles, but then gives link errors.

That is funny and interesting solution. I'll try it. :) Maybe I'll just put all my imports at the end of files. :D
Oct 15 2006