![]() |
|
"aspect" keyword blocks use of AspectC++ |
Hans Van Broeckhoven
Member #5,529
February 2005
|
a grep through allegro's include files showed me the use of the variable name 'aspect' in the following file : matrix.h. This makes allegro completely unusable by the aspectc++ weaver (www.aspectc.org) since aspect is the keyword for defining aspects (as class is a keyword for defining classes in regular C++). this is a big bummer for my thesis-project |
Kitty Cat
Member #2,815
October 2002
![]() |
You can try this: #define aspect _ugly_aspect #include <allegro.h> #undef aspect it's quite ugly, but it might work. -- |
Elias
Member #358
May 2000
|
Very clever of them creating an extension, which defines a word as new keyword likely being used in existing code Anyway, try this: [Edit: beaten by KittyCat] Or if there's no way to work around it like this, I wouldn't mind a patch against Allegro to change it, after all we had to change paramters named "y1" and "index" for similiar reasons (although libc is a much stronger reason to change things than aspect). -- |
Krzysztof Kluczek
Member #4,191
January 2004
![]() |
Quote: Very clever of them creating an extension, which defines a word as new keyword likely being used in existing code
Ever tried compiling RPG written in C using C++? ________ |
Thomas Fjellstrom
Member #476
June 2000
![]() |
Thats why you always compile C code with a C compiler. -- |
Thomas Harte
Member #33
April 2000
![]() |
If I were you, I'd just sever the matrix code from Allegro. Do you really use it at all? [My site] [Tetrominoes] |
Elias
Member #358
May 2000
|
Personally, I think we should put all the 3d + matrix code into an addon. But then, what about backwards compatibility and so on? Dropping backwards compatibility here would be a precedence for dropping it in other places, and so we'd end up trying to do Allegro 5, and history would repeat itself.. [Edit: That is, just removing it in his local copy might be a good idea..] -- |
Thomas Harte
Member #33
April 2000
![]() |
Quote: Personally, I think we should put all the 3d + matrix code into an addon. But then, what about backwards compatibility and so on? Why not drop it into a 'semi addon', i.e. an addon included in the core Allegro distribution and installed by default but one that may be disabled by issueing the correct commandline to make? The only precedent you'd set would be for people being able to not build the library with the bits they don't want if those bits are easy to sever. [My site] [Tetrominoes] |
Elias
Member #358
May 2000
|
Yes, making it modular. Definitely what we should do. In fact, it should already work.. simply don't include allegro.h, but directly the things you need, like allegro/base.h, allegro/graphics.h, and not allegro/matrix.h and allegro/3d.h and so on. -- |
HoHo
Member #4,534
April 2004
![]() |
Another way of doing it would be to predefine whatever #defines the headers define(e.g ALLEGRO_3D_H) one don't want to include prior to #including allegro.h. __________ |
Peter Wang
Member #23
April 2000
|
The attached patch is enough, isn't it? I would akkept it.
|
Raf256
Member #3,501
May 2003
|
Quote: Ever tried compiling RPG written in C using C++?
Rotfl |
Evert
Member #794
November 2000
![]() |
Quote: This makes allegro completely unusable by the aspectc++ weaver (www.aspectc.org) since aspect is the keyword for defining aspects (as class is a keyword for defining classes in regular C++). While I think it's nice to have a workaround for this, I do think that it's not really Allegro's fault for not working on a platform it doesn't support at the moment. Quote: Personally, I think we should put all the 3d + matrix code into an addon. Just dump it in the compatibility layer for 4.3 and be done with it. |
Hans Van Broeckhoven
Member #5,529
February 2005
|
the #define aspect _blah_aspect-trick indeed works! tnx for that... Now there's still some other stuff necessary to make ac++ work with my allegro-program, but none of it is allegro's "fault"... Tnx for the help... EDIT: In the meantime I have an allegro-program working together with aspectc++, but had some problems also with _asm used in \ALLEGRO\include\allegro\platform\al386vc.h. I've been told the _asm keyword is obsolote and MSVC only supports it for compatibility with previous versions (I used the free VC2003Toolkit (VC 7.0) command line compiler). supported is : asm, _asm or _asm so i heard. this can ofcourse be easily solved by adding |
Peter Wang
Member #23
April 2000
|
Does anyone know which versions of MSVC support which of the _asm, _asm, and _asm variants?
|
Chris Katko
Member #1,881
January 2002
![]() |
MSVC6 supports _asm and __asm. -----sig: |
|