C / C++ / MFC

Yup, you are tight , iwas jsut able to extend and use it directly... :)

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;

By configuring the port with your LED as output (writing to the TRIS_x register) and setting the output state to the level which lets current flow through your LED (writing to the PORT_x register; the level depends on how the LED is connected).

The two types are not the same, so it does not really make sense; see https://msdn.microsoft.com/en-us/library/ezzw7k98.aspx[^]. Perhaps you should explain what problem you are trying to solve.

You should use the UpdateAllViews[^] function of your CDocument derived class. That will then call the correct method for each CView derived object to update itself.

Maybe this[^] link will help. "the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst

Anthony Appleyard wrote: Is this class declaration likely to be any use to any of you? Not really, the GDI+ Pen class[^] is already available.

Each project is part of a Solution (top folder in the tree), which may contain other projects. So you can build/rebuild/clean only a particular project, or every project in the Solution.

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!".

Hi Mike thanks for answering This card can be controlled with standard DirektShow routines some people answered me. But is this fast enough ? And all features programmable ? I will see ... ;) greets Peter

"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!". :-)

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. :-)

See https://msdn.microsoft.com/en-us/library/ybk95axf.aspx[^].

Member 11393333 wrote: I need it No. What you need is a different kind of job. That would be better both for you and your prospective employee. Seriously, ask yourself this question: what is the point of applying to a job with requirements you cannot hope to meet? Even if someone were to provide you with the example you ask for, it's likely the employee will realize it's not your work, and that you cannot be trusted. In the unlikely case he hires you anyway, you won't be able to complete any task, and you'll be fired. Better spend your efforts in finding a job that fits your abilities! GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

You're trying to cast to (CDetour::*), which isn't a valid type definition. It is only a part of a member function pointer definition and doesn't make sense without the parameter list and return type. Look at the last line in the MS code example: &CMember::Target is the address of a member function pointer. You can only cast a member function pointer to a member function pointer of a differentsimilar type, in this case (void (CDetour::*)(void)), which is a member function of the class Detour (that is what CDetour::* means) with an empty parameter list (the (void) bit) and a void return type (the preceding void) The compiler error is based on the fact that the compiler doesn't recognize (CDetour::*) as part of a function pointer definition without the preceding return type, and there is no other valid interpretation. Your edit version looks better: the compiler does recognize the member function pointer cast correctly, it just doesn't want to accept that cast for some reason. One possible problem could be the calling convention being used: your class definition generated the member function using __thiscall, whereas the QT function was defined as using __cdecl. You may want to check your calling convention settings. [edit]fixed my statement about function pointer casts in light of what I said in the last paragraph[/edit] GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)