I have a question regarding C++ Wrapper classes. I have some experience with C and classes seem kind of odd to me. What things should I consider in order to create a wrapper, say for Win32 GUI code? Everytime I create a class Win32 code seems to not want to compile and complains about WINAPI and other Win32 objects not being defined. Also is it even possible to truly make a wrapper class since Win32 is older than dirt? Thank you in advance for any replies!

Quote:Also is it even possible to truly make a wrapper class since Win32 is older than dirt?

C is older than the Win32 API. What's your point?

Yes, it is entirely possible to write a wrapper around Win32 API functions. If you are getting errors, its because you are doing something wrong. Possibly missing an #include, not linking with the right libraries, or writing illegal C++ (dispite what you might think, C++ is quite a different language from C).

The other question is, why bother? There are plenty of existing wrappers or, quite frankly, better languages (C# + .NET) for GUI development.

Well no need to be rude or a jerk. I am trying to better understand the methodology behind wrapping a class around the Win32 interface, and what things I need to understand to do it. I don't necessarily want to blindly use a class thats already been created because I am not going to understand why it works if I don't try. I find most tutorials "show you how to do it", they don't explain the "why's" regarding why you do it. To me, the class is very odd considering I have only done coding in languages that are non-OOP based and most C++ books do that lame Critter caretaker program which is just confusing as hell.

My point is that the Win32 is antique, it was mainly used for C programming and was not written with a perspective on OOP languages from what I can tell, so is it hard to wrap in a C++ class or nearly impossible to wrap the API completely? As I said, C++ is an enigma and I am trying to understand it since I can program somewhat decently with the Win32 API. I was hoping for rational info if anyone can provide some.

If you don't understand OOP, I would reccommend using an OOP library before you try to write one. Perhaps using MFC or wxWidgets. Or better yet giving Java or C# a try.

I'm just being blunt.

However, I'm confused. If the "concept" of a class seems foreign or confusing to you (it seems likes that's what you are saying), you aren't going to want to jump into something like trying to build a collection of classes for handling Windows GUI programming. The OO paradigm is much, much more than just using the "class" keyword in C++ instead of "struct," and sticking some member functions in your class.

The desire to want to understand how something works rather than just blindly using it is commendable. However, attempting reimplementation doesn't always lead to understanding, and can very often lead to the acquision of incorrect information, especially when you bite of more than you can chew.

You might want to start with something a little less ambitious than OO Win32 wrappers (which will be fraught with not only the perils of sane object-oriented design, but also the perils of Win32 and the perils of C++). But perhaps more ambitious than whatever this "critter caretaker" example you mentioned is (I have never heard of it before).

There are many reasons why the Win32 API is in C. Some good, some bad. Among them, however, is the fact that C is very, very good at interoperating with other languages (and its pretty easy to do).

I don't like posting here because of the numerous ignorant/immature users like sgalland who are running on empty when it comes to the facts and are quick to accuse others of being rude or a "jerk." I find that anything you say that is contrary to their opinion and that isn't qualified with platitudes is automatically interpreted as a flame by these nitwits.

Thank you for the responses, and sorry for the attitude, I read what I wrote and I sounded like a jerk. Anyhoo, what are some good C++ books, I have 3 books, C++ for game programming for beginners, C++ for dummies (worst c++ book written), and C++ in 21 days and frankly the C++ class section are all critter programs or classes that seem impossible to decipher. I for some reason just don't understand the class paradigm although they seem simple in theory, they seem to be a complex subject. Maybe I should just stick with C :)

A class is a datatype, in the same way that a C struct is. You can create instances (also referred to as objects in OO parlance; C structs normally just have "instances" when spoken of by C programmers, if they even bother to distinguish concept of the type from the concept of the instantiations) of it in basically the same ways as in C. However, in C++ you can also provide member functions in addition to data members, 'protection' of members (public/private/protected access levels), inheritance (explained below), and some "auto-run" functionality (constructors and destructors): special functions that are run when an object of the class is instantiated and when it is cleaned up (either as a result of delete'ing an object allocated with new, delete[]'ing an array of objects allocated with new[], or because the object was stack-allocated and fell out of scope).

The 'class' keyword in C++ is syntactic sugar; a C++ compiler allows you to add all of these things to 'struct's as well. By typing 'class' instead, you default any inherited bases to inherit privately (you usually want public inheritance, so you have to then specify this), and members to be private (you usually want all or almost all data to be private, and most functions to be public). However, the term also carries semantic baggage: it is idiomatic to use 'struct' for mere collections of data (so typically they only have no member functions except for constructors and a destructor, and don't contain any pointers), and 'class' for types that provide behaviour and thus actually model something.

Inheritance allows for subtyping relationships: you can say that class X IS-A class Y, which is to say, an X object can do anything a Y object can. This is implemented by the compiler by adding all the Y data members to the X "object layout", almost as if you had a data member of the X type - except that you can call X functions on (and access X data members from) the Y directly, rather than having to access the X member. In exchange for this, you have somewhat less flexibility than you get with real "composition" (modelling a HAS-A relationship, by making an actual member of type X). It is quite unusual for it to be a good idea for X to both "be" and "have" a Y; and beware that when you define X, you should NOT redefine members of Y (unless you want *extra* members that happen to have the same name, and even then, things get difficult to manage).

Inheritance also facilitates polymorphism. I could describe this in some detail, but I think the best approach for you would be to read here and here (the latter is a fairly random Google hit that I selected because there's actual code that's fairly illustrative; you might want to just google for 'C "pointer cast polymorphism"' yourself) for a description of how similar functionality gets brutally hacked into C, and then here to see how C++ does the work for you (in a much safer way which is still as efficient as could sanely be expected).

Constructors and destructors are used for setup and cleanup of objects. This facilitates the very powerful C++ idiom of RAII (Resource Acquisition Is Initialization). The idea is that every object is responsible for its own "toys", and puts them away when it's done. The C++ standard library provides several classes that respect these rules. When everyone pitches in like that, it becomes easier for everyone - for example, if you want to make your own class do RAII properly, then it makes good sense to prefer standard library "container" objects over raw arrays or hand-rolled list/graph structures, because the constructors and destructors of the members will be called as well as those for your containing object, greatly reducing your workload. See more here and here.

Actually, hell, just read the whole C++ Faq Lite. It's quite worthwhile.

Maybe a code example:

#include "windows.h"#define WIN32_LEAN_AND_MEANclass cWindowsGui{  private:  int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lCmdLine, int nCmdShow)  ;  public:  cWindowsGui();};cWindowsGui::cWindowsGui(){  this.WinMain(HINSTANCE h, HINSTANCE p, LPSTR c, int cs);}int WINAPI cWindowsGui::WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lCmdLine, int nCmdShow){  MessageBox(NULL,"Test Message","Test",MB_OK);}

When I use this code it tells me that WINAPI, LPSTR, and other Windows.h defined variables are invalid once I initialise them. The problem isn't that I have a book, I guess its that in my 3 C++ books they all have a lame critter example that just doesn't show me what I would call a real world class. I know that Java works differnetly about C++, but this is the only thing I can come up with to write self contained code that follows the OOP paradigm since Java is the only OOP language that I know. I have heard that C++ is not a true OOP from many people and I don't know if this is the cause of the issue, nor the fact I am using MinGW as my compiler, but from what I have seen (and that's not saying much) it should work. As I keep stating, how would I do something like this in the real world to understand C++ classes better?