Having dug into the code a bit for win32 (msvc) and posix (under debian linux), I am a bit confused. There appears to be varied and inconsistent support for certain features and platforms. Before I attempt to help out (which I'd like to do), I'd like to ask some questions:
(1) Under 'win32', which platforms specifically are intended: cygwin, mingw, or direct msvc? The current code, as I have seen it, will not compile under cygwin (due to lacking posix support in cygwin), nor under msvc (various minor and confusing details).
(2) Which version of C++ is this intended to run under: the old iostream libraries, or the newer standard C++ libraries (with or without namespaces)? It appears from the posix tree that the newer standard c++ libs are intended, without namespaces. The win32 tree (at least under msvc) seems to use the old iostream libraries (<iostream.h> does not resemble <iostream>, and the two are incompatible).
(3) are namespaces permitted, even though they are not used explicitly by the source? As many people have found, using namespaces in our own code introduces numerous problems under win32-msvc when attempting to use the CommonC++ libs.
Individual developpers of course can modify the code (as I did) to get it working, but that is not really the best option. It is hard to judge how many people are using this library, and under what circumstances. Perhaps if there was some consensus on the use of this library, the code could be cleaned up and updated:
- remove the non-working cygwin (and mingw?) support from the main source tree until such time as it has a reasonable chance of compiling.
- remove all references to the old iostream libraries in win32
- under the assumption that modern compilers support namespaces, drop the name-hiding macros (or at least make it clean and optional) and put in (optional) namespace support
- make explicit the platform, compiler, and library support, so that developpers do not see "cygwin" in the source and assume that cygwin is supported. Also, make it clear what works and what is in-progress: Win32 support is in progress, for one.
I'd be more than happy to help make changes, but I don't want to step on someone else's beloved fixes or hacks, or pull support from some platform that someone actually uses.
Thanks,
-Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ideally we would like to nativily compile msv directly in the win32 tree, and have the posix tree target cygwin when pthread support in cygwin is more complete. There have been a lot of recent changes with merging code between the win32 and posix trees and some of these have caused minor and odd problems with the last release.
The use of iostream in win32 has been an issue another Common C++ developer has been working on resolve.
Namespace support is being adopted for Common C++ 2.0. Until recently there were systems (like FreeBSD) that had shipped with older gcc compilers that did not do namespaces well. I agree about making the macros optional and namespaces optional, and a start for that was done with some namespace "macros" recently added.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having dug into the code a bit for win32 (msvc) and posix (under debian linux), I am a bit confused. There appears to be varied and inconsistent support for certain features and platforms. Before I attempt to help out (which I'd like to do), I'd like to ask some questions:
(1) Under 'win32', which platforms specifically are intended: cygwin, mingw, or direct msvc? The current code, as I have seen it, will not compile under cygwin (due to lacking posix support in cygwin), nor under msvc (various minor and confusing details).
(2) Which version of C++ is this intended to run under: the old iostream libraries, or the newer standard C++ libraries (with or without namespaces)? It appears from the posix tree that the newer standard c++ libs are intended, without namespaces. The win32 tree (at least under msvc) seems to use the old iostream libraries (<iostream.h> does not resemble <iostream>, and the two are incompatible).
(3) are namespaces permitted, even though they are not used explicitly by the source? As many people have found, using namespaces in our own code introduces numerous problems under win32-msvc when attempting to use the CommonC++ libs.
Individual developpers of course can modify the code (as I did) to get it working, but that is not really the best option. It is hard to judge how many people are using this library, and under what circumstances. Perhaps if there was some consensus on the use of this library, the code could be cleaned up and updated:
- remove the non-working cygwin (and mingw?) support from the main source tree until such time as it has a reasonable chance of compiling.
- remove all references to the old iostream libraries in win32
- under the assumption that modern compilers support namespaces, drop the name-hiding macros (or at least make it clean and optional) and put in (optional) namespace support
- make explicit the platform, compiler, and library support, so that developpers do not see "cygwin" in the source and assume that cygwin is supported. Also, make it clear what works and what is in-progress: Win32 support is in progress, for one.
I'd be more than happy to help make changes, but I don't want to step on someone else's beloved fixes or hacks, or pull support from some platform that someone actually uses.
Thanks,
-Kevin
Ideally we would like to nativily compile msv directly in the win32 tree, and have the posix tree target cygwin when pthread support in cygwin is more complete. There have been a lot of recent changes with merging code between the win32 and posix trees and some of these have caused minor and odd problems with the last release.
The use of iostream in win32 has been an issue another Common C++ developer has been working on resolve.
Namespace support is being adopted for Common C++ 2.0. Until recently there were systems (like FreeBSD) that had shipped with older gcc compilers that did not do namespaces well. I agree about making the macros optional and namespaces optional, and a start for that was done with some namespace "macros" recently added.