digitalmars.D.learn - How can I compile this?
- Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> Oct 14 2006
- rm <roel.mathys gmail.com> Oct 14 2006
- Tom S <h3r3tic remove.mat.uni.torun.pl> Oct 14 2006
- Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> Oct 14 2006
- Johan Granberg <lijat.meREM OVEgmail.com> Oct 14 2006
- rm <roel.mathys gmail.com> Oct 14 2006
- Lars Ivar Igesund <larsivar igesund.net> Oct 14 2006
- rm <roel.mathys gmail.com> Oct 14 2006
- Bradley Smith <digitalmars-com baysmith.com> Oct 14 2006
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
rm <roel.mathys gmail.com> 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
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
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
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
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
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
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
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
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
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
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