Thread: [Cppcms-users] feedback after testing cppcms svn trunk compiled with msvc2005
Brought to you by:
artyom-beilis
Menu
▾
▴
cppcms-users
|
From: Cristian O. <one...@gm...> - 2011-01-20 10:37:39
|
Hi, I'm currently testing cppcms from svn trunk compiled with msvc2005 (I know that the wiki states that only MSVC9 and MSVC10 are supported but MSVC8 works just as fine). As a first impression I would like to say that the lib looks really good. I intend to use it in combination with apache+mod_fastcgi. After a few days of working with it I found the following issues and I want to share them with you: 1. The application does not handle shutdown requests sent by mod_fastcgi; a simple solution would be to add the mechanism used in libfcgi (the fastcgi client implementation provided by www.fastcgi.com) see the attached apache_mod_fastcgi_nice_shutdown.patch - nothe that the implementation could be improved to use a cppcms thread instead of _beginthread. 2. When trying the hello/form example I was getting an infinite loop in the application due to the fact that an input stream was tested only for eof and not for validity see http_request_infinite_loop.patch. These two where critical issues that I would like to see solved somehow in cppcms. The following two patches are just insignificant improvements: 3. Enable using external boost lib while running cmake configure and add an extra name for the zlib library on Windows cmake_permit_using_external_boost_and_zlib_on_win_name.patch 4. This fixes the only code incompatibility I have found on msvc2005 (mscv_2005_compatibility.patch) but googleing revealed that this can be fixed using a never winsdk so this is only important if upgrading is not an option This is all for now. Regards, Cristian Oneț |
|
From: Cristian O. <one...@gm...> - 2011-01-20 11:09:52
|
On Thu, Jan 20, 2011 at 12:37 PM, Cristian Oneț <one...@gm...> wrote: > Hi, > > I'm currently testing cppcms from svn trunk compiled with msvc2005 (I > know that the wiki states that only MSVC9 and MSVC10 are supported but > MSVC8 works just as fine). > As a first impression I would like to say that the lib looks really > good. I intend to use it in combination with apache+mod_fastcgi. > After a few days of working with it I found the following issues and I > want to share them with you: > 1. The application does not handle shutdown requests sent by > mod_fastcgi; a simple solution would be to add the mechanism used in > libfcgi (the fastcgi client implementation provided by > www.fastcgi.com) see the attached > apache_mod_fastcgi_nice_shutdown.patch - nothe that the implementation > could be improved to use a cppcms thread instead of _beginthread. > 2. When trying the hello/form example I was getting an infinite loop > in the application due to the fact that an input stream was tested > only for eof and not for validity see > http_request_infinite_loop.patch. > These two where critical issues that I would like to see solved > somehow in cppcms. The following two patches are just insignificant > improvements: > 3. Enable using external boost lib while running cmake configure and > add an extra name for the zlib library on Windows > cmake_permit_using_external_boost_and_zlib_on_win_name.patch > 4. This fixes the only code incompatibility I have found on msvc2005 > (mscv_2005_compatibility.patch) but googleing revealed that this can > be fixed using a never winsdk so this is only important if upgrading > is not an option > This is all for now. > > Regards, > Cristian Oneț > Sorry I have one more patch that I forgot about. When running with apache+mod_fastcgi the application runs in context of NTAUTHORITY\SYSTEM which can't use CryptAcquireContext the way it's used by a normal user (so it's failing) see [1] but from the msdn docs [2] it seems that cppcms should call CryptAcquireContext with CRYPT_VERIFYCONTEXT flag (see the flag's description). [1] http://www.eggheadcafe.com/software/aspnet/32785121/how-to-prevent-microsoft-csps-from-using-dpapi.aspx [2] http://msdn.microsoft.com/en-us/library/aa379886%28v=vs.85%29.aspx Regards, Cristian Oneț |
|
From: Artyom <art...@ya...> - 2011-01-20 11:30:42
|
First of all thanks for contributions they are very important! > Hi, > > I'm currently testing cppcms from svn trunk compiled with msvc2005 (I > know that the wiki states that only MSVC9 and MSVC10 are supported but > MSVC8 works just as fine). > As a first impression I would like to say that the lib looks really > good > I intend to use it in combination with apache+mod_fastcgi. > After a few days of working with it I found the following issues and I > want to share them with you: Basically I just had no chance to test in on MSVC8 so I published what I could test. If it works fine I'll add it to the supported platforms list (even thou it wouldn't be used in nightly builds and tests) > 1. The application does not handle shutdown requests sent by > mod_fastcgi; a simple solution would be to add the mechanism used in > libfcgi (the fastcgi client implementation provided by > www.fastcgi.com) see the attached > apache_mod_fastcgi_nice_shutdown.patch - nothe that the implementation > could be improved to use a cppcms thread instead of _beginthread. Ok this is good because I hadn't tested it with Apache on Windows. Few points: 1. Why and how does this work? HANDLE shutdownEvent = (HANDLE) atoi(val); Isn't handle has meaning inside process only? Or it can be shared between processes this way? 2. I think there should be better handling of shutdown: It should wait for multiple objects because process may go down for other reason and the thread should be stopped as well. BTW: booster::thread can be used for this purpose. it should be something like a special class that stops its thread in destructor or something like that. I'll take a look on this. > 2. When trying the hello/form example I was getting an infinite loop > in the application due to the fact that an input stream was tested > only for eof and not for validity see > http_request_infinite_loop.patch. Thanks, you are right, I'll commit it. > These two where critical issues that I would like to see solved > somehow in cppcms. The following two patches are just insignificant > improvements: > 3. Enable using external boost lib while running cmake configure and > add an extra name for the zlib library on Windows > cmake_permit_using_external_boost_and_zlib_on_win_name.patch Actually CppCMS no longer supports external boost and this is for ABI stability reason - I don't want users to have programs to fail because he uses boost_1_43 in their program and CppCMS was compiled against 1_44 or 1_36. The internal boost is not only subset of boost but rather renamed version of it (namespace boost -> namespace cppcms_boost) These ifdefs should go in any case. > 4. This fixes the only code incompatibility I have found on msvc2005 > (mscv_2005_compatibility.patch) but googleing revealed that this can > be fixed using a never winsdk so this is only important if upgrading > is not an option > This is all for now. > Thanks I'll commit this as well. Thank you very much, Artyom |
|
From: Artyom <art...@ya...> - 2011-01-20 11:34:46
|
> From: Cristian Oneț <one...@gm...> > > Sorry I have one more patch that I forgot about. When running with > apache+mod_fastcgi the application runs in context of > NTAUTHORITY\SYSTEM which can't use CryptAcquireContext the way it's > used by a normal user (so it's failing) see [1] but from the msdn docs > [2] it seems that cppcms should call CryptAcquireContext with > CRYPT_VERIFYCONTEXT flag (see the flag's description). > > [1] >http://www.eggheadcafe.com/software/aspnet/32785121/how-to-prevent-microsoft-csps-from-using-dpapi.aspx > > [2] http://msdn.microsoft.com/en-us/library/aa379886%28v=vs.85%29.aspx > Ok I'll commit this as well. As you understand I'm mostly Linux/Unix developer with good background in Windows. so such things are quite hard to catch them for me. Thanks! Artyom |
|
From: Cristian O. <one...@gm...> - 2011-01-20 11:53:16
|
On Thu, Jan 20, 2011 at 1:34 PM, Artyom <art...@ya...> wrote: >> From: Cristian Oneț <one...@gm...> >> >> Sorry I have one more patch that I forgot about. When running with >> apache+mod_fastcgi the application runs in context of >> NTAUTHORITY\SYSTEM which can't use CryptAcquireContext the way it's >> used by a normal user (so it's failing) see [1] but from the msdn docs >> [2] it seems that cppcms should call CryptAcquireContext with >> CRYPT_VERIFYCONTEXT flag (see the flag's description). >> >> [1] >>http://www.eggheadcafe.com/software/aspnet/32785121/how-to-prevent-microsoft-csps-from-using-dpapi.aspx >> >> [2] http://msdn.microsoft.com/en-us/library/aa379886%28v=vs.85%29.aspx >> > > Ok > > I'll commit this as well. > > As you understand I'm mostly Linux/Unix developer > with good background in Windows. > so such things are quite hard to catch them for me. Sure, I understand, I also work on both Linux and Windows and from what info I got on the project I imagined that this is the case. Thanks for taking care of the problems found so far, I'll keep reporting stuff that I find. > Thanks! > Artyom Regards, Cristian |
|
From: Cristian O. <one...@gm...> - 2011-01-20 12:06:17
|
On Thu, Jan 20, 2011 at 1:30 PM, Artyom <art...@ya...> wrote: > First of all thanks for contributions > they are very important! > > > > >> Hi, >> >> I'm currently testing cppcms from svn trunk compiled with msvc2005 (I >> know that the wiki states that only MSVC9 and MSVC10 are supported but >> MSVC8 works just as fine). >> As a first impression I would like to say that the lib looks really >> good >> I intend to use it in combination with apache+mod_fastcgi. >> After a few days of working with it I found the following issues and I >> want to share them with you: > > Basically I just had no chance to test in on MSVC8 so I published > what I could test. If it works fine I'll add it to the > supported platforms list (even thou it wouldn't be used in nightly builds and > tests) > >> 1. The application does not handle shutdown requests sent by >> mod_fastcgi; a simple solution would be to add the mechanism used in >> libfcgi (the fastcgi client implementation provided by >> www.fastcgi.com) see the attached >> apache_mod_fastcgi_nice_shutdown.patch - nothe that the implementation >> could be improved to use a cppcms thread instead of _beginthread. > > Ok this is good because I hadn't tested it with Apache on Windows. > > Few points: > > 1. Why and how does this work? > > HANDLE shutdownEvent = (HANDLE) atoi(val); > > Isn't handle has meaning inside process only? Or it > can be shared between processes this way? AFAICT from looking at libfcgi and mod_fastcgi code mod_fastcfg places the shutdown event handle in the client's environment in the _FCGI_SHUTDOWN_EVENT_ variable. As I've said I've taken the code from libfcgi\os_win32.c (www.fastcgi.com/dist/fcgi-2.4.1-SNAP-0910052249.tar.gz), it works so it means that is can be shared between parent and child processes. > 2. I think there should be better handling of shutdown: > > It should wait for multiple objects because process may > go down for other reason and the thread should be stopped > as well. > > BTW: booster::thread can be used for this purpose. > > it should be something like a special class > that stops its thread in destructor or something > like that. > > I'll take a look on this. Thanks, the better handling would be even "better" :). > >> 2. When trying the hello/form example I was getting an infinite loop >> in the application due to the fact that an input stream was tested >> only for eof and not for validity see >> http_request_infinite_loop.patch. > > Thanks, you are right, I'll commit it. > >> These two where critical issues that I would like to see solved >> somehow in cppcms. The following two patches are just insignificant >> improvements: >> 3. Enable using external boost lib while running cmake configure and >> add an extra name for the zlib library on Windows >> cmake_permit_using_external_boost_and_zlib_on_win_name.patch > > Actually CppCMS no longer supports external boost and this > is for ABI stability reason - I don't want users > to have programs to fail because he uses boost_1_43 in their > program and CppCMS was compiled against 1_44 or 1_36. > > The internal boost is not only subset of boost but rather > renamed version of it (namespace boost -> namespace cppcms_boost) > > These ifdefs should go in any case. It's good to know this. But boost is not a runtime dependency meaning that after building cppcms if I use boost in the application linked with cppcms I don't need to use the same version of boost, am I correct? > >> 4. This fixes the only code incompatibility I have found on msvc2005 >> (mscv_2005_compatibility.patch) but googleing revealed that this can >> be fixed using a never winsdk so this is only important if upgrading >> is not an option >> This is all for now. >> > > Thanks I'll commit this as well. Thanks, Cristian > > > Thank you very much, > Artyom |
|
From: Artyom <art...@ya...> - 2011-01-20 12:31:22
|
> AFAICT from looking at libfcgi and mod_fastcgi code mod_fastcfg places > the shutdown event handle in the client's environment in the > _FCGI_SHUTDOWN_EVENT_ variable. As I've said I've taken the code from > libfcgi\os_win32.c > (www.fastcgi.com/dist/fcgi-2.4.1-SNAP-0910052249.tar.gz), it works so > it means that is can be shared between parent and child processes. > Ok, I'll take a look on this. > > > > The internal boost is not only subset of boost but rather > > renamed version of it (namespace boost -> namespace cppcms_boost) > > > > These ifdefs should go in any case. > > It's good to know this. But boost is not a runtime dependency meaning > that after building cppcms if I use boost in the application linked > with cppcms I don't need to use the same version of boost, am I > correct? > Not correct. For example you use in cppcms boost::foo() - from boost 1_36 This symbol is defined in cppcms.lib (assuming it is statically linked) Now you are using boost_1_45 and you use boost::foo() as well and new boost::foo() is not binary compatible with 1_36 Now linker may actually use the boost::foo from cppcms and not from the header you compiled with (and this actually happens). Now more then that if you use shared object under Unix it would happen with them as well. It is quite easy to show how programs using different versions of boost::regex in same code base crash. So no you can't - even if the symbols are inline symbols and the library is header only. Because compiler may create non-inlined weak symbols and share them at link stage (and this really happens) in order to reduce the size of the code. Read this for more details: http://stackoverflow.com/questions/836875/creating-library-with-backward-compatible-abi-that-uses-boost Regards, Artyom |
|
From: Cristian O. <one...@gm...> - 2011-01-20 13:23:49
|
On Thu, Jan 20, 2011 at 2:31 PM, Artyom <art...@ya...> wrote: >> AFAICT from looking at libfcgi and mod_fastcgi code mod_fastcfg places >> the shutdown event handle in the client's environment in the >> _FCGI_SHUTDOWN_EVENT_ variable. As I've said I've taken the code from >> libfcgi\os_win32.c >> (www.fastcgi.com/dist/fcgi-2.4.1-SNAP-0910052249.tar.gz), it works so >> it means that is can be shared between parent and child processes. >> > > Ok, I'll take a look on this. > >> > >> > The internal boost is not only subset of boost but rather >> > renamed version of it (namespace boost -> namespace cppcms_boost) >> > >> > These ifdefs should go in any case. >> >> It's good to know this. But boost is not a runtime dependency meaning >> that after building cppcms if I use boost in the application linked >> with cppcms I don't need to use the same version of boost, am I >> correct? >> > > Not correct. > > For example you use in cppcms > > boost::foo() - from boost 1_36 > > This symbol is defined in cppcms.lib (assuming it is statically linked) > > Now you are using boost_1_45 and you use boost::foo() as well and > new boost::foo() is not binary compatible with 1_36 > > Now linker may actually use the boost::foo from cppcms and not from the > header you compiled with (and this actually happens). > > Now more then that if you use shared object under Unix it would > happen with them as well. It is quite easy to show how programs > using different versions of boost::regex in same code base > crash. > > So no you can't - even if the symbols are inline symbols and the library > is header only. Because compiler may create non-inlined weak symbols > and share them at link stage (and this really happens) in order to reduce > the size of the code. > > Read this for more details: > > > http://stackoverflow.com/questions/836875/creating-library-with-backward-compatible-abi-that-uses-boost > > > Regards, > Artyom Then this means that cppcms must be compiled with the same version of boost as the application. Doesn't this imply usage of an external boost (the one that is shared with the application)? And you just said that using an external boost is not going to be supported anymore. I'm thinking of using the external boost feature only to compile cppcms and the application with the same version of boost (not the opposite that you are trying to avoid). Using an internal version of boost is what really opens the door for an application to use a different version of boost then the one cppcms uses. By the way which is the minimum version of boost which can be used to compile cppcms? Thanks, Cristian |
|
From: Artyom <art...@ya...> - 2011-01-20 13:38:16
|
> Then this means that cppcms must be compiled with the same version of
> boost as the application.
> Doesn't this imply usage of an external
> boost (the one that is shared with the application)? And you just said
> that using an external boost is not going to be supported anymore.
No this means that CppCMS should not be compiled against Boost. Period.
I'm quite surprised it worked for you at all because it shouldn't.
Also I compile in some boost code so (iostreams) so you may get something
very wrong as internal code may use different version.
I think I'll remove this "EXTERNAL_BOOST" at all.
> I'm
> thinking of using the external boost feature only to compile cppcms
> and the application with the same version of boost (not the opposite
> that you are trying to avoid).
CppCMS 1.x.x is going to handle stable ABI.
So if you once compiled and application against version
1.0.0 then you can easily ugrade the dll for example to
1.8.3 and it should work out of the box same as for
Qt4 or GTK2
Boost does not support this, more then that it breaks
ABI every 3 month...
> Using an internal version of boost is
> what really opens the door for an application to use a different
> version of boost then the one cppcms uses.
Yes exactly.
> By the way which is the
> minimum version of boost which can be used to compile cppcms?
>
I use internally 1.39 and slowly use it less and less in
favor of booster - boost like library with some adopted/taken/redesigned
boost API for ABI stability.
Artyom
|
|
From: Cristian O. <one...@gm...> - 2011-01-20 13:50:58
|
On Thu, Jan 20, 2011 at 3:38 PM, Artyom <art...@ya...> wrote: >> Then this means that cppcms must be compiled with the same version of >> boost as the application. >> Doesn't this imply usage of an external >> boost (the one that is shared with the application)? And you just said >> that using an external boost is not going to be supported anymore. > > No this means that CppCMS should not be compiled against Boost. Period. > > I'm quite surprised it worked for you at all because it shouldn't. > > Also I compile in some boost code so (iostreams) so you may get something > very wrong as internal code may use different version. > > I think I'll remove this "EXTERNAL_BOOST" at all. > > >> I'm >> thinking of using the external boost feature only to compile cppcms >> and the application with the same version of boost (not the opposite >> that you are trying to avoid). > > CppCMS 1.x.x is going to handle stable ABI. > > So if you once compiled and application against version > 1.0.0 then you can easily ugrade the dll for example to > 1.8.3 and it should work out of the box same as for > Qt4 or GTK2 > > Boost does not support this, more then that it breaks > ABI every 3 month... > >> Using an internal version of boost is >> what really opens the door for an application to use a different >> version of boost then the one cppcms uses. > > Yes exactly. > >> By the way which is the >> minimum version of boost which can be used to compile cppcms? >> > > I use internally 1.39 and slowly use it less and less in > favor of booster - boost like library with some adopted/taken/redesigned > boost API for ABI stability. > > Artyom Then I'm back to my original question: Can I use boost with my application if cppcms uses another version of boost internally? From what you have said "It is quite easy to show how programs using different versions of boost::regex in same code base crash." I get that *NO* I can't. But in the same time you say that cppcms should not be compiled against an external boost so how could I use boost together with cppcms in my application? Thanks, Cristian |
|
From: Artyom <art...@ya...> - 2011-01-20 14:08:12
|
>
> Then I'm back to my original question: Can I use boost with my
> application if cppcms uses another version of boost internally?
> From
> what you have said "It is quite easy to show how programs using
> different versions of boost::regex in same code base crash." I get
> that *NO* I can't. But in the same time you say that cppcms should not
> be compiled against an external boost so how could I use boost
> together with cppcms in my application?
>
Ok, now I understand what you ask.
Of course you can!
The internal boost is placed in "cppcms_boost" namespace so it would
not collide with any other version of boost you use, this is
the idea.
Artyom
|
|
From: Cristian O. <one...@gm...> - 2011-01-20 14:11:38
|
On Thu, Jan 20, 2011 at 4:08 PM, Artyom <art...@ya...> wrote: >> >> Then I'm back to my original question: Can I use boost with my >> application if cppcms uses another version of boost internally? >> From >> what you have said "It is quite easy to show how programs using >> different versions of boost::regex in same code base crash." I get >> that *NO* I can't. But in the same time you say that cppcms should not >> be compiled against an external boost so how could I use boost >> together with cppcms in my application? >> > > Ok, now I understand what you ask. > > Of course you can! > > The internal boost is placed in "cppcms_boost" namespace so it would > not collide with any other version of boost you use, this is > the idea. > > Artyom Great then :) sorry for the misunderstanding. Regards, Cristian |
|
From: Artyom <art...@ya...> - 2011-01-21 06:15:48
|
Hello, I've committed infinite loop and urandom patches. - the backtrace patch, no needed to do it the way you did as I already has support of older SDK. Just changed ifdef check if it works - Apache/win32 shutdown support added as well, pleas check this. Artyom ----- Original Message ---- > From: Cristian Oneț <one...@gm...> > To: cpp...@li... > Sent: Thu, January 20, 2011 12:37:32 PM > Subject: [Cppcms-users] feedback after testing cppcms svn trunk compiled with >msvc2005 > > Hi, > > I'm currently testing cppcms from svn trunk compiled with msvc2005 (I > know that the wiki states that only MSVC9 and MSVC10 are supported but > MSVC8 works just as fine). > As a first impression I would like to say that the lib looks really > good. I intend to use it in combination with apache+mod_fastcgi. > After a few days of working with it I found the following issues and I > want to share them with you: > 1. The application does not handle shutdown requests sent by > mod_fastcgi; a simple solution would be to add the mechanism used in > libfcgi (the fastcgi client implementation provided by > www.fastcgi.com) see the attached > apache_mod_fastcgi_nice_shutdown.patch - nothe that the implementation > could be improved to use a cppcms thread instead of _beginthread. > 2. When trying the hello/form example I was getting an infinite loop > in the application due to the fact that an input stream was tested > only for eof and not for validity see > http_request_infinite_loop.patch. > These two where critical issues that I would like to see solved > somehow in cppcms. The following two patches are just insignificant > improvements: > 3. Enable using external boost lib while running cmake configure and > add an extra name for the zlib library on Windows > cmake_permit_using_external_boost_and_zlib_on_win_name.patch > 4. This fixes the only code incompatibility I have found on msvc2005 > (mscv_2005_compatibility.patch) but googleing revealed that this can > be fixed using a never winsdk so this is only important if upgrading > is not an option > This is all for now. > > Regards, > Cristian Oneț > |
|
From: Cristian O. <one...@gm...> - 2011-01-21 09:25:27
Attachments:
apache_event_handler.patch
|
On Fri, Jan 21, 2011 at 8:15 AM, Artyom <art...@ya...> wrote: > Hello, > > I've committed infinite loop and urandom patches. > - the backtrace patch, no needed to do it the way you did > as I already has support of older SDK. Just changed ifdef > check if it works About the backtrace fix: I thought of that yesterday but when I tried it I was getting a crash (ESP not maintained correctly) but today when I've tried it again it works as expected so I must have messed up my build yesterday - the bottom line is that the backtrace code from trunk works here also > - Apache/win32 shutdown support added as well, pleas check this. Thanks, it looks much better that way but it still needs a fix. After the scope is left the objects are destroyed thus causing a crash (see the attached patch for one possible solution). > Artyom Regards, Cristian |
|
From: Cristian O. <one...@gm...> - 2011-01-21 10:57:15
Attachments:
msvc_wchart_as_native_type_not_set_fix.patch
|
Hi, I just find another small issue while trying to use #include <cppcms/json.h> in my application. In the "wonderful world" of msvc you can choose how wchar_t is interpreted by the compiler [1] so if "/Zc:wchar_t-" is used wchar_t is defined as "unsigned short" and not as a native type. In this case CPPCMS_JSON_SPECIALIZE_INT(wchar_t) and CPPCMS_JSON_SPECIALIZE_INT(unsigned short) will be one and the same and result in a compilation error which can be fixed by the attached patch. [1] http://msdn.microsoft.com/en-us/library/dh8che7s%28v=vs.80%29.aspx Regards, Cristian |
|
From: Artyom <art...@ya...> - 2011-01-21 11:38:08
|
> From: Cristian Oneț <one...@gm...> > > I just find another small issue while trying to use #include > <cppcms/json.h> in my application. In the "wonderful world" of msvc > you can choose how wchar_t is interpreted by the compiler [1] so if > "/Zc:wchar_t-" is used wchar_t is defined as "unsigned short" and not > as a native type. In this case CPPCMS_JSON_SPECIALIZE_INT(wchar_t) and > CPPCMS_JSON_SPECIALIZE_INT(unsigned short) will be one and the same > and result in a compilation error which can be fixed by the attached > patch. > > [1] http://msdn.microsoft.com/en-us/library/dh8che7s%28v=vs.80%29.aspx > > Regards, > Cristian > C++ standard requires that wchar_t is distinct type, and defining it same type as unsigned short is not right and will not be supported. According to link, MSVC uses /Zc:wchar_t by default so it should be distinct type. If this is not default then it should be defined so in compilation options with this compiler. I'm not going to do ifdefs to support broken compiler especially if a simple flag can fix this and new versions of MSVC do this right. Artyom |
|
From: Cristian O. <one...@gm...> - 2011-01-21 11:53:29
|
On Fri, Jan 21, 2011 at 1:38 PM, Artyom <art...@ya...> wrote: > > >> From: Cristian Oneț <one...@gm...> >> >> I just find another small issue while trying to use #include >> <cppcms/json.h> in my application. In the "wonderful world" of msvc >> you can choose how wchar_t is interpreted by the compiler [1] so if >> "/Zc:wchar_t-" is used wchar_t is defined as "unsigned short" and not >> as a native type. In this case CPPCMS_JSON_SPECIALIZE_INT(wchar_t) and >> CPPCMS_JSON_SPECIALIZE_INT(unsigned short) will be one and the same >> and result in a compilation error which can be fixed by the attached >> patch. >> >> [1] http://msdn.microsoft.com/en-us/library/dh8che7s%28v=vs.80%29.aspx >> >> Regards, >> Cristian >> > > C++ standard requires that wchar_t is distinct type, and defining it > same type as unsigned short is not right and will not be supported. > > According to link, MSVC uses /Zc:wchar_t by default so it should > be distinct type. > > If this is not default then it should be defined so in compilation > options with this compiler. > > I'm not going to do ifdefs to support broken compiler especially > if a simple flag can fix this and new versions of MSVC do this right. > > Artyom Fair enough, I can live with that. Regards, Cristian |
|
From: Artyom <art...@ya...> - 2011-01-21 11:39:29
|
> About the backtrace fix: I thought of that yesterday but when I tried
> it I was getting a crash (ESP not maintained correctly) but today when
> I've tried it again it works as expected so I must have messed up my
> build yesterday - the bottom line is that the backtrace code from
> trunk works here also
So I should revert the changeset in backtrace? (MSVC <= 1500)
>
> > - Apache/win32 shutdown support added as well, pleas check this.
> Thanks, it looks much better that way but it still needs a fix. After
> the scope is left the objects are destroyed thus causing a crash (see
> the attached patch for one possible solution).
>
I see. I know what is the problem I'll fix this.
Artyom
|
|
From: Cristian O. <one...@gm...> - 2011-01-21 11:54:34
|
On Fri, Jan 21, 2011 at 1:39 PM, Artyom <art...@ya...> wrote: >> About the backtrace fix: I thought of that yesterday but when I tried >> it I was getting a crash (ESP not maintained correctly) but today when >> I've tried it again it works as expected so I must have messed up my >> build yesterday - the bottom line is that the backtrace code from >> trunk works here also > > So I should revert the changeset in backtrace? (MSVC <= 1500) No, the changeset is OK and working. >> >> > - Apache/win32 shutdown support added as well, pleas check this. >> Thanks, it looks much better that way but it still needs a fix. After >> the scope is left the objects are destroyed thus causing a crash (see >> the attached patch for one possible solution). >> > > I see. I know what is the problem I'll fix this. Thanks, Cristian |
|
From: Artyom <art...@ya...> - 2011-01-21 14:51:54
|
> > - Apache/win32 shutdown support added as well, pleas check this.
>
> Thanks, it looks much better that way but it still needs a fix. After
> the scope is left the objects are destroyed thus causing a crash (see
> the attached patch for one possible solution).
>
I've committed the fix.
Please update and check if it works.
Note: you need to revert that "static" fix src/service.cpp in order to make
sure that the fix I've committed works.
Artyom
|
|
From: Cristian O. <one...@gm...> - 2011-01-21 15:14:48
|
On Fri, Jan 21, 2011 at 4:51 PM, Artyom <art...@ya...> wrote: > > >> > - Apache/win32 shutdown support added as well, pleas check this. >> >> Thanks, it looks much better that way but it still needs a fix. After >> the scope is left the objects are destroyed thus causing a crash (see >> the attached patch for one possible solution). >> > > I've committed the fix. > Please update and check if it works. > > Note: you need to revert that "static" fix src/service.cpp in order to make > sure that the fix I've committed works. Thanks, your fix works the application is stopping as expected when the server is stopping. Regards, Cristian |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X