[thread] barrier.cpp don't compile with msvc60 & stlport]
Hi, with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60. I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3" and get the following errortext: ...\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero."); because the StlPort defines invalid_argument as: class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif }; With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc") Sven
Sven Johannsen wrote:
Hi,
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3"
and get the following errortext: ....\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
because the StlPort defines invalid_argument as:
class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif };
Is that the complete definition?
With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc")
Google tells me that this "Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig"?" translates to "Source type could be accepted by no constructor, or the dissolution of overloading of the constructor is ambiguous." From this, I would guess either that the invalid_argument class has another constructor that you didn't show that is making the conversion ambiguous, or that the string class either has no constructor that takes a single char* argument, or else that constructor is marked "explicit", or else there are multiple constructors and the choice between them is ambiguous. Mike
Michael Glassford wrote:
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
I use the following bjam command: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\develop\STLPort" "-sSTLPORT_VERSION=4.5.3"
and get the following errortext: ....\boost-23072004\libs\thread\build\..\src\barrier.cpp(21) : error C2440: 'type cast' : 'char [22]' kann nicht in 'class _STL::invalid_argument' konvertiert werden Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument' I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
because the StlPort defines invalid_argument as:
class _STLP_CLASS_DECLSPEC invalid_argument : public logic_error { public: invalid_argument(const string& __arg) : logic_error(__arg) {} # ifdef _STLP_OWN_IOSTREAMS ~invalid_argument() _STLP_NOTHROW_INHERENTLY; # endif };
Is that the complete definition?
yes. there is no explizit or something else.
With the microsoft stl everything compile fine. (bjam "-sTOOLS=msvc")
Google tells me that this "Quelltyp konnte von keinem Konstruktor angenommen werden, oder die Ueberladungsaufloesung des Konstruktors ist mehrdeutig"?" translates to "Source type could be accepted by no constructor, or the dissolution of overloading of the constructor is ambiguous." From this, I would guess either that the invalid_argument
i found the english errortext in the msdn: () Compiler Error C2440 'conversion' : cannot convert from 'type1' to 'type2'
ambiguous." From this, I would guess either that the invalid_argument class has another constructor that you didn't show that is making the conversion ambiguous, or that the string class either has no constructor that takes a single char* argument, or else that constructor is marked "explicit", or else there are multiple constructors and the choice between them is ambiguous.
Mike
the ms-stl defines invalid_argument with explicit and // CLASS invalid_argument class invalid_argument : public logic_error { public: explicit invalid_argument(const string& _S) : logic_error(_S) {} virtual ~invalid_argument() {} protected: virtual void _Doraise() const {_RAISE(*this); } }; there must something differend. does nobody use msvc and stlport and the current boost-version? Sven
Sven Johannsen writes:
does nobody use msvc and stlport and the current boost-version?
This configuration is being tested on daily basis, see "msvc-stlport" column in http://www.meta-comm.com/engineering/boost-regression/developer/summary.html Hmm, the toolset name could be more specific. It's MSVC 6.5 + STLPort 4.5.3. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Sven Johannsen writes:
does nobody use msvc and stlport and the current boost-version?
This configuration is being tested on daily basis, see "msvc-stlport" column in http://www.meta-comm.com/engineering/boost-regression/developer/summary.html
Hmm, the toolset name could be more specific. It's MSVC 6.5 + STLPort 4.5.3.
cool - i use the same configuration! So every has to work ;-)) Why does it compiles on meta-comm and not on my machine? I tried it on two differend machines. (but both with the same stlport) So what's different? I use the ms-iostream - what kind of iostreams is the regressiontest using? Sven
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
[snipped]
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument'
I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
I suspect the header needs to include <string>, note that while <stdexcept> needs to forward declare std::basic_string, it doesn't need the full definition, while the code that generates the error does. John.
Le jeu 29/07/2004 à 12:30, John Maddock a écrit :
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
[snipped]
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument'
I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
I suspect the header needs to include <string>, note that while <stdexcept> needs to forward declare std::basic_string, it doesn't need the full definition, while the code that generates the error does.
I'm interested in knowing if this solution does work. The Boost.Interval library always had (and still has) this kind of error in the regression logs for STLPort-4.5.3. However I couldn't reproduce it with my own version of STLPort. And since nobody seemed to care about this particular platform, I supposed that it was a bug in the old version of STLPort that was later corrected. I would be glad to learn it's only a matter of including <string>. Can anybody confirm that by simply adding #include <string> the compilers don't complain anymore about this kind of error? Regards, Guillaume
Guillaume Melquiond wrote:
Le jeu 29/07/2004 à 12:30, John Maddock a écrit :
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
[snipped]
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument'
I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
I suspect the header needs to include <string>, note that while <stdexcept> needs to forward declare std::basic_string, it doesn't need the full definition, while the code that generates the error does.
I'm interested in knowing if this solution does work. The Boost.Interval library always had (and still has) this kind of error in the regression logs for STLPort-4.5.3. However I couldn't reproduce it with my own version of STLPort. And since nobody seemed to care about this particular platform, I supposed that it was a bug in the old version of STLPort that was later corrected. I would be glad to learn it's only a matter of including <string>. Can anybody confirm that by simply adding #include <string> the compilers don't complain anymore about this kind of error?
Regards,
Guillaume
it works!!!! a small change and everything work fine. Can somebody make these change in the cvs-pool? it's very easy, just add the line: "#include <string>" to the file barrier.cpp. Sven
Sven Johannsen wrote: [snip previous discussion]
it works!!!!
a small change and everything work fine. Can somebody make these change in the cvs-pool?
it's very easy, just add the line: "#include <string>" to the file barrier.cpp.
Done, though instead of changing barrier.cpp, I chose to #include <string> everywhere in the Boost.Threads library that there is a #include <stdexcept> to fix potential similar problems in other places in the future. Mike
Sven Johannsen writes:
Guillaume Melquiond wrote:
Le jeu 29/07/2004 à 12:30, John Maddock a écrit :
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
[snipped]
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument'
I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
I suspect the header needs to include <string>, note that while <stdexcept> needs to forward declare std::basic_string, it doesn't need the full definition, while the code that generates the error does. I'm interested in knowing if this solution does work. The Boost.Interval library always had (and still has) this kind of error in the regression logs for STLPort-4.5.3. However I couldn't reproduce it with my own version of STLPort. And since nobody seemed to care about this particular platform, I supposed that it was a bug in the old version of STLPort that was later corrected. I would be glad to learn it's only a matter of including <string>. Can anybody confirm that by simply adding #include <string> the compilers don't complain anymore about this kind of error? Regards, Guillaume
it works!!!!
a small change and everything work fine. Can somebody make these change in the cvs-pool?
it's very easy, just add the line: "#include <string>" to the file barrier.cpp.
Done. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Sven Johannsen writes:
Guillaume Melquiond wrote:
Le jeu 29/07/2004 à 12:30, John Maddock a écrit :
with the current cvs-version (7/23/2004) i can't build the thread library with stlport 4.5.3 and msvc60.
[snipped]
Sorry about the german error-text. it's something about: can't convert char[22] to 'class _STL::invalid_argument'
I don't know that wrong about: throw std::invalid_argument("count cannot be zero.");
I suspect the header needs to include <string>, note that while <stdexcept> needs to forward declare std::basic_string, it doesn't need the full definition, while the code that generates the error does.
I'm interested in knowing if this solution does work. The Boost.Interval library always had (and still has) this kind of error in the regression logs for STLPort-4.5.3. However I couldn't reproduce it with my own version of STLPort. And since nobody seemed to care about this particular platform, I supposed that it was a bug in the old version of STLPort that was later corrected. I would be glad to learn it's only a matter of including <string>. Can anybody confirm that by simply adding #include <string> the compilers don't complain anymore about this kind of error? Regards, Guillaume
it works!!!!
a small change and everything work fine. Can somebody make these change in the cvs-pool?
it's very easy, just add the line: "#include <string>" to the file barrier.cpp.
Done.
the lib (and dll) compiles. it seems that where was a problem with the native iostreams. (with the stlport iostreams i can't reproduce the error) but the trouble is going on. (see my mailing "[thread] wrong name of the thread lib and dll.") Thanks, Sven
participants (8)
-
Aleksey Gurtovoy -
Guillaume Melquiond -
John Maddock -
Michael Glassford -
Sven Johannsen