* Brent Fulgham said: > > > Simple. :-) > > Perhaps, but not clean. And doesn't make sense in this > > particular case... > > Remember the rule of the Ockham's Razor???? I think it should > > be obeyed > > here... > > > > I think the real problem is in trying to export a language-specific > construct to another language which does not support it. C does not support > objects. Yes, yes. I realize that a "good C programmer can bliff and > blaff, etc., to achieve an object-oriented design that will be worthy of a > Nobel prize and the Pulitzer prize simultaneously, etc. etc.". Oh, no! :)) Let us not start a language flame war :))) This is not the point. The issue is, whether this particular problem REQUIRES C++ from the conceptual and implementational(sp??) point of view... > However, the fact is that C is designed primarily for procedural style > programming, and does not have features in place to handle > C++/Java/Python/etc. objects. Of course it doesn't - it is possible, but not practical :)) > A better question is how a revised C++-ish library might interoperate with > an object-oriented language designed to make use of polymorphism, > abstraction, etc. Say, how Python might work as a front end, or how you > might use Java, etc. The answer is - you can't... All the languages you mentioned have clean C interacing methods, but no C++ ones. The reason is that C++ is not interoperable. > Asking how to pass a C++ object to C is like asking how to cast a float to a > byte field in assembly. :)))))) > Ideally, a library would (in addition to it's C++ functionality) have a C > interface that doesn't really deal with the issue of objects. Say, > something that would accept some standard C types and structs, and return > same. And that's an overkill - you end up writing two libraries and, undoubtedly, putting too much effort into the C part than the result is worth. A waste of time and talent, I'd say... regards, marek
Attachment:
pgplRHFzMCejw.pgp
Description: PGP signature