> I know nothing of scheme, guile, nor Objective C (except that is > probably a more pure object oriented language then C++). > > You get a more advanced C when using C++. You get data hiding and > encapsulating. The conceptual tying together of data structures and > methods. I can see lots of advantages to using C++. You are not forced > to use all the features of C++.
aparently, you've never done any kernel coding or anything with GObject. C++'s classes are definately not the only way to do object oriented programming, and are very often, not the best way for a paticular problem. Proper C coding can be *very* object oriented. > I don't know if this is over kill or not, but I try to have every > "variable" to be an instance of a class. I even use classes for U8, U16 > and U32 objects. I can add methods, etc. for instance I quite often do > something like: > U32 myuint32; > myuint32.u16(1) = 0x1234; > myuint32.u8(1) = 0x77; > myuint32.u8(0) = 0x88; > This is equivalent to (assuming big endian machine): > myuint32 = 0x88771234; > This is much cleaner than using ugly C casts. eg: > unsigned long myuint32; > *((unsigned short*)&myuint32)+1) = 0x1234; > *((unsigned char*)&myuint32)+1) = 0x77; > *((unsigned char*)&myuint32)+0) = 0x88; ya, thats overkill, from what you are doing, it looks like you want ntohl() and friends > I can also do fancier things like this. Objects are much nicer and can > provide a much better API for developers. > myuint32.DisplayHex(); > myuint32.DisplayDec(); > myuint32.u16(0).DipslayHex(); > myuint32.u16(1).DisplayDec(); > myuint32.u8(0).DisplayHex(); > myuint32.u16(0).u8(1).DisplayHex(); the same things can be done in C, just by a different, more flexible method. > I knew some work of porting GTK+ to Windows had been done, but I thought > the draw back is that it looked like a GTK application rather than a > Windows application. ie. it didn't use the native MSW widgets and > therefore didn't inherit the MSW look and feel. Maybe this is not the > case anymore ? GTK is very themable (theme engines, etc) so win32 users can use a theme engine that matches their gui. > With regards to Makefiles, I would really encourage you NOT to use a > recursive Make system. This known to be a really bad way of creating a > hierarchical build system. See the short paper describing the problems > of recursive make by Peter Miller. It's called "Recursive Make > Considered Harmful" and can be found at > http://www.canb.auug.org.au/~millerp/README.html it may take longer to do some builds, but the simplicity of using a recursive Makefile.am system more than makes up for that
