Change Sprite foo("tank.bmp"); to Sprite *foo = new Sprite("tank.bmp");, remove allegro_exit (you don't need it), and add delete foo; before returning from main.

Actually, he could have replaced the -> with a period, like

draw_sprite(screen, foo.sprite_img, 200, 200);

Allthough the new/delete is to prefer and should be a habit.
It is okay to declare/create a class like he did in the first place, but it will only be available in the scope of that function.

I know, I was just saying he could with the code provided

You basically have two choices, each has its own merits and drawbacks. You can either use multiple images, blitting the appropriate one at the appropriate time, or you can gather them all together into a single sheet, and blit the portion of the image that contains the correct frame.

Regardless of which one you choose, you need a more sophisticated object, one that defines a number of frames that your game can pick from. If you're like me and prefer a data-driven design, you can store all that information in a separate file and build a loader into your sprite class; that's a lot more flexible, and allows a game designer (if you have one) to create sprites without your intervention. However, if you're all alone and embedding the data into your code doesn't bother you, continue doing what you're doing, except load up several images into a single sprite - perhaps with a variable argument list:

It wouldn't have an adverse effect whatsoever - I just wouldn't personally do it that way. That's just me. If using an animation is cutting your speed in half, though, you're doing something wrong (maybe doing it twice).

It's a pointer to a pointer. If you're not very familiar with pointers, you need to get familiar with them very soon. If you have an array of objects (or anything else), and you don't know how large that array will be, you have to use a dynamic array.

So this:
int fixed[10];
becomes this:
int *dynamic = (int *)malloc(10 * sizeof(int));

That works for primitive types, but a BITMAP must be referred to with a pointer to begin with, since that single object itself is created dynamically (plus you don't want it to go out of scope and disappear). But because you potentially need more than one, you point to pointers.

So this:
BITMAP *fixed[10];
dynamic[0] = load_bitmap("bitmap0.bmp", NULL);
dynamic[1] = load_bitmap("bitmap1.bmp", NULL);
...
becomes this:

BITMAP **dynamic = (BITMAP **)malloc(10 * sizeof(BITMAP *));
dynamic[0] = load_bitmap("bitmap0.bmp", NULL);
dynamic[1] = load_bitmap("bitmap1.bmp", NULL);
...

Obviously I'm oversimplifying and throwing out error checking, but that's the gist of it. This is really, really fundamental. If you don't fully understand pointers you'll run into trouble very quickly. Find some tutorials, buy a copy of K&R, do whatever you have to do, but you definitely need to be very comfortable with this sort of construction.

This suggestion may not be what you looking for, but this is what I have ended up doing in my project.

If you want to go OOP simply create a class for everything. So you would end up having a class for Frames, Animation, AnimationMgr, Objects, Tiles, Sprites, etc.

Think of this way, Tiles and Sprites are different, but they share common attributes and functions. Therefore, create an Object class and derive from it Tile and Sprite.

Object class would have an Animation Manager that could contain more then one animation. After all, a sprite would have a number of animations, such as waling, shooting, dying, etc. Tiles can also have multiple animations based on the events.
The Animation Manager (like the name says) manages animations. The Animation class only worries abut frames that build up this animation. While frame class contains the information in regards to a frame.

Frame could have an ID, Name, Delay, Counter, BITMAP
Animation then can have a list or an array of frames, current frame, etc.
Animation Manager can have a list of animations, current animation, etc.
Object has Animation Manager, along with other attributes.
Tile inherits Object class and implements its own attributes and functions.
Sprite, just like a Tile class does the same thing with a difference of its own needs.

From that you can then derive a Player class, Enemy, or whatever else you may need. Best of all, each derived object will be able to handle animations just like any other object.
If you feel that some of the Objects will not be in need for an animation, then all you do is create a single Animation with a single frame and that is it.

Game Programming All In One 2e? Me too. I recall it saying that the rotate and fliping algorithisms are long and complex. Maybe you should create all of the images at runtime, and then draw_sprite the right one. Use more of his code, it works. The BITMAP array that holds animations actually works. If you want, I'll post my sprite handler, also a class, but closer to what the book said.