gtest compile error with STLPort Debug (MSVC++ 9.0) in death tests

[GoogleCodeExporter]

I am using MSVC 9.0 with STLPort 5.1.5. When I compile gtest with debug
features enabled, including STLPort ones, I get following errors:

CL: /c /nologo /EHsc /GR- /Oi /Zi /W3 /we4150 /DWIN32 /MDd /RTC1 /DDEBUG
/D_DEBUG /D_UNICODE /DUNICODE /D_CRT_SECURE_NO_DEPRECATE /D_STLP_DEBUG=1
/Od /D_STLP_DONT_USE_AUTO_LINK /D_STLP_USE_STATIC_LIB
/D_STLP_STATIC_CONST_INIT_BUG /I "[path
replaced]\Build\..\Libs\STLport\stlport" /D_LIB

gtest-filepath.cc
[path replaced]\Libs\STLport\stlport\stl/type_traits.h(249) : error C2139:
'testing::internal::String' : an undefined class is not allowed as an
argument to compiler intrinsic type trait '__has_trivial_constructor'

[path replaced]\Tests\Libs\gtest\include\gtest/internal/gtest-port.h(568) :
see declaration of 'testing::internal::String'

[path replaced]\Libs\STLport\stlport\stl/_vector.h(137) : see reference to
class template instantiation 'stlpdx_std::__type_traits<_Tp>' being
compiled with
         [
                 _Tp=testing::internal::String
         ]

[path replaced]\Libs\STLport\stlport\stl/debug/_iterator.h(381) : see
reference to class template instantiation
'stlpdx_std::priv::_NonDbg_vector<_Tp,_Alloc>' being compiled with
         [
                 _Tp=testing::internal::String,
                 _Alloc=stlpdx_std::allocator<testing::internal::String>
         ]

[path replaced]\Libs\STLport\stlport\stl/debug/_vector.h(106) : see
reference to class template instantiation
'stlpdx_std::priv::__construct_checker<_Container>' being compiled with
         [

_Container=stlpdx_std::priv::_NonDbg_vector<testing::internal::String,stlpdx_std
::allocator<testing::internal::String>>
         ]

[path replaced]\Tests\Libs\gtest\include\gtest/internal/gtest-port.h(734) :
see reference to class template instantiation 'stlpdx_std::vector<_Tp>'
being compiled with
         [
                 _Tp=testing::internal::String
         ]

[path replaced]\Libs\STLport\stlport\stl/type_traits.h(250) : error C2139:
'testing::internal::String' : an undefined class is not allowed as an
argument to compiler intrinsic type trait '__has_trivial_copy'

[path replaced]\Tests\Libs\gtest\include\gtest/internal/gtest-port.h(568) :
see declaration of 'testing::internal::String'

[path replaced]\Libs\STLport\stlport\stl/type_traits.h(251) : error C2139:
'testing::internal::String' : an undefined class is not allowed as an
argument to compiler intrinsic type trait '__has_trivial_assign'

[path replaced]\Tests\Libs\gtest\include\gtest/internal/gtest-port.h(568) :
see declaration of 'testing::internal::String'

[path replaced]\Libs\STLport\stlport\stl/type_traits.h(252) : error C2139:
'testing::internal::String' : an undefined class is not allowed as an
argument to compiler intrinsic type trait '__has_trivial_destructor'

[path replaced]\Tests\Libs\gtest\include\gtest/internal/gtest-port.h(568) :
see declaration of 'testing::internal::String'

[path replaced]\Libs\STLport\stlport\stl/type_traits.h(253) : error C2139:
'testing::internal::String' : an undefined class is not allowed as an
argument to compiler intrinsic type trait '__is_pod'

[path replaced]\Tests\Libs\gtest\include\gtest/internal/gtest-port.h(568) :
see declaration of 'testing::internal::String'

Exact reason of an error is in gtest-port.h:734 and in gtest-port.h:737.
There are vectors of Strings defined while String is still a forward
declaration. STLPort vector tries to apply various type checks to its
argument first checking if argument has trivial constructor and fails since
String isn't defined yet. 

Even more fun is that this code is necessary only for death tests that I am
not going to use for my project. I tried patching gtest to undefine
GTEST_HAS_DEATH_TESTS, but this resulted in unresolved externals a bit later.

I've made a workaround for this bug that is ugly, but is good enough for
me. Added the following lines:

#ifdef _STLP_DEBUG
    #define __has_trivial_constructor(x) true
    #define __has_trivial_copy(x) true
    #define __has_trivial_assign(x) true
    #define __has_trivial_assign(x) true
    #define __has_trivial_destructor(x) true
    #define __is_pod(x) true
#endif

to the very beginning of gtest-port.h and gtest-test-part.cc files.

Possible solutions are:
1. Fully defining String class before its first usage
2. Allowing user to explicitly exclude death tests without leaving him with
all these unresolved externals.
3. Creating workarounds like the one above in case of STLPort on MSVC++ 9.0. 

I could have been created patch and submit it, but I don't know google
tests code good enough.

Could anyone please handle this issue? I want to start automated testing in
C++ in my own small project and I would be happy if I can use google tests
for it.

If I could help somehow, please notify me.

Original issue reported on code.google.com by Anton.De...@gmail.com on 26 Nov 2009 at 11:04

[GoogleCodeExporter]

Found a much nicer workaround that may be good enough to go to release. Please 
check
the patch attached. The only thing that is need to be done is to check if we are
actually using STLPort and surround the patch with that checks.

Original comment by Anton.De...@gmail.com on 26 Nov 2009 at 11:47

• Added labels: ****
• Removed labels: ****

Attachments:

• gtest-issue228-patch.patch

[GoogleCodeExporter]

Original comment by w...@google.com on 5 Dec 2009 at 7:12

• Changed state: Accepted
• Added labels: OpSys-All
• Removed labels: ****

[GoogleCodeExporter]

Sorry this has fallen through the crack, Anton.  Since it has been so long, I 
wonder if the problem still exists in the latest version of gtest.  Could you 
let us know?  Or, are you still interested in getting this fixed?  Thanks.

Original comment by w...@google.com on 8 Sep 2010 at 6:15

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by w...@google.com on 8 Sep 2010 at 6:15

• Changed title: gtest compile error with STLPort Debug (MSVC++ 9.0) in death tests
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

The project that caused initial troubles is abandoned now, so personally for me 
this issue isn't important anymore.

If you think that it may be important for others, please tell me and I will try 
to reproduce an issue in my spare time.

Original comment by Anton.De...@gmail.com on 8 Sep 2010 at 6:22

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks for the quick reply and the offer to help, Anton!  We haven't heard no 
other request on this, so I'll close it as won't fix for now.

Original comment by w...@google.com on 8 Sep 2010 at 6:30

• Changed state: WontFix
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Hi Guys,

 I am using gtest for my product which used stlport. I was getting following errors.

error C2784: 'stlp_std::basic_istream<_CharT,_Traits> 
&stlp_std::getline(stlp_std::basic_istream<_CharT,_Traits> 
&,stlp_std::basic_string<_CharT,_Traits,_Alloc> &)' : could not deduce template 
argument for 'stlp_std::basic_string<_CharT,_Traits,_Alloc> &' from 'twine'

error C2784: 'stlp_std::basic_istream<_CharT,_Traits> 
&stlp_std::getline(stlp_std::basic_istream<_CharT,_Traits> 
&,stlp_std::basic_string<_CharT,_Traits,_Alloc> &)' : could not deduce template 
argument for 'stlp_std::basic_istream<_CharT,_Traits> &' from 
'stlp_std::ifstream'

Original comment by rdesigan...@gmail.com on 12 Nov 2014 at 6:04

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Do you know if the problem with STLPort compilation has been fixed now?

Thanks and Regards,
Raghu

Original comment by rdesigan...@gmail.com on 12 Nov 2014 at 6:05

• Added labels: ****
• Removed labels: ****