I have just started playing around with CommonC++ on Win32, and had a few questions.
1. It appears as though there are a bunch of classes not defined in the Win32 lib. Is this intentional?
2. Some of the classes in the Win32 lib reference external classes ( like Semaphore ). Do I need to compile the posix lib to get these classes? It looks like the posix lib references a few API calls that don't exist in Win32 ( like opendir ).
Just one ( completely uninformed ) comment - wouldn't it make sense for the posix and win32 libs to share header files when possible? The Thread appears to be pretty much the same - it just seems like a headache to manage 2 header files.
So far it looks promising. I am willing to help out on the win32 side of things if more minds/eyes are needed.
Thanks-
John Dunn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The win32 api is dissimilar enough that the development was done largely seperate from the posix source tree. The socket sources have been merged together into a single source now, and yes, it
would be good to do that with the remaining files.
When compiling win32, you have two options potentially now; one is to use posix with cygwin, which almost works, and may soon work completely, and the other is to use a native win32 compiler with the win32 source tree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the long term goal with Win32? I guess I see 3 possibilities-
1. Single posix tree and use cgwin.
2. Continue using 2 different trees.
3. Single src tree with shared headers and ifdef'd src files.
I hope 3, since that will give us the best performance and maintainability.
I have experience with threads and sockets in Win32, and would be willing to help on this project, but since I have never worked on any opensource/sourceforge project I won't start without someone giving me an ok.
With a proper map I'm fairly confident I could implement some of the missing classes, but I am really only interested if the long term goal is a single non-cgwin src.
You can email me at johnd@peakaudio.com if you wish to contact me directly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A single set of sources with #ifdef conditionals (like already done for sockets) would be much better. One build tree could then be used for "common" and platform specific code, and the library divisions could be more logically grouped. So yes, "#3" is the long term goal. If you would like to help with that, I would be happy to add you to the project.
David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just started playing around with CommonC++ on Win32, and had a few questions.
1. It appears as though there are a bunch of classes not defined in the Win32 lib. Is this intentional?
2. Some of the classes in the Win32 lib reference external classes ( like Semaphore ). Do I need to compile the posix lib to get these classes? It looks like the posix lib references a few API calls that don't exist in Win32 ( like opendir ).
Just one ( completely uninformed ) comment - wouldn't it make sense for the posix and win32 libs to share header files when possible? The Thread appears to be pretty much the same - it just seems like a headache to manage 2 header files.
So far it looks promising. I am willing to help out on the win32 side of things if more minds/eyes are needed.
Thanks-
John Dunn
The win32 api is dissimilar enough that the development was done largely seperate from the posix source tree. The socket sources have been merged together into a single source now, and yes, it
would be good to do that with the remaining files.
When compiling win32, you have two options potentially now; one is to use posix with cygwin, which almost works, and may soon work completely, and the other is to use a native win32 compiler with the win32 source tree.
What is the long term goal with Win32? I guess I see 3 possibilities-
1. Single posix tree and use cgwin.
2. Continue using 2 different trees.
3. Single src tree with shared headers and ifdef'd src files.
I hope 3, since that will give us the best performance and maintainability.
I have experience with threads and sockets in Win32, and would be willing to help on this project, but since I have never worked on any opensource/sourceforge project I won't start without someone giving me an ok.
With a proper map I'm fairly confident I could implement some of the missing classes, but I am really only interested if the long term goal is a single non-cgwin src.
You can email me at johnd@peakaudio.com if you wish to contact me directly.
A single set of sources with #ifdef conditionals (like already done for sockets) would be much better. One build tree could then be used for "common" and platform specific code, and the library divisions could be more logically grouped. So yes, "#3" is the long term goal. If you would like to help with that, I would be happy to add you to the project.
David