Re: Problems using perl headers with C++

Thanks, this helped, but only for write/read/do_open/do_close/etc

However,
#include <algorithm>
still sucks with -std=c++11

In file included from /usr/include/c++/4.9/random:49:0,
                 from /usr/include/c++/4.9/bits/stl_algo.h:66,
                 from /usr/include/c++/4.9/algorithm:62,
                 from src/panda/string.h:10,
                 from src/xs/lib/lib.h:3,
                 from src/xs/lib.h:2,
                 from Lib.xs:2:
/usr/include/c++/4.9/bits/random.h:271:17: error: macro "seed" passed
1 arguments, but takes just 0
       { seed(__s); }

2015-01-30 6:54 GMT+03:00 bulk88 <bul...@hotmail.com>:
> Jan Dubois wrote:>>>> On Thu, Jan 29, 2015 at 9:44 AM, Олег Пронин <syb...@crazypanda.ru> wrote:>>>>>> 1) On windows, you can't include ostream after perl's headers.>>>>>> c:\strawberry\c\bin\../lib/gcc/x86_64-w64-mingw32/4.7.3/include/c++/ostream:333:49:>>> error: macro "PerlLIO_write" requires 3 arguments, but only 2 given>>>>>> c:\strawberry\c\bin\../lib/gcc/x86_64-w64-mingw32/4.7.3/include/c++/istream:484:42:>>> error: macro "PerlLIO_read" requires 3 arguments, but only 2 given>>>>>> That's because perl defines 'read' and 'write' macro for windows.>>>>>> 2) Unable to use std::vector with -std=c++11, because in bits/random.h>>> there are calls to seed() method. Perl defines macro 'seed'.>>>>>> Are we gonna do something with all of these?>>> IMHO marcos are big evil. If we use it, let's give them some>>> non-conflicting names.>>>>>> You are missing the point of the macros: They are used to create a>> wrapper around standard C library functions to redirect them to the>> Perl implementation instead of calling the RTL version.>>> IDK why those libc hooking were ever created. Nearly all XS code links with> a non-perl compiland, whether its a static link .o/.obj, or a .a/.lib to a> DLL. Once the the perl header including .xs file is linked with non-perl> header including .o/.obj, if any libc resource or ptr or fd is passed across> the compiland boundaries, the DLL is fundamentally broken. Throw away> Inline::C "XS modules" are the only use case for libc hooking. I've never> seen a case where that libc hooking made anything work that didn't work> before. If your rely on a XS module that was last released in 1995, maybe> you should ask for comaint from the PAUSE admins.>>> If you know what you are doing, and you want to bypass the>> redefinitions, then you can always>>>> #undef seed>> #undef read>> #undef write>> #include <...>>>> sometimes read/write/something is #defined to> _read/_write/_something/_readex/_mingw_read/_read2 in the MS CRT or Mingw> CRT headers, #undef won't fix that damage>>>>> or include the additional headers *before* the Perl headers.>>>> See for example this code:>>>>     https://github.com/rjbs/Time-Piece/blob/82beba4/Piece.xs#L135-L142>>>> It has specific reasons for calling the RTL version of some functions,>> so it makes sure not to go through the Perl layer.>>>> Cheers,>> -Jan>>> The correct fix is>> #define NO_XSLOCKS /* dont hook libc calls to virtualize different> faux-processes for psuedofork, this the most common option*/> #define PERLIO_NOT_STDIO 0 /* don't redirect stdio to perlio, this is rarely> needed, but try it too if you get errors after NO_XSLOCKS*/>> before>> #define PERL_NO_GET_CONTEXT> #include "EXTERN.h"> #include "perl.h"> #include "XSUB.h">> Some minor residual problems result such as>> #define WORD 264>> from perly.h



-- 
Oleg Pronin,
CTO, Co-Founder,
Crazy Panda LTD
CP Decision LTD