There might be more experts than you'd think. On another forum, there is an user who essentially knows the C++ standard by heart. And as far as I know, he is neither part of the C++ standard committee nor is he working for a C++ compiler vendor.
I would expect to find many more people such as him in these two groups.

Even so, one doesn't have to know everything about a subject to get away with calling oneself an expert these days - [i]far[/i] from it, in fact (unfortunately).

Why is it prohibited to buy a C++ book where you live?
In any case, there is a fairly good book available online for free (Thinking in C++):

Then you should specify which step you don't understand.

Well, it looks like you're having some reading about bitwise operations to do.
So you should do that first.

Well, suppose you have three bitsets (your Huffman sequences) with values 2, 5 and 4 which are 2, 3 and 4 bits in length, respectively.
In binary these are:

The code would now string them together using bitwise operations as follows:
0100 101 10

As soon as there are 8 bits, they're written to the file - so we have:
0 10010110
The right 8 bits are written to the file and removed, which leaves us with

If there's nothing else to write to the file, seven filler bits must be added, so that a full byte is reached.

The basic idea is that you combine your bit sets until you have 8 bits you can write to the file.

In semi-pseudo code:

[CODE]uint bitsUsed=0;
uint64_t combinedSet=0;
const uint64_t bitSetToAdd=1234;
const uint bitSetLength=12;
while (bitsUsed>=8)

Don't forget to "flush" any remaining bits that didn't add up to one byte when you're done writing.

Reading is basically the reverse of that; but less convenient - you'll have to read it bit by bit, since you don't know beforehand how long the Huffman sequence will be.

Never mind, apparently this is normal behavior on Unix systems and relies on the assumption that peak memory usage is not significantly higher than the average usage.

P.S. the edit limit could be slightly longer than it is now.

I must say that I'm surprised that this happens.
I know that memory management doesn't always return the pages to the OS immediately, but it seems that even if you create and delete 1 GB+ worth of objects, the memory is not returned to the OS, even after some time has passed (I waited about ten minutes).
It seems that this is true for all objects allocated with new. When deleting arrays created by new[], the memory seems to be returned to the OS immediately.
Doesn't this behavior cause high overall memory usage?

As far as I'm concerned, your code has a much more serious issue... the following:

[CODE] if (pixel[0] == 255)
if (pixel[1] == 255)
if (pixel[2] == 255)
return false;
} else {
return true;
} else {
return true;
} else {
return true;

can be written as:

[CODE]return pixel[0]!=255 || pixel[1]!=255 || pixel[2]!=255;[/CODE]
or if you prefer:
[CODE]return !(pixel[0]==255 && pixel[1]==255 && pixel[2]==255);[/CODE]

Why the unnecessary restrictions? Besides the linked list, you won't get around using all of these anyway and using a linked list should depend on whether a particular implementation you had in mind actually needs it.
Aside from that, it's not really that much of a challenge and especially not fun.
That's the kind of work one has to do every day anyway.

You give them every last detail of gameplay and the design of the interface. They'll need to know what your game world can contain, how the player can interact with it and any characters in it (such as talking, fighting). Each topic requires you to go more in-depth, so if there is combat, you'll need to explain the details of how it is supposed to work.
The story is largely irrelevant to them, as it mainly affects the game world, character interactions (dialogues), etc. That's not their job (unless you make it - but then you should hire game (world) designers or story writers instead). Programmers will just provide the tools that allow others to build said game world.

I'd like to point out that the OP is a troll who is just repeating the same procedure that he already went through on other forums using various names.
He's just testing how far he can push people before he finally gets banned.
If you look at his other threads, you'll see they follow the same pattern: he is "extremely confused" about something or another that requires an in-depth explanation, effectively aiming to waste people's time. It's likely that he is actually already a more or less accomplished programmer with a lot of time on his hands.

@spoonlicker: This might be a shot in the dark, but: you wouldn't have used the name "Avast" for extended periods of time a few years back, would you? This would totally make my day.

At its core, it's the same principle: for the client, it's simply playing a video stream.
The difference is that when streaming a game (or generally, a remote desktop), the buffer must be very small to allow fast reaction times. Even so, they are not as fast as when playing the game natively.

Counter-question: why can you watch YouTube videos without any problems even though you do not have a 210 mbps connection?
The answer is the same in both cases.

You still allocate the int variables dynamically, for which there is no reason.
If you find yourself writing the keyword new, you generally should stop and try to find good reasons why you [i]need[/i] to use new. If you can't, you shouldn't use it.
Doubly so when you find yourself writing delete. Due to RAII (which you aren't conforming to here), you rarely should have any manual deletes in your program, unless you're currently implementing a container class of some sort (and even then, it's not needed if you build it on other containers).

[CODE]string playerName[SIZE];
int score[SIZE];[/CODE]
You also should look up vectors.
The above both incurs an unnecessary limitation on the number of objects you can have and in most cases, it just creates lots of instances that are never actually used.

Dev-C++ is outdated, you should use a different IDE (such as Code::Blocks).
As for graphical libraries, SFML would be your best bet (assuming you're talking about 2D graphics). SDL is also popular, however it is a C library (of course, you can still use C libraries with C++ if you really want to).

Also, please use std::string and std::swap - this is the C++ forum after all.

This page has what you need to know about ar archives:

Start by extracting the three files from the .deb.
Then you can proceed with the important part, i.e. extracting the desired file(s) from the data archive.

[ICODE]return 0;[/ICODE] might be a good idea, no?
That requires you to fix the return type of function, though.
And you need to fix the the return type of main too, because it always must be int anyway.

Yes, you need the header queue.

This form of compression is called run-length encoding.
However, it performs quite poorly for most types of data.

Instead, you should look if any substrings already occurred earlier in the text and save a offset/size pair if they have. This is the general idea many popular compression algorithms are based on.

[QUOTE]Yes. My statement was incorrect. C99 allows const, previous versions did not.[/QUOTE]
const was introduced in C90, actually.

[QUOTE]I'd love to believe you but AD is stating otherwise.[/QUOTE]
No. I think your main problem is that you tend to misinterpret things people say - it's probably the same with your instructor.

[QUOTE="nbaztec"]I mean if we can just use const in C, then why use #define, off the top of my head, is it due to this?[/QUOTE]
Not at all, both variants are perfectly legal in C. In fact, you can even use non-constants as the array size since C99.
That #define is still used is probably because bad habits die slowly - const was added to C in 1990, but the language had been existing for quite a while until then.

nbaztec commented: Informative. +1

The relevant part of the C standard is in
[QUOTE]The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int

C does not have inheritance, so obviously there is no dynamic_cast either.

There are references in C++, but not in C.

Yes, constants are indeed often realized through macros in C, although const exists just like in C++.

Yes, C does not support default arguments or any other function overloading for that matter. C++ does.

Explain what?

It should be:
[CODE]if(beginMinute + durationMinute >= 60)++endHour, endMinute = (beginMinute + durationMinute)%60; [/CODE]

You're meant to only access the top element of a stack, so std::stack provides no way to iterate over its elements.
But you could keep removing elements from the stack until you find the value you're looking for or the stack is empty, then push all elements back on the stack (possibly excluding the one you found, if any).

Ah, I see.
Also, you said you wanted to use case statements - I associate that with switch cases:

case 1:
dead nowDead;

case 2:
alive youAlive;