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:
$ 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