Most likely ASLR - Address Space Layout Randomization. The operating system is trying to help you not get pwnd due to easily exploitable crappy code.

You don't need a custom allocator for that type (or frankly, any type - effectively). Custom allocators are a way to speed things up, or to keep data localized (definitely not mutually exclusive goals). You DO however definitely need custom comparator functions, and you are close to getting it right. Very close. Have you considered making the member comparators const themselves, e.g. "bool operator<(const Vertex& rhs) const;"?. ;-P ++luck;

Then I'm totally baffled. Recommend you compile with /P (preprocess to file) and then, from a command-prompt try to compile that generated file. It should contain #line directives and such making it (hopefully) obvious why it fails. ++luck;

Run-time or compile-time? If compile-time, gperf (GNU perfect hash) could probably help.

To me, just based on this comment, it seems you'd have: A "base", the driver. The singleton. This owns one or more USBBus objects, each handling a physical connection. These in turn owns zero or more USBDevice's, each representing a device on that bus. Each USBDevice would in turn probably have one or more "functions" (e.g. a USB mouse with buttons, wheel, and some more clickable buttons could easily present 3 or more functions/sub-devices). It also seems logical that each device (and function and so on) might need (hold) a reference to its owner, to f.ex. be able to notify it about events. Not to mention the obvious - verify correctness in such a highly dynamic and unpredictable system :-) I see no obvious reason any of the USB types should ever touch the global/static parts. But should the need arise; don't give them access to the data (if you ever used MFC, consider that the anti-thesis of good design). Instead provide them an interface - and not only an interface that returns a ref or ptr to the global/static var's, but something that actually do some work. Which brings me to another good rule-of-thumb (actually, this one is more like a law of nature): - Interfaces shall be minimal and complete. Additionally: - Member functions should do two things; Use the object's state (directly or indirectly), and not leak the objects state to the outside. If a function is not using the object's state, it has no business being a member function (not counting corner cases). If it's not hiding the internal state, it's "leaking" it to other types to use or abuse, and making it hard-to-impossible to change the implementation later on. That last point, not leaking internal state to the outside, is worth hammering in over and over until you say "Obviously, anything else would be insanity!". Later, if needed, "on the side" you might even find it useful to have a "registry" of devices, no matter what bus they are on, to save lookup time or whatever. F.ex. the system input handler might poll you about input events, and then you could have one list of devices dedicated to HID input. Another case could be the user requests "Put all storage devices to sleep" and instead of walking the busses and their devices (which in turn may have an expander (hub-ish) with another bus to dive into) you have a single list to iterate. You get the idea. ++luck;

What research? All versions of Visual Studio build C++ code into a native image. While true, some versions produce horribly bloated images (ref. the .... was it CDialog library bug in one or two versions of MFC) making them quite unsuitable to use, or produce images impossible to run on anything but the "Latest And Greatest(tm)" Microsoft Operating System. It does require research to find out about such things.

I should have said "is C++ ( and derivatives ) strongly typed " No need. You just mixed concepts when including overloading - that's like comparing apples with the act of driving a car. :-) So restricting the question to C, it is indeed a strongly typed language, but in some instances not entirely strict about it. C++ is stricter. For further reading, see f.ex. this wikipedia page.

While true, the documentation states "measured clockwise". Provided the user has turned the monitor the same direction using both vendor's drivers, one of them is clearly wrong. Does WHQL still exist? If so, perhaps Microsoft would like a ping "Hey, you don't check this!".

Does your COptionDBTransport inherit from CCmdTarget (or a derived type of it)? Have you included (even if indirectly) ? (ON_BN_CLICKED is defined in another header)

"They" use some version of cpp compiler, sorry do not know exactly which one. Seems likely it'd be a GCC, or nowadays maybe even LLVM. Have a look at command line options -W4 or -Wall. One of the two options (or very similar) would probably tell you "Silly user, now you gone and made a mess out of stuff again!". :-)

VC6-VC10 produce unreachable code warnings (C4702) /W4, but much to my surprise not at /W3.

Some basics: Is-a = inheritance. If you inherit type B from A, then you can use type B as type A. Also see Liskov Substitution Principle (LSP). Example:

class Shape { virtual void Draw() = 0; /* ... */ };
class Circle : public Shape { void Draw(); };

A Circle is-a Shape, so type Circle inherits type Shape. Note that this is all about behavior (interface), so you can treat a pointer or reference to any subclass of Shape as if it was a Shape with respect to Shape's interface (in this case a single Draw() function). Has-a = aggregating. Example:

class Canvas {
public: void Draw();
private: set m_shapes;
};

A Canvas can hold one or more Shape's, of any concrete subtype, and most likely Canvas::Draw will iterate over the shapes it holds, calling their Draw method. For clarity, you may want to think of Canvas::Draw as Canvas::DrawShapes. For the particular case where you are to have one, and only one, object of a specific type, you may want to have a look at making it a Singleton. I hope this attempt at a simple explanation of the concepts can help you come up with a design. While drawing has nothing at all to do with USB, the concepts of inheritance and aggregation are the same. For project after project. (NOTE: code-formatting was done for compactness, please do not copy as-is :-) )

If it's indeed the blit sucking that much time, prime suspect would be format conversion. Check out GetObject() for BITMAP, to see what the format of src and dest are. I'm willing to bet 3 lines of C++ that they are different. :-)

Is there any expert who can find out how to control this device with own software ? While there certainly are, it could be between quite and very expensive. As reverse engineering (even for compatibility) is illegal in some jurisdictions, the one(s) performing it would have to be in a place where it's allowed. Say Europe. Then you have to factor in the very specialized skill-set and expertise in the area, and we could easily look at five digits USD. IMO the company producing the card should at a minimum provide complete driver(s) for it, better yet complete documentation. As patented stuff like H.264 is included, they may themselves be prevented by NDA's to provide neither, making the product a burden on the environment (read: landfill :-) ). Anyway, my advice would be to first contact the company producing it. If that fails, I'd advice against even considering hiring someone to do the work unless you had serious dough just lying around. Better to get a simple card with working software and append x264 to the pipeline. ++luck;

If you are referring to VC 7.0 (or maybe even 7.1?), this is a known "problem". For more info/verifications, you could google some MS newsgroups (usenet news). Obviously it can be fixed - but only by the ones destroying your data in the first place.

While I can sympathise with your standpoint, I don't know what you referred to and neither the threads and questions. That said, I know from experience that many questions are repeated - displaying the questioner have not even done the basic googling or searching of even CP itself. If the questioner tells up front "I've been trying to find this answer using means x, y and z" it's one thing, but asking a beginners question with an almost obvious proof s/he hasn't even done a google search IMO deserves LARTing. Again, as I don't know what you referred to there might have been something more serious provoking your post, but in my experience post of this kind are provoked by a bystander watching, just for a short while, people who are too lazy to even bother trying to find their own answers before bugging the general public and get flamed for it.

John R. Shaw wrote: CString w/o MFC? No! IIRC, CString is nowadays (also) under the CPL - MS made it part of the WTL library which they made free software.

cpeed wrote: anyone understand where is the problem? Considering you only request one char, and '1' + CR + LF is three chars...

nguyenvhn wrote: Could you give me an article to make more clearly that "using any MFC collection class is almost always the wrong thing"? Once you gain more experience in C++, It'll come to you. But to give a starting place, you might want to Google some news. And so that, what is the true replacement? There is no silver bullet.

No. There is however a function, _rotl, and an assembly instruction (Intel added it after the age old joke).