Wow man, you are asking a lot here. But it shows you thought about this stuff which is very good!!
Anyway, I''ll see what I can answer (not much probably).
1) How do I eliminate the run-time library from being
Isn''t this a standard option in vc++?
2) I can probably override the Window::operator new functions for my class (and the operators of all other classes), then provide a custom "allocator" function in the DLLs to make the objects -- kind of like an object factory in COM. This is messy, but then only the library creator (me) has to work with it -- it''ll be transparent to the user. My question, then, is how do I override the allocation of things on the stack?
You don''t. Why not create a factory interface which let''s the user instantiate everything. THe implementation of that factory wil use new internally. That way the user will never new things. (which the use shouldn''t be doing anyway cause it''s interfaces we are talking about which aren''t really instantiatable). The you refcount these interfaces so they can destroy themselfs when needed. Standard COM stuff.
3) How can users of my library create one .EXE file that will run under all major operating systems -- Windows, Mac, Linux, etc.? I can re-define the entry point, but will that simply enable it to run in different environments? The program''s themselves will not link or even #include code from any specific OS or OS-specific API -- only mine.
You can''t. Running your application on different osses with the same binary is not possible (yet), unless you are using Java. Simply recompile. If you create everything structured this shouldn''t be a problem.
4) anyway, does anyone know how I can override or handle
Sorry can''t help you here.
5) Cast operators (apparently) don''t work with pointers to classes. When I do this:
class String
{
public:
operator const char*() { return m_pData; }
};
pStringObject = new String("test");
const char* pMyString = (*pStringObject);
What the h*ck are you trying to do here man? You are converting a class (which can contain everything) to a character array. This is scary man
. You cannot know what is in the class. Why not let the class have a method:
char* GetCharPointer();
Or am I missing something?
6) I just though of another one! Since the pure C++ classes
Don''t quite understand you here.
7) I just realized - I''ll have to create my own substitute for LoadLibrary/FreeLibrary (you can tell I learned C++ from Windows...). Wait...do they exist in the standard C Run-Time library? Or does someone have source code to create functions like those for C++? Anybody have links to a tutorial on something like that?
Nope. But Loadlibrary is win32 only. Linux uses another system for dynamically linking that has something to do with .os files. I could look it up for you if you want to. My bet is that you need a different LoadLibrary for each O.S. And the runtime has no dynamic loading feature.
8) When I get this project off the ground, would this be a project people would be interest in joining? Or is it worthless to anyone but me?
THis is a great and ambitious project. I once started such a thing and had great plans about extensibility and platform independacy but then i got a new job that I''m working really hard on now. So I don''t have time for it anymore.
ANwyay, goodluck.
Jaap Suter
I''d be really grateful for any (polite) answer to these questions!
(any COM techies, please respond!)
____________________________
Mmmm, I''ll have to think of one.
____________________________Mmmm, I''ll have to think of one.
1) How do I eliminate the run-time library from being linked or #include-ed in the program that uses my library (I can create a generic starter project for the users of my library -- I just want to know how to do it).
2) I can probably override the Window::operator new functions for my class (and the operators of all other classes), then provide a custom "allocator" function in the DLLs to make the objects -- kind of like an object factory in COM. This is messy, but then only the library creator (me) has to work with it -- it'll be transparent to the user. My question, then, is how do I override the allocation of things on the stack?
3) How can users of my library create one .EXE file that will run under all major operating systems -- Windows, Mac, Linux, etc.? I can re-define the entry point, but will that simply enable it to run in different environments? The program's themselves will not link or even #include code from any specific OS or OS-specific API -- only mine.
4) This is beginning to sound like a C++-based virtual machine...anyway, does anyone know how I can override or handle the generic exceptions, like an access violation? If I can't allow users to create these objects on the stack, then I want to know how to make sure they know why they're getting access violations with temporary objects.
5) Cast operators (apparently) don't work with pointers to classes. When I do this:
There should be a way to have language-level support for this -- just like you can re-define the global operator new. You should be able to re-do the stack as well, although that would probably be pretty difficult and require an OS that links DLL code almost directly with the program, giving them the same stack. *sigh* Using something like CoCreateInstance on each class isn''t what I need -- that''s overkill for a library. What that does is enable each class to be in its own DLL (or EXE or whatever) -- all I want to do is put together a collection of classes for a library.
