I'm unable to even get it to compile on Mac.

Compiling with debugging, I get a crash within main.cpp, on the call to "langton.start();", it giving me the error:

(gdb) r
Starting program: /Users/onlinecop/programming/temp/allegro/602869/LILACA/lilaca 
Reading symbols for shared libraries ...............................................................................+ done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xb0001a70
[Switching to process 3049 thread 0x3213]
0x00003ba7 in _mangled_main () at main.cpp:42
42              langton.start();
(gdb) kill
Kill the program being debugged? (y or n) y
Current language:  auto; currently c++
(gdb) q

(My line numberings are different because of some stuff I played around with to get it to work.)

Using Allegro 4.2.3.

It's intended to fully qualify the variable, which makes the code more clear and also avoids subtle bugs like C::aab versus ::aaa (AKA, a global variable aaa). It's easy to accidentally type the latter and the compiler won't complain if it's compatible with the context it's used in. If you want to be really sure, you can always go with this->C::aab.

The only arguments for "this->" that I can agree with are:
- When writing an example, showing that we're referring to a class member.
- When using an IDE with autocompletion, getting the IDE to provide you just the class members.

I thank you all for so fast replies!

I know that counting is starting from 0 (I programmed before in asm, php, some bash and perl),
but I had segfaults when it was 0 (I dont know why),
now is ok when I hanged i<=800 to i<800.
But thanks for advice.

I tried to compile my code under windows (on virtual machine),
after some time with troubles with compilation (windows is very strange system)
I run dbg and changed some of my code:

void Field::reset() {
    for(unsigned int i=0; i<800; i++) { // i=1 and i<800 (from <=800)
        for(unsigned int z=0; z<800; z++) { // same here
            this->set_fill(false, i, z);
        }
    }
    this->filled_cells=0;
}

same for Field::draw_dots.

I also received segfault here (Info::draw_info):

textprintf_ex(buffer, font, 10, screen->h-20, makecol(255,0,0),-1, "To leave press [ESC]");

So I changed "screen->h-20" to "780" (I am not planning changing resolution in future).

Last error is appearing here (at System::start()):

blit(this->buffer, screen, 0, 0, 0, 0, 800, 800); // Update screen

I have no ideas why there is segfault.
Any ideas?

EDIT:
about "this->",
so I should use it always, but only when needed?

Thanks for your corrections Dario_ff,
but I still have segfault in same place:

By the way, it's very interesting method you used in conditions in loops:

for(unsigned int i=0; i!=FIELD_SIZE_W; i++)

I'd imagine that within the processing pipeline, the advantage of using != is that it simply checks for equality then negates that result; much faster than the <, which subtracts the one from the other and checks whether that sets the overflow/underflow bit, the values are still unequal, etc.

The disadvantage is that if you happen to 'hop' over the value you were checking for, you've got either 2^32 or 2^64 more loop iterations to go through before it overflows back to 0 and starts again. Of course by then, you've either segfaulted your application or unplugged your computer for the length of time it's taken...

No. It shouldn't. In the off chance the value goes over the right hand side, it will keep looping till it wraps around. it SHOULD be <. So it will always break when i is equal to or greater. Instead of only when it equals the right hand side.

That makes no sense.

I'm dubious about the statement on '<' being "much slower than '!=' in the first place (anybody got real-world facts on assembler instructions JNE and JL ?)

And in any case, I find it a bad idea(tm) to teach a self-called "newbie C++ programmer" to alter his way of coding an expression. Not before he has completely mastered structured programming; and counting "from 0 included to MAX-1 included" is really part of the basics.

Not in any meaningful way. Maybe one or two clock ticks per iteration; on a 2GHz dual-core CPU, that's half a nanosecond. Less than the time a photon travels from the screen to your eye.

First of all, the loop overhead is negligible in 99% of all the loops you'll ever write. One or two extra clock ticks on a loop that takes thousands of clock ticks per iteration is literally nothing. If such a loop turns out to burn too much CPU time, see if you can get away with less iterations, with less calls to the loop itself, or with a better algorithm. Only if you are already using the best possible algorithm as sparsely as possible, and you are still having performance problems, consider optimizing code. But before doing so, give the compiler a fair chance of doing it for you (-O2), and when done, be sure to profile so you can be sure the code is really faster. You'd be surprised.

Consider the following code:

for (int i = 0; i != 10; ++i)
  foobar(i);

Is this safe or not? You'd be tempted to say "yes", but what if foobar is defined like so:

void foobar(int& i) {
  ++i;
}

It is not an off chance, it is a very realistic possible source of bugs that are extremely hard to find.
The only situation where I'd use != over < to iterate is with STL iterators: These often don't have a less-than comparison operator, and incrementing some_container::end() does nothing, so the iterator cannot possibly overrun (it can invalidate though, but that is a different question).

This approach is known as shotgun debugging and generally considered bad practice.

Ok, I haven't looked at the whole code, but I made some other changes.

And because of the massive bitching around here, I replaced != with < (but I think that just for pissing all of you I'll put !(i>=FIELD_SIZE_W)

I think the error you have in your VM is because it doesn't support your res. Remember the desktop res must be >= to the window's res. Remember you have a square, 800x800, and it's possible your VM res is lower than that.

Audric,
I am newbie programmer in C++, but before I coded for many years
( I remember time when I was writing BASIC code at C64).
I used 1, because 0 caused segfaults on VM (on my GNU/Linux was work).

Dario_ff,
it's not VM fault.
I have VMWare with vmtools installed.
Default resolution is 1280x768 and... WAIT.
I completly forgot about it!
You have right, it's VM fault.
Thank you very much, now my program is working propertly!

Thank you all for helping me with segfaults and others!

Can we make a little summary?
I mean what faults I made in obiect-oriented model (with classes and others),
"this->" problem and others like that.
Here is final, working code:
http://www.allegro.cc/files/depot/2285/lilaca-1.0.tar.gz

EDIT:

I had to change a few other things on my system so it'd work. Notably, you're still creating your screen dimensions at (800, 800) and setting your ant's initial position to (400, 400). But you've defined your array to be 800x600 through use of FIELD_SIZE_W and FIELD_SIZE_H.

So change within your langton.cpp the lines:

    set_gfx_mode(GFX_AUTODETECT_WINDOWED, 800, 800, 0, 0);

to

    set_gfx_mode(GFX_AUTODETECT_WINDOWED, FIELD_SIZE_W, FIELD_SIZE_H, 0, 0);

and both the ant's position and the this->buffer dimensions to the new screen dimensions:

    this->buffer = create_bitmap(800, 800);
    ...
    this->ant.set_position(400, 400); // Center of view

to

    this->buffer = create_bitmap(SCREEN_W, SCREEN_H);
    ...
    this->ant.set_position(SCREEN_W / 2, SCREEN_H / 2); // Center of view

Then if you change your dimensions again, everything will be fine.