hello my gamername is lethal_beast i am 15 years old, i love gaming (sometimes programming). the game i play most of the time is cod4
i am fairly new to programming apart from knowing some basics of c++ (still not really good). i started this weekend with installing allegro, reading the wiki and trying to understand the code.
here is a question:

in the following code (copied from wiki) i cant remove the first if statement( if(!al_init()) ) why is that i thought the if (!....) was for checking if something works so you can display the error when it doesn't works.

i can remove the if(!display) though.

#include <stdio.h>
#include <allegro5/allegro.h>

int main(int argc, char **argv){

ALLEGRO_DISPLAY *display = NULL;

if(!al_init()) {
fprintf(stderr, "failed to initialize allegro!\n");
return -1;
}

display = al_create_display(640, 480);
if(!display) {
fprintf(stderr, "failed to create display!\n");
return -1;
}

al_clear_to_color(al_map_rgb(0,0,0));

al_flip_display();

al_rest(10.0);

al_destroy_display(display);

return 0;
}

al_init() needs to be called to call most allegro functions. If you want to skip the check (but why would you? checking for errors is a good thing!), just remove the `if(! )` and the `{}` block below it.

ty for the help
the reason why i am asking this is because i want to understand which parts run the program and which parts are only optional.

The only thing you do not really need is the al_rest call. This will make everything pause for 10 seconds.

You may also want to look at other al_init_* functions because they are needed for sound, gamepad,ttf text drawing, and more.

It's there so the window doesn't close right away

It's a very basic example from the wiki.

In programming, everything is mandatory. The biggest "optional" stuff you can possibly get is omitting explicitly setting up values that already set by default if they satisfy you. However, you shouldn't rely on that things will work on their own, so explicitly stating virtually everything is not only a good practice, but also a failsafe from unexpected behavior in underlying system.

------

Also, since you're only learning, I suggest you to use C rather than C++. It's (vastly) easier to learn and to work with, which is a big deal for you right now. (Not that simplicity is a bad thing: C++ is overcomplicated lightyears over the top, and all of the complexity hardly gives any benefits while certainly making your life harder.) Examples are written in C, too, which is another reason for you to use it.

i will start looking up some c tutorials from youtube and internet.
if have any tips about learning C certain tutorials,videos or maybe a book please post.
what is the biggest difference between C and C++?
allegro runs on C and C++?

C is, for the most part (that has changed a bit since c++11, and c99, there are more differences between the two than there were) a subset of C++. C doesn't have classes, exceptions, or templates. C is procedural programming at its finest.

In brief:

C

C++

C is not a subset of C++, because C++ can't compile C code. Technically, you could force it to do so using specifically coded programs, but that's not valid argument.

Allegro runs on C.

As opposed to C++, C lacks of syntax sugar. That's about it. They do everything similarry and capabilities are exactly the same, but C does it straightforward while C++ uses complicated and (for the most part) confusing patterns.

http://www.cprogramming.com/tutorial/c/lesson1.html

Just make sure you don't treat programming as magical stuff that you "copy from a book and then it works". All there is to program execution is juggling bytes, numbers. Everything is the number, one way or another.

C has terrible support for object oriented programming, while its baked into C++. If you are getting started you may not want to deal with OOP just yet, but when you are, don't do it in C.

You're really asking which language should you use with Allegro. You can use either C or C++, its the same.

Having done a lot of OOP, I'd feel closer to the opposite. C++ uses straightforward patterns (except for the whole header/source separation, but C has that problem too), but C makes you jump through unnecessary hoops.

It really just depends on what you're comfortable with and what you want to do, though. I'd probably recommend C++ over C if only for the fact that it's more similar to the other currently popular languages than C is.

Code 100% standard c89, and any decent C++ compiler can compile it.

Everyone knows this one:

typedef int foo;
struct foo { int x; };

I was surprised by this one: (technically it compiles)

printf("%d\n", sizeof('a'));

I can't say I've seen that. Or considered it.

Also: Works in C, but not as C++^[1]. Or even this works in C, but not in C++^[2].

Is C++ backwards compatible with C?

For all in-tents and purposes, I'd agree that C is a subset of C++. If your C program isn't compilable as C++, it's probably poorly written. The second example I posted may have it's uses, but it's a fairly trivial fix, plus I think most people write prototypes anyway.

--------------------------------------------
Appendix: Valid C, but invalid C++:

//[1]
void foo() { printf("ok\n"); }

int main() {
   foo(1, 2, 3, 4, 5);
   return 0;
}

//[2]
int main() {
   foo();
   return 0;
}

void foo() { printf("ok\n"); }

Oh fine. I did say "for the most part". Many of the things that don't work in C++ that do in C, you probably shouldn't do normally anyhow.

I do normally cast pointer types, in my data structures handling. You wouldn't write it's own stack implementation for every possible data type, would you? Provided typecasting and pointer math hardly (if any) takes more processing than direct approach. And silly C++ with it's silly restrictions will complain about casting issues so hard that the code won't work. Way to go simplicity, Jeff.

What makes any surprise to you? 'X' would be a char constant, what's confusing with getting size of a char constant?

Then I think you'll be surprised as well.

For some reason, 'X' is an int constant in C.

Back on topic i.e. relevant to the original poster

What you've done is found your first example of code that isn't written as intuitively as it could be.

To explain, the way 'if (A) B' works is:

1. Execute A.

2. If the result was true / nonzero / non-null, then execute B.

There are two ways of approaching this. Some people always try to make sure A has no side-effects and is (as you expected) merely a check.[1] Other people expect that everyone understands the subtleties of 'if', and will happily set the condition (A) to an important command that must be executed, and then check its result using the surrounding 'if' construct.

The first approach does lead to more verbose code that takes a bit longer to write, but it also makes your kind of misunderstanding less likely. This is a trivial example and one you'll get used to quickly, but there are lots and lots of other ways programmers can confuse each other, many of them far harder to figure out

Hope that all makes sense

[1]
[EDIT] Added this footnote. Here's an example of how such people would write the above code:

bool succeeded = al_init();
if(!succeeded) {
  fprintf(stderr, "failed to initialize allegro!\n");
  return -1;
}

(Note 'bool' is C++ - in C it won't work and you'll have to write 'int'.)

Well, it did treated it as an unsigned int. This is not entirely what I expected, but it's still perfectly reasonable: unless you trying to save space, you choose an int, because it would perfectly fit the register, naturally keeps byte alignment and the bus will probably fetch it faster from RAM. Since this letter would end up directly in registers, there's no need to save space whatsoever, so it's 4 bytes. Also, it allows using unicode characters rather than ASCII characters.

For bool in C, shouldn't char be used instead of int? Why use 4 bytes when you can use 1.

C doesn't define boolean type. The if block only recognizes zero and non-zero value. You could use char for bool as well as int, you could as well use bithacks to place 8 booleans into a single char. Myself, I hardly ever use booleans. Instead, I use goto jumps, which is the basic reason for most people to even use booleans - to avoid gotos because "they're bad" and "you can't use them". ------ But when I do, it's an int bitfield.

@jmasterx: the registers are 4- or 8-byte and often for the computations chars, shorts etc. will be converted up to the architecture dependent size. If it makes any difference at all, any type smaller than the machine word will be slower to handle, however if you store lots of such values, the size gain factor of 4 or 8 may turn out relevant. In the general case it's not.

@Raidho36: note that C99 adds <stdbool.h>. It's not built into the language, but it's standard and should be portable (if you use code that already messes with redefining of the "true", "false" or "bool" symbols, you may run into surprises).

Yeah I know, but I don't use C99. It doesn't have anything I'd wanted to have over default feature set. Also I don't mess with those values, I simply use whatever is capable of evaluating into zero and nonzero when I need it to. And as I already mentioned, I hardly ever need a boolean type and when I do for the most part I only use boolean values as a part of bitfields.

K&R shake their beards with approval, and I too think this is the proper way of doing stuff in C. That was just some useless knitpicking ;-)