It's Argument Dependent Lookup (ADL) also known as Koenig lookup. It's invaluable when you're trying to define operations on a type in a namespace using functions in that namespace. Say you have:

namespace N
{
class A
{};

friend A operator+( const A &, const A& );

}

// Somewhere else...

A a, b;

auto c = a + b;

if the compiler didn't know to look for the operator in the namespace A was declared in you wouldn't be able to use operator functions in namespaces that easily. It would be a particular headache for <, << and >> which are required by chunks of the standard library.

You're right - I got things a bit bum backwards. Basically you want C to be able to look at the implementation details of M so you declare C a friend in M:

class M
{
// Somewhere in the declaration of M...
friend class C;
};

should do the trick.

If all instances of C are owned by and created by an instance of M and there are no other clients of C then I can't see a lot of problem in making M a friend of C. You're essentially saying that C is a part of M you don't need all the time so you want to tear it off and discard it after some initialisation process. Another way of doing it would be to introduce a new class, A that contains the bits of M that C needs to manipulate. M would contain an instance of A and pass a pointer to the instance to C when needed. That gives you a bit more future proofing and decoupling - both C and M don't depend on each other and just depend on A. Yet another way would be to have a getter/setter interface on M but if C's the only thing that would want to use it then you're complicating the interface of M for no real reason. Personally I'd go for the first and consider the second or third later if the requirements change and you need more flexibility.

The first thing you've got to do is work out whether it's I/O bound or whether it's the data processing that's slowing things down. You might find that CFile isn't particularly well tuned for reading from flash and not buffering enough. If it turns out that it's the I/O that's causing the problem find the lowest level function you can call and see what the raw I/O speed of your device is for a range of buffer sizes and then implement something that hits the sweet spot in terms of buffer size. It's a shame you're using MFC classes and not standard library ones as it's a lot easier to replace the underlying buffering and I/O mechanism, but such is life! Another thing might be to try reading more data in your while loop (say 512 characters at a time) and manually parcelling out the data rather than letting CFile::Read do it. If it turns out that the I/O is fast enough then have a look at what you're doing with the data. If you've got a lot of string handling you might find loads of temporaries flying about (especially if you're using VC++ 2008 and earlier) and there's loads of hidden memory manipulation that's slowing things down. In that case look at reducing the number of temporaries you need by reusing objects and expoiting things like NRVO. Anyway, the main thing though is to find out where the bottle neck is then do something about it.

I've used a couple of way of getting around this: - use the void pointer hack - wrap every WIN32 operation in another class called window_handle then implement window classes as needed using that. I also replaced the concrete base class with an interface class as virtually all the code that would have been saved by implementation inheritance ended up in the window_handle. This is similar to your shared PIMPL but the PIMPL is actually a full blown object in its own right and does all the WIN32 stuff and doesn't just hide an HWND. Another way I want to experiment with further decouples the windows guff from the logic of what the window actually does. The idea is to have a window class that has a message handler interface pointer but I haven't tried that yet. You'll be getting a similar effect using boost::signal2 to route messages.

Friends will work but you should always be aware of the coupling that introduces into your design.

(Bit late to the party... still think this is worth saying and it might help you in future) If you ever find yourself wanting to use a class but there's aspects of it's interface that you don't want to work with then don't try and modify the class you want to use - that way lies madness and hackiness of the first degree. If the class with the relatively fat interface really needs a big interface somewhere else you don't want to break that. So what can you do about it? Wheel out the software engineer's swiss army knife - another level of indirection! So if you've got a class:

class fat_and_dangerous
{
public:
void safe();
void dangerous();
};

and don't want clients to use dangerous() implement another class using it:

class skinny_and_safe
{
public:
skinny_and_safe() : fat_( new fat_and_dangerous ) {}

	void safe() { fat\_->safe(); }

private:
	std::unique\_ptr fat\_;

}

and in most of your client code only use skinny_and_safe. Just out of interest... don't actually implement skinny_and_safe inline. It leaks too many implementation details to the client. Don't worry about performance - most compilers (actually linkers working with compilers) these days will elide the indirect call - until a profiler tells you that it's slow.

When you're choosing a container choose a vector. They're (except for one case) as fast as an equivalent automatic array. Then if you find the interface or performance characteristics of something else works better you can change it later.

It depends on the architecture and how quickly the processor can form an address in comparison to how fast an instruction gets through the pipeline. The only way you're going to know for sure is to measure the speed of your app using both types of variables.

Write it in idiomatic C++ (using boost) and if you know any Python at all it'll click straight away.

It has a future - I was first told in 1995 that I wouldn't have a job next year writing C++ applications and I'm still at it. Sun couldn't sell Java stations in the 1990s and even though I use a Chromebook [1] almost exclusively at home high performance apps on them usually have a chunk written in C++. I can't see anything replacing C++ (apart perhaps for C) in the embedded or OS spheres either.

It's not necessarily bad design to pass a reference to a local variable to another thread for processing. One example of where it might come in handy is splitting up an array into chunks and processing each chunk in separate threads. However using volatile as a synchronisation mechanism is not the sort of thing I'd recommend to try and avoid a proper synchronisation mechanism (i.e. a condition variable).

No probs - I only thought about it as I had the same problem last week :-)

Something you might have missed: You can set the VC++ debugger up to catch exceptions where they're thrown and it generates a message like the dialogue you're getting. Are you running under the debugger with that setting enabled? If you're not running under a debugger then it's something else but I thought I'd try and clear that up first!

The array passed into the function could potentially have any value in it you can't select a simple return value to represent your error condition. I'd consider throwing an exception rather than using a return value:

if( A[low] > item || A[high] < item] ) throw binary_search_out_of_bounds();

Another option is to have the function return a std::pair<bool, int> where the first item in the pair tells the caller if they have an error condition or not and the second is the value they're after. Personally I find that a bit ugly and it complicates your code more as you have to do more in the calling function so I'd go with an exception. Cheers, Ash

Looking at the error there's probably a missing equality operator, but why's not obvious as we haven't got the full class definition. And it's not better to pass a pointer rather than returning a value - a decent compiler C++98 compiler will implement NRVO which makes it just as efficient to return a value.

You can return objects that are declared local to a function from a function. That's what copy constructors are for...

Make your nested structure public and declare the member functions in your class first then see what happens.

It depends on what your host operating system is. If you're running Windows then I'd suggest either Microsoft Visual C++ Express or MingGW and a text editor of your choice. From recent experience of teaching a couple of newbies Visual C++ was a bit of a cognitive load at the same time as learning C++ - you have to deal with some non-C++ bits that you have no idea about at first. MinGW is a bit simpler to get started with - the cognitive load is still there but spread slightly differently. If you're running on Linux or something like FreeBSD then install g++ and use that.

If you're using a standard C++ compiler then the cout should happen first. However as you're not using a standard compiler (cout and printf are members of the std namespace for a standard compiler) then all bets are off. Get a new compiler and see if you have the same problem.