[ 
https://issues.apache.org/jira/browse/THRIFT-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017939#comment-13017939
 ] 

Dragan Okiljevic edited comment on THRIFT-1031 at 4/9/11 7:37 PM:
------------------------------------------------------------------

@Xavier

I got the same problem while trying to compile Thrift generated C++ code for 
enums using Visual Studio 2010. The map is supposed to be initialized using two 
iterator arguments (first, and last), so it will containt key/value pairs for 
each enumeration value.

Quick & dirty solution:
Last time I inspected the code, it seemed that this map is not used, so my code 
worked  when I simply removed it from generated code by commenting it from 
Thrift generated files. (Worked not only for compilation, but for runtime usage 
of enums aswell).

I'm not sure why MSVC doesn't recognize TEnumIterator as an iterator type. This 
class overloads '*' operator and returns std::pair<int, const char *> which 
seems to work on *nix, but not MSVC. Am I right?

Anyway, there is many ways to populate std::map either during initialization or 
later, so I guess there is one both compatible with MSVC and *nix and Mac OSX 
compilers.

I would suggest creation of a new issue for this problem, as it is lossely 
connected to the main topic of this one.

      was (Author: dragan.okiljevic):
    @Xavier

I got the same problem while trying to compile Thrift generated C++ code for 
enums using Visual Studio 2010. The map is supposed to be initialized using two 
iterator arguments (first, and last), so it will containt key/value pairs for 
each enumeration value.

Quick & dirty solution:
Last time I inspected the code, it seemed that this map is not used, so my code 
worked  when I simply removed it from generated code by commenting it from 
Thrift generated files. (Worked not only for compilation, but for runtime usage 
of enums aswell).

I'm not sure why MSVC doesn't recognize TEnumIterator as an iterator type. This 
class overrides '*' operator and returns std::pair<int, const char *> which 
seems to work on *nix, but not MSVC. Am I right?

Anyway, there is many ways to populate std::map either during initialization or 
later, so I guess there is one both compatible with MSVC and *nix and Mac OSX 
compilers.

I would suggest creation of a new issue for this problem, as it is lossely 
connected to the main topic of this one.
  
> Patch to compile Thrift for vc++ 9.0 and 10.0
> ---------------------------------------------
>
>                 Key: THRIFT-1031
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1031
>             Project: Thrift
>          Issue Type: Improvement
>          Components: C++ - Library
>         Environment: Windows XP 32bit, vc++ 9.0, 10.0
>            Reporter: James Dickson
>            Priority: Trivial
>             Fix For: 0.7
>
>         Attachments: thrift_msvc.patch, thrift_msvc_v0_1.patch
>
>
> At our company we need clients running on Windows being able to connect to 
> our linux servers running hypertable. The attached patch enables the parts 
> needed by Hypertable to be compiled on Windows using either the VC++ 9.0 or 
> 10.0 compilers.
> Having read previous posts about ports using boost::asio we found these to be 
> too intrusive for our needs. This version uses pthreads_win32 and winsock2 
> and is as designed to be as un-intrusive as is possible to the original unix 
> code base. It is mostly #defines between unix sockets and winsock2 sockets. 
> We also tried to follow the folder structuring of the C# runtime that has 
> visual studio solutions to be consistent.
> More details are in the README as not all the functionality of the original 
> unix code base is available to windows users. We will add the missing 
> functionality, we just wanted to share what we had as for a Windows based 
> client for us it is sufficient.
> The patch is based on the latest revision in SVN, we would love feedback and 
> any code reviews. If there is any possibility of this being added to the main 
> trunk then that would be much appreciated, however we don't expect that.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to