Although 2012, all the people I know who smoke, still use fire. :rolleyes:

I just see it as yet another folder to put stuff in. I don't think it has any impact on productivity for me. Maybe it has for some.

Quite right :)

leppie wrote:

A years supply of cigarettes (~R6000) is about the same as half a PC...

So, which half of the PC would you go for?

Using just stl you can do something like:

ifstream file("file.dat");

vector lines;
string line;

while (getline(file, line))
lines.push_back(line);

Remember that it is all about substitution at compile time. The values you use when compiling the lib will be used there, and the values you use when compiling the exe will be used there. This means you will have to be careful when changing the values between compilations. Are you saying that you have the same values in both projects and still experiencing problems?

Andrew Brock wrote:

At a guess tho, I would say it is because you didn't declare it as a virtual function.
 
In the header file it should be declared as virtual void OnInitialUpdate();

Not likely since once virtual, always virtual. You don't need to declare an overridden virtual function virtual. However good it might be for readability, it's not necessary.

Tyler Elric wrote:

Is this what your'e referring to as "Move semantics" ?

Yes it is.

Sorry for the late reply, but are you using an old compiler? If not, implement move semantics in your classes. It will take care of things for you.

I'm going to be straight, this code is a mess, and as you've already noticed, error prone. Why not use std::vector<> and a couple of iterators? Problem solved. ?

You should use the hMenu parameter to specify the control id of your button (IDOK or IDCANCEL in your case) From MSDN: hMenu [in, optional] A handle to a menu, or specifies a child-window identifier depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used. For a child window, hMenu specifies the child-window identifier, an integer value used by a dialog box control to notify its parent about events. The application determines the child-window identifier; it must be unique for all child windows with the same parent window.

If it is the implementation files you're missing, you could just drag the missing cpp-files from windows explorer and drop them in your project tree, and they will be built from wherever they are stored.

Stefan_Lang wrote:

The code tends to get quite verbose

Are you implying this is a bad thing?

In most cases, no. In some cases, yes. It does affect readability if it's too frequent. However, I have not experienced this in any other situation than when working with std streams.

I personally almost never use it, simply because it clutters the global namespace. The worst abuse is to put it in a header file, and thus, polluting the global namespace in all files including that header. I imagine though it can be useful in some situations, like when dealing with streams and manipulators. The code tends to get quite verbose if it's fully qualified. A local using namespace could be acceptable in my oppinion. Good topic by the way.

It is not thread safe. You will have to manually add the locking before accessing its data. Imagine what would happen if a node is removed while PLookup is using it. The easies way of creating a thread safe container is to embed an existing container in a new class with the same interface, or a subset thereof if sufficient, forwarding all calls to the aggregated container and adding all the locking in between.

memset() doesn't do any allocations. Your array is allocated on the stack and will not require any deallocations. Only when allocating memory with an allocation method such as new/alloc/malloc/or other platform specific allocation methods, you will have to deallocate accordingly. memset() only writes data to a piece of memory that should allready have been allocated by you if you've done it properly.

It is actually possible under certain conditions for the compiler to inline virtual functions. Consider the following:

class Base
{
virtual void func() {...}
};
class Derived : public Base
{
virtual void func() {...}
};

Base b;
b.func();
Derived d;
d.func();

In both cases, the compiler can chose to inline func.

Ah! The trailing null!

I can see no standard compliance requirements in the original post, but your assumptions seem right.

The entire page is a good resource. In the next version of the standard I'm looking forward to see overloading of the new operators: ; - ) and : - P