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

You can try this:

#define aspect _ugly_aspect
#include <allegro.h>
#undef aspect

it's quite ugly, but it might work.

Very clever of them creating an extension, which defines a word as new keyword likely being used in existing code I mean, why didn't they call it $aspect or something?

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).

Ever tried compiling RPG written in C using C++? 'class' (and 'new', too) are quite common there.

Thats why you always compile C code with a C compiler.

If I were you, I'd just sever the matrix code from Allegro. Do you really use it at all?

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..]

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.

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.

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.

The attached patch is enough, isn't it? I would akkept it.

Rotfl

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.

Just dump it in the compatibility layer for 4.3 and be done with it.

the #define aspect _blah_aspect-trick indeed works! tnx for that...
I had allready changed the sources myself. the only files needing change are :
matrix.h
math3d.c
in functions :
void get_camera_matrix(...);
void get_camera_matrix_f(...);
get_scaling_matrix_f(...);

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...
Hans

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
#define _asm __asm

Does anyone know which versions of MSVC support which of the _asm, _asm, and _asm variants?

MSVC6 supports _asm and __asm.