activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQCPP-404) compilation errors on Windows because of Unicode set in project file
Date Wed, 20 Jun 2012 15:45:43 GMT

     [ https://issues.apache.org/jira/browse/AMQCPP-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Timothy Bish resolved AMQCPP-404.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 3.4.4

Fix applied in trunk and 3.4.x branch
                
> compilation errors on Windows because of Unicode set in project file
> --------------------------------------------------------------------
>
>                 Key: AMQCPP-404
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-404
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 3.4.2
>         Environment: OS Windows, Visual Studio 2008
>            Reporter: Ivan Pechorin
>            Assignee: Timothy Bish
>            Priority: Trivial
>             Fix For: 3.4.4
>
>
> There are compilation errors because of "Unicode" character set is set in Windows project
files.
> 1>System.cpp
> 1>..\src\main\decaf\lang\System.cpp(455) : error C2664: 'strlen' : cannot convert
parameter 1 from 'LPTSTR' to 'const char *'
> 1>        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style
cast or function-style cast
> 1>..\src\main\decaf\lang\System.cpp(461) : error C2664: 'std::vector<_Ty>::push_back'
: cannot convert parameter 1 from 'LPTSTR' to 'const std::string &'
> 1>        with
> 1>        [
> 1>            _Ty=std::string
> 1>        ]
> 1>        Reason: cannot convert from 'LPTSTR' to 'const std::string'
> 1>        No constructor could take the source type, or constructor overload resolution
was ambiguous
> 1>..\src\main\decaf\lang\System.cpp(462) : error C2664: 'strlen' : cannot convert
parameter 1 from 'LPTSTR' to 'const char *'
> 1>        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style
cast or function-style cast
> Fixed trivially by changing from "Unicode" to "Not set".
> Is there any reason to ship the library with "Unicode" character set by default? I try
to avoid the Unicode builds where possible, and don't see any reason why a messaging client
(or any other infrastructure-type library) needs it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message