Hello everyone,

I wanted to get into allegro for a project. So I installed allegro and put in the following code:

But the problem is that I'm getting the following errors:

'al_init': identifier not found (r 7)
'al_create_display': identifier not found (r 9)
Incomplete type is not allowed (r 9)

Does anyone know how to fix this?
Kind regards

If you followed the typical pattern of installation, then your include line for allegro should use angled brackets <...>.

No, don't use angle brackets use quotes and it should be telling you the header was not found. It's allegro5/allegro.h .

What's wrong with using angle brackets?

You have a couple problems:

#include "allegro5/allegro5.h"

should be:

#include <allegro5/allegro5.h>

The same is true for #include "stdafx.h", that should be #include <stdafx.h>. You should only use quotes for local files you are loading from the same folder your other game source code files are in.

Also, your line;

ALLEGRO_DISPLAY disp = al_create_display(100, 100);

should be...

`ALLEGRO_DISPLAY *disp = al_create_display(100, 100);`

as al_create_display() returns a pointer.

So in summary, this is what your code should look like...

#include <allegro5/allegro5.h>
#include <iostream>
#include <stdafx.h>
   
int main(int argc, char** argv)
{
 al_init();
   
 ALLEGRO_DISPLAY *disp = al_create_display(100, 100);
  
 return 0;
}

Nonono. Angle brackets are for system includes and you're all missing the point there's an extra 5 in his header include line.

You're right about the extra 5, wrong about the angle brackets. The angle brackets indicate to load from the path in your setup. In my own setup in Code::Blocks I have added in a separate directory for library includes. So I use angle brackets for them.

Quotes are used for local files which are not in your include path in your preferences etc.

This is my includes for Allegro for my DP2 game; works just fine.

#include <allegro5/allegro.h>
#include <allegro5/allegro_font.h>
#include <allegro5/allegro_ttf.h>
#include <allegro5/allegro_native_dialog.h>
#include <allegro5/allegro_image.h>
#include <allegro5/allegro_primitives.h>
#include <allegro5/allegro_physfs.h>
#include <allegro5/allegro_audio.h>
#include <allegro5/allegro_acodec.h>
#include <allegro5/allegro_opengl.h>
#include <physfs.h>

So he just needs to remove the extra 5 and make certain the location of the library is in his include path.

From MSDN...

Quoted form
-----------
The preprocessor searches for include files in this order:
1) In the same directory as the file that contains the #include statement.
2) In the directories of the currently opened include files, in the reverse order in which they were opened. The search begins in the directory of the parent include file and continues upward through the directories of any grandparent include files.
3) Along the path that's specified by each /I compiler option.
4) Along the paths that are specified by the INCLUDE environment variable.

Angle-bracket form
------------------
The preprocessor searches for include files in this order:
1) Along the path that's specified by each /I compiler option.
2) When compiling occurs on the command line, along the paths that are specified by the INCLUDE environment variable.

By your own post, it doesn't matter if he uses "" for system / allegro includes.

But I've always been taught <> for sys libraries. "" For local.

It just appears local, then searches system libs if it can't find it.

You guys LOVE to argue and debate. LMFAO Hey, do what ever fucking works. Wow.

NO. ONLY DO IT MY WAY. EVERY ONE ELSE IS WRONG.

Brackets <...> are what you should be using for your allegro includes.

Your projects shouldn't be in your libs path and allegro (whatever version you're using) shouldn't be in your project's path. You're free to do it wrong if you want, of course.

No. Just no. Allegro should never be installed to your compiler or your system directories. Period. Which means it should be treated as a local file, with the include directory specified.

Well sorry Edgar, but putting "PERIOD" in there doesn't make it final!!!

My Allegro install is NOT IN MY COMPILER'S SYSTEM FOLDER! It is a totally separate folder! As should everyone else's if you want to avoid problems.

In my own setup my compiler is in "C:\MINGW32", my libraries I add to my system like Allegro, SDL2 etc... are all in "C:\MINGW_DEV_LIBS". I use Code::Blocks as my IDE and on it,. I go to SETTINGS->COMPILER then select the "SEARCH DIRECTORIES" tab and add "C:\MinGW_Dev_Lib\include" to my "COMPILER" tab and "C:\MinGW_Dev_Lib\lib" to the "LINKER" tab which also contains the relavant "C:\MinGW32" folders.

I then add Allegro 5 with: #include <allegro5/allegro.h>

THAT is how you properly do it. You can also add in separate folders for your lib in a similar way for each project. There is a similar way to set this up with Visual Studio.

I can't believe you don't know this. I think you just like to argue endlessly.

Okay Neil, answer this. How do you include cmath? Do you use quotes or brackets? I would hope your answer would be brackets, because it's a system library. How is Allegro a system library? So why should I use angle brackets?

This is retarded but it works :

#include "cmath"
#include "cstdio"

int main(int argc , char** argv) {
   
   printf("sqrt(3) is %f\n" , sqrt(3.0f));
   
   return 0;
}

Likewise this is retarded, but it works as well :

#include <allegro5/allegro.h>

But the appropriate way to include a library in your code is to use quotes, unless it is a system library.

I use square brackets, like:

#include [allegro5/allegro]

which doesn't compile at all, but its my right to do what I want regardless of the correct way, so suck it.

Brackets are overrated. I just stares at my compilers until it reads in my mind the libs I want.

You could argue about this, or you could read the standard.

Or you can do what Dizzy does, which at least is consistent across all known platforms.

The standard says that there is no standard for what to do with either <> or "". It's implementation defined.

Here's what gcc says...

You can use whatever you want and it will work, but allegro is not a system header nor is it a system library, so it should not be treated as such.

The reason why `#include ""` works, according to the standard is because when it fails (fails to find any local files), than it switches to the <> method. So the reason why quotes work for you is because according to the standard, it will use the angle brackets method when the quotes FAIL, which according to most of the standard implementation, it WILL fail every time as it will not find the file locally and so will switch to searching using the angle brackets method, which searches system folders where the compiler exists and any other you included in setup (which is what I do).

But do it the way you wish, whatever, but don't sit there on your high horse saying "NO, JUST NO" every time someone is trying to HELP!

This is the correct answer

Now it looks like Obj-C ;P

The point is, in the old days it was considered fine and fair practice to install everything into your compiler's bin,lib,and include directories. Today we know that's nonsense because that's how version mis-matches get created. Everything should be installed separately from your compiler. If it didn't come with your compiler, then chances are that it doesn't belong there. This also allows you to hot-swap versions of the libraries you use depending on a simple -I directive. The fact that both <> and "" search these folders doesn't matter. To be strict and fair, <> shouldn't search those folders. When you specify "" you are saying this file is NOT a system file, so categorically it shouldn't be searching in system directories! ;P

I always use double white space to mean single quotes, and triple white space to mean double quotes, and then I have a pre-processor stage convert them at compile time.

That way, I only have to use one key, space. It's way faster.

You might like the Whitespace programming language then.

Okay smarty what does six spaces mean?

It means tab!

#include <allegro5\allegro.h>

I use quotes only for the files in my project. Otherwise, I use <>.

That is the most common way to do things. I have never actually seen it done any other way. There's no reason to if you set up your paths properly.