Re: [fpc-pascal] Android and cwstring
On 2013-07-31 20:57, Sven Barth wrote: On 31.07.2013 20:55, Felipe Monteiro de Carvalho wrote: On Wed, Jul 31, 2013 at 8:51 PM, Sven Barth wrote: The cwstring of Android uses the ICU library libicuuc.so. Is this available in the NDK for one of the higher API levels? It is not in the list for API level 8. I don't know, I have merely quoted the commit message for when cwstring was changed from a stub to a more complete implementation for Android. If it is truly not available in lower API levels then I'd suggest to use fpwidestring anyway... I did some research before i sent the mail and found the libucuuc.so using adb shell into an emulator. I will take a look at the fpwidestring and paswstring. Thanks for the help. REgards, Torsten. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android and cwstring
On Thu, Aug 1, 2013 at 9:59 AM, Torsten Bonde Christiansen wrote: > I did some research before i sent the mail and found the libucuuc.so using > adb shell into an emulator. That's a common mistake. Android is a full Linux inside, so of course there are tons of native libraries available inside. But they are not guaranteed to be there, they are not guaranteed to work as expected in all devices, etc. One should never use libraries outside the list of available NDK libraries. I'm not saying it won't work, it might work, but the official position of Google developers is that they should not be used. -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Hi, > FYI, created wiki page http://wiki.lazarus.freepascal.org/SWIG to bundle > information. >It would of course be very welcome if somebody got the current version into >main SWIG so it is more easily usable The wiki page is a good idea, things have to be clarified though. I don't know in how far others dealt with the code in the meantime - so this is my personal view: When I ported the patch to 2.0.8 things looked quite good, the changes needed were very straightforward - and in the end the result was quite usable. But IMO the code itself is / was a big mess and far from being clean & readable - which is no bigger problem if 'it simply works' :D Now - I tried a port to latest swig (2.0.10) some months ago [even made a fork on github...], but never released, the reason: it doesn't work any more. I didn't search for the relevant changes in their changelog, but I didn't managed to get it even compiled - too many functions simply were missing. Even worse, the Fortran module (upon which the Delphi module is based) although being in trunk also didn't compile - exactly the same missing functions. In short: IMHO the patch is too much bitrotten to be further used, I think a clean and new implementation from scratch would be the much better way. Maybe this can do the trick, too: https://github.com/swig/swig/wiki/GSoC-2013-ideas#wiki-Support_for_C_as_target_language I mean, h2pas does a decent job... And if it's allowed to dream: one time fpc will simply link against C++ directly :) Regards, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Am 01.08.2013 11:10, schrieb dev.d...@gmail.com: And if it's allowed to dream: one time fpc will simply link against C++ directly :) If you prefer to work in Pascal instead of C++ then you could work on that dream by improving the cppclass code in the compiler. Linking against static C++ class methods already works, what's (basically) missing is support for C++ runtimes (at first the stdc++ one would be sufficient), support for vtables and object instantiation/destruction. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: ++ and -- ( and +=, -=, ...)
On 2013-07-30 22:42, leledumbo wrote: > > People who uses C style short unreadable code approach > usually state they get more optimized code, yet the compiler is actually > able to produce the same with optimizations turned on. No, I simply prefer to use += and -= because it is easier to read the code (for me at least). But with the added restrictions applied in recent FPC releases (eg: those shortcuts don't work with properties any more) I am slowly forced to move back to the verbose a := a + b syntax. :-/ Regards, Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ++ and -- ( and +=, -=, ...)
Am 31.07.2013 11:33, schrieb Sven Barth: Technically it would be simple to change that as the corresponding code is already available for the above mentioned situation, but it would definitely change the semantics if the left side is e.g. an array with a function as index accessor (as the function is then only called once)... I believe it would be much better if FPC would do this (that is, evaluate the left side on assignments like a += b only once), because the other program languages like C and PL/1 that provide the same syntax do it the same way. So people who use other languages too will be less surprised. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] ipv6 address convertion
Hi,
I need to manipulate an ipv6 address. I need to add some value to the
netaddress and replace the hostaddress with another value. E.g. add 2 to
the netaddress and replace the hostaddress by ::1
2001:db8:8500:11f8:6631:50ff:fe9a:640b/62 -> 2001:db8:8500:11fa::1/62
Is there a function in fpc that converts a 'short' ipv6 address to its
full length ? I.e. convert :: to the required number of 0's to get a
'full' address ? E.g.
2001:DB8:8500:11f8::1 -> 2001:0DB8:8500:11f8::::0001
And what are the NetAddrToStr6 and HostAddrToStr6 and their counterparts
supposed to do ? Same for the ipv4 functions.
If I try following program (compiled with fpc 2.6.0) with this :
./project1 6 2001:DB8:8500:11f8::1/62
I get strange results :
netadr : ::0033:3DBB:1000::0034:5296:1000
hostadr : ::
netadr : 2001:0DB8:8500:11F8::0001
hostadr : 2001:0DB8:8500:11F8::0001
Note the first netaddress.
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, sockets;
var
inparam : string;
address : string;
begin
if not ((paramstr(1)='6') or (paramstr(1)='4')) then
writeln('only 4 or 6 allowed as first parameter')
else
if paramstr(1)='6' then
begin
inparam:=paramstr(2);
writeln(inparam);
address:=copy(inparam,1,pos('/',inparam)-1);
writeln('netadr : ',NetAddrToStr6(StrToNetAddr6(inparam)));
writeln('hostadr : ',HostAddrToStr6(StrToHostAddr6(inparam)));
writeln('netadr : ',NetAddrToStr6(StrToNetAddr6(address)));
writeln('hostadr : ',HostAddrToStr6(StrToHostAddr6(address)));
end
else
begin
inparam:=paramstr(2);
writeln(inparam);
address:=copy(inparam,1,pos('/',inparam)-1);
writeln('netadr : ',NetAddrToStr(StrToNetAddr(inparam)));
writeln('hostadr : ',HostAddrToStr(StrToHostAddr(inparam)));
writeln('netadr : ',NetAddrToStr(StrToNetAddr(address)));
writeln('hostadr : ',HostAddrToStr(StrToHostAddr(address)));
end;
end.
Thanks,
Koenraad Lelong
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ++ and --
Am 30.07.2013 18:20, schrieb Mark Morgan Lloyd: Now specifically to your question - I believe that one of the reasons may be the fact that Pascal does not support unary arithmetic operators in postfix notation. The fact that C allows using them with both prefix and postfix notation makes them even more difficult from my point of view because potentially allowing them only in one of the notations known from other languages would immediately trigger users to ask why only one of possible notations (common elsewhere) is supported and the other not. I've got a vague recollection that some of the ++ and -- semantics are particularly unpleasant, and that one of the C inventors did his best to disown them. At least += etc. are fairly unambiguous: they're almost macro expansions and as such they don't mandate any extra overloadable operators etc. FWIW: the += etc. assignment operators make sense IMO, because for complex expressions involving array indices etc. that are to be incremented or decremented, it is no more necessary to write them twice. Compared to that, the difference between ++ and += 1 (with ++ you have to put parantheses around the expression to be incremented !!) seems unimportant. And, if that's a matter for you: the newer PL/1 compilers support += etc., but don't support ++ and --, Kind regards Bernd ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
On Thu, 1 Aug 2013, dev.d...@gmail.com wrote: Hi, FYI, created wiki page http://wiki.lazarus.freepascal.org/SWIG to bundle information. It would of course be very welcome if somebody got the current version into main SWIG so it is more easily usable The wiki page is a good idea, things have to be clarified though. I don't know in how far others dealt with the code in the meantime - so this is my personal view: When I ported the patch to 2.0.8 things looked quite good, the changes needed were very straightforward - and in the end the result was quite usable. But IMO the code itself is / was a big mess and far from being clean & readable - which is no bigger problem if 'it simply works' :D Now - I tried a port to latest swig (2.0.10) some months ago [even made a fork on github...], but never released, the reason: it doesn't work any more. I didn't search for the relevant changes in their changelog, but I didn't managed to get it even compiled - too many functions simply were missing. Even worse, the Fortran module (upon which the Delphi module is based) although being in trunk also didn't compile - exactly the same missing functions. In short: IMHO the patch is too much bitrotten to be further used, I think a clean and new implementation from scratch would be the much better way. Maybe this can do the trick, too: https://github.com/swig/swig/wiki/GSoC-2013-ideas#wiki-Support_for_C_as_target_language I mean, h2pas does a decent job... And if it's allowed to dream: one time fpc will simply link against C++ directly :) Not even C++ compilers can use each other's DLLs, if I understood correctly. I just received a (clean) patch from Sven Barth, which expands on your patch. It's on 2.0.8, and indeed does not work with swig trunk. I was planning to try and get this into swig, but after your remarks, I am no longer so sure that this is a good idea :) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:10, schrieb dev.d...@gmail.com: And if it's allowed to dream: one time fpc will simply link against C++ directly :) If you prefer to work in Pascal instead of C++ then you could work on that dream by improving the cppclass code in the compiler. Linking against static C++ class methods already works, what's (basically) missing is support for C++ runtimes (at first the stdc++ one would be sufficient), support for vtables and object instantiation/destruction. How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Am 01.08.2013 11:38, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:10, schrieb dev.d...@gmail.com: And if it's allowed to dream: one time fpc will simply link against C++ directly :) If you prefer to work in Pascal instead of C++ then you could work on that dream by improving the cppclass code in the compiler. Linking against static C++ class methods already works, what's (basically) missing is support for C++ runtimes (at first the stdc++ one would be sufficient), support for vtables and object instantiation/destruction. How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ? Support for every C++ compiler (mainly MSVC, C++ builder and GCC [LLVM counts here as GCC]) needs to be implemented explicitely, because they not only differ in class layout, but also in e.g. name mangling. So in the end (if we want to support more than GCC and LLVM) we'll need to use a directive to declare which compiler to target and this then includes a corresponding interface unit for the runtime (like is done with Objective C) and let the compiler generate the code correctly. Maybe together with packages support it should be possible to interface with multiple different compilers at once. As a first step I'd only target GCC and LLVM as these are the main compilers for the majority of our platforms. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:38, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:10, schrieb dev.d...@gmail.com: And if it's allowed to dream: one time fpc will simply link against C++ directly :) If you prefer to work in Pascal instead of C++ then you could work on that dream by improving the cppclass code in the compiler. Linking against static C++ class methods already works, what's (basically) missing is support for C++ runtimes (at first the stdc++ one would be sufficient), support for vtables and object instantiation/destruction. How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ? Support for every C++ compiler (mainly MSVC, C++ builder and GCC [LLVM counts here as GCC]) needs to be implemented explicitely, because they not only differ in class layout, but also in e.g. name mangling. So in the end (if we want to support more than GCC and LLVM) we'll need to use a directive to declare which compiler to target and this then includes a corresponding interface unit for the runtime (like is done with Objective C) and let the compiler generate the code correctly. Maybe together with packages support it should be possible to interface with multiple different compilers at once. Since a library is provided by a vendor, I'd say you normally interface with one compiler per lib that you target, no ? As a first step I'd only target GCC and LLVM as these are the main compilers for the majority of our platforms. Eh, MSVC also seems popular on windows ? ;) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: ++ and -- ( and +=, -=, ...)
Semantically, it's not the same, but a += b can be replaced by inc ( a, b ) ; It's readable, it looks like normal standard Pascal; and it's clear that the address of a is calculated only once. If a,b are not ordinals, inc could be overloaded. Greetings Gerhard - Original Message - From: "Graeme Geldenhuys" To: Sent: Wednesday, July 31, 2013 12:54 PM Subject: Re: [fpc-pascal] Re: ++ and -- ( and +=, -=, ...) On 2013-07-30 22:42, leledumbo wrote: People who uses C style short unreadable code approach usually state they get more optimized code, yet the compiler is actually able to produce the same with optimizations turned on. No, I simply prefer to use += and -= because it is easier to read the code (for me at least). But with the added restrictions applied in recent FPC releases (eg: those shortcuts don't work with properties any more) I am slowly forced to move back to the verbose a := a + b syntax. :-/ Regards, Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Am 01.08.2013 12:11, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:38, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:10, schrieb dev.d...@gmail.com: And if it's allowed to dream: one time fpc will simply link against C++ directly :) If you prefer to work in Pascal instead of C++ then you could work on that dream by improving the cppclass code in the compiler. Linking against static C++ class methods already works, what's (basically) missing is support for C++ runtimes (at first the stdc++ one would be sufficient), support for vtables and object instantiation/destruction. How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ? Support for every C++ compiler (mainly MSVC, C++ builder and GCC [LLVM counts here as GCC]) needs to be implemented explicitely, because they not only differ in class layout, but also in e.g. name mangling. So in the end (if we want to support more than GCC and LLVM) we'll need to use a directive to declare which compiler to target and this then includes a corresponding interface unit for the runtime (like is done with Objective C) and let the compiler generate the code correctly. Maybe together with packages support it should be possible to interface with multiple different compilers at once. Since a library is provided by a vendor, I'd say you normally interface with one compiler per lib that you target, no ? That's basically what I said :) As a first step I'd only target GCC and LLVM as these are the main compilers for the majority of our platforms. Eh, MSVC also seems popular on windows ? ;) We have three windows platforms with MSVC and I don't know how many platforms where GCC or LLVM is the main compiler. I'm not going for popularity here, just for the majority of platforms. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Automatically exporting C++ API using SWIG??
On 01/08/2013 12:24, Sven Barth wrote: > Am 01.08.2013 12:11, schrieb Michael Van Canneyt: >> On Thu, 1 Aug 2013, Sven Barth wrote: >>> Am 01.08.2013 11:38, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: > Am 01.08.2013 11:10, schrieb How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ? >>> Support for every C++ compiler (mainly MSVC, C++ builder and GCC >>> [LLVM counts here as GCC]) needs to be implemented explicitely, >> Since a library is provided by a vendor, I'd say you normally >> interface with one compiler per lib that you target, no ? > That's basically what I said :) >> >>> >>> As a first step I'd only target GCC and LLVM as these are the main >>> compilers for the majority of our platforms. >> >> Eh, MSVC also seems popular on windows ? ;) > We have three windows platforms with MSVC and I don't know how many > platforms where GCC or LLVM is the main compiler. I'm not going for > popularity here, just for the majority of platforms. Looking at the options 1 use swig architecture to parse the C++ source code/headers and extract Pascal bindings - either by a rewrite or adapting the current effort 2 accommodate (and maintain) various compiler idiosyncracies from a distance... I'd say option 1 would be the easiest and best maintainable? - SWIG already provides infrastructure to parse the source files - People using Delphi would probably also be interested in fixing/patching bugs - On top of the previous point: changes in C/C++ standards/formats would not be our concern so much because those will be dealt with by the wider SWIG community - Of course, if swig is ever extended to support more languages, we get that for free Of course I understand it's very attractive to have everything in house and native in FPC, but I suspect the effort needed to develop/maintain it may outweigh that... @dliw: wasn't the Object Pascal module based on the Modula 3 module? IIRC recent posts on the swig mailing lists did indeed indicate the Modula 3 module was buggy in current SWIG. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Am 01.08.2013 12:47, schrieb Reinier Olislagers: On 01/08/2013 12:24, Sven Barth wrote: Am 01.08.2013 12:11, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:38, schrieb Michael Van Canneyt: On Thu, 1 Aug 2013, Sven Barth wrote: Am 01.08.2013 11:10, schrieb How do you handle different binary formats of C++ compilers ? Or is this meanwhile standardized ? Support for every C++ compiler (mainly MSVC, C++ builder and GCC [LLVM counts here as GCC]) needs to be implemented explicitely, Since a library is provided by a vendor, I'd say you normally interface with one compiler per lib that you target, no ? That's basically what I said :) As a first step I'd only target GCC and LLVM as these are the main compilers for the majority of our platforms. Eh, MSVC also seems popular on windows ? ;) We have three windows platforms with MSVC and I don't know how many platforms where GCC or LLVM is the main compiler. I'm not going for popularity here, just for the majority of platforms. Looking at the options 1 use swig architecture to parse the C++ source code/headers and extract Pascal bindings - either by a rewrite or adapting the current effort 2 accommodate (and maintain) various compiler idiosyncracies from a distance... I'd say option 1 would be the easiest and best maintainable? - SWIG already provides infrastructure to parse the source files - People using Delphi would probably also be interested in fixing/patching bugs - On top of the previous point: changes in C/C++ standards/formats would not be our concern so much because those will be dealt with by the wider SWIG community - Of course, if swig is ever extended to support more languages, we get that for free Of course I understand it's very attractive to have everything in house and native in FPC, but I suspect the effort needed to develop/maintain it may outweigh that... Important point for variant 2: less overhead. Using swig you first flatten the API and then unflatten it again into Object Pascal classes. For callbacks you have also wrappers (which are hidden from you). In case of cppclass you don't have all this, because code will be called directly. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
> @dliw: wasn't the Object Pascal module based on the Modula 3 module? > IIRC recent posts on the swig mailing lists did indeed indicate the > Modula 3 module was buggy in current SWIG. Sorry, you're right - it was based on Modula - I did mix it up. Thanks for this correction. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
> Important point for variant 2: less overhead. Right, that's the biggest plus in my eyes. >Or is this meanwhile standardized ? Unfortunately not. It starts in different name mangling - as already said here - and other (small) differences. So working on a cross-platform project in C++ with different compilers involved - is still quite an adventure :D >then you could work on that by improving the cppclass code in the compiler Hm, I will at least take a look. d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
On Thu, 1 Aug 2013, Sven Barth wrote: Of course I understand it's very attractive to have everything in house and native in FPC, but I suspect the effort needed to develop/maintain it may outweigh that... Important point for variant 2: less overhead. Using swig you first flatten the API and then unflatten it again into Object Pascal classes. For callbacks you have also wrappers (which are hidden from you). In case of cppclass you don't have all this, because code will be called directly. And: it's written in Pascal. The problem with tools such as swig is, that, unless it works 'out of the box' for the particular DLL you're interested in, basically, you are stuck. Like as in: Leap.i:259: Error: Syntax error in input(1). The line in question being: SWIG_CSBODY_PROXY(public, public, SWIGTYPE) To make matters worse, the actual error depends on the target output language. Aha Hm With swig, I must now learn C, C++, the swig .i and .swg file formats. And then I must still get started on the swig java/csharp/delphi/whatever backend. And that is if I am lucky that the providers of the DLL provided me with a input file for swig. If not, I still must construct that... Now if it is written in Pascal, I pull up my sleeves, open whatever it is in Lazarus and start debugging/coding. Not so in tools like swig. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Automatically exporting C++ API using SWIG??
On 01/08/2013 13:11, Sven Barth wrote: > Am 01.08.2013 12:47, schrieb Reinier Olislagers: >> On 01/08/2013 12:24, Sven Barth wrote: > Important point for variant 2: less overhead. Using swig you first > flatten the API and then unflatten it again into Object Pascal classes. > For callbacks you have also wrappers (which are hidden from you). In > case of cppclass you don't have all this, because code will be called > directly. > Thanks for the info, Sven. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Automatically exporting C++ API using SWIG??
Sven Barth wrote: We have three windows platforms with MSVC and I don't know how many platforms where GCC or LLVM is the main compiler. I'm not going for popularity here, just for the majority of platforms. Looking at the options 1 use swig architecture to parse the C++ source code/headers and extract Pascal bindings - either by a rewrite or adapting the current effort 2 accommodate (and maintain) various compiler idiosyncracies from a distance... I'd say option 1 would be the easiest and best maintainable? - SWIG already provides infrastructure to parse the source files - People using Delphi would probably also be interested in fixing/patching bugs - On top of the previous point: changes in C/C++ standards/formats would not be our concern so much because those will be dealt with by the wider SWIG community - Of course, if swig is ever extended to support more languages, we get that for free Of course I understand it's very attractive to have everything in house and native in FPC, but I suspect the effort needed to develop/maintain it may outweigh that... Important point for variant 2: less overhead. Using swig you first flatten the API and then unflatten it again into Object Pascal classes. For callbacks you have also wrappers (which are hidden from you). In case of cppclass you don't have all this, because code will be called directly. However, I'm reminded of the flurry of activity when SCADA malware was found in the wild a couple of years ago: it was decided fairly early that it had probably been compiled with MS tools, but inspection of the calling convention suggested that it was non-standard and it took a lot of head scratching before people decided which compiler/linker and what pragmata had been used. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: ++ and -- ( and +=, -=, ...)
Hi felow pascaloids, I know I'm out the discussion, but I don't understand why Pascal should include stuff from other languages that doesn't fit the "spirit" of Pascal, as readability (and no, "++" isn't more readable). I mean, if you like a structure, syntax or behavior from C, then use C. I do it sometimes; for example when I should do something low-level I feel myself more comfortable using C than Pascal. Of course, the language should evolve, and it did with Objects and Classes, and later with Generics and For-In loops (I don't like this latest addition but only because I had a lot of bad experiences when I programmed in C++) but I think FPC cannot admit anything just because another language has it. These are my two cents. Regards Guillermo "Ñuño" Martínez. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: ++ and -- ( and +=, -=, ...)
Somehow relevant, has someone thought of turning Inc()/Dec() into functions that return the modified value -like the Interlocked ones? I think this would cover some of the cases discussed in a more "pascalish" notation.Also, Include()/Exclude() could similarly be turned into functions. -- Constantine Yannakopoulos ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android and cwstring
On 2013-07-31 20:57, Sven Barth wrote: On 31.07.2013 20:55, Felipe Monteiro de Carvalho wrote: On Wed, Jul 31, 2013 at 8:51 PM, Sven Barth wrote: The cwstring of Android uses the ICU library libicuuc.so. Is this available in the NDK for one of the higher API levels? It is not in the list for API level 8. I don't know, I have merely quoted the commit message for when cwstring was changed from a stub to a more complete implementation for Android. If it is truly not available in lower API levels then I'd suggest to use fpwidestring anyway... hmmm i can't get fpwidestring to work, it seem that it is not compiled during a normal compiler build. The same goes for all of the collation units. Should i add and special defines to get them compiled or is it a bug in the makefile? Regards, Torsten. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android and cwstring
On 01.08.2013 20:43, Torsten Bonde Christiansen wrote: On 2013-07-31 20:57, Sven Barth wrote: On 31.07.2013 20:55, Felipe Monteiro de Carvalho wrote: On Wed, Jul 31, 2013 at 8:51 PM, Sven Barth wrote: The cwstring of Android uses the ICU library libicuuc.so. Is this available in the NDK for one of the higher API levels? It is not in the list for API level 8. I don't know, I have merely quoted the commit message for when cwstring was changed from a stub to a more complete implementation for Android. If it is truly not available in lower API levels then I'd suggest to use fpwidestring anyway... hmmm i can't get fpwidestring to work, it seem that it is not compiled during a normal compiler build. The same goes for all of the collation units. Should i add and special defines to get them compiled or is it a bug in the makefile? How exactly did you compile? As described in the wiki with "make crossall OS_TARGET=android CPU_TARGET=arm ..." in the top level directory? In that case it should be compiled and a fpwidestring.ppu should be located in the $fpcsrc/rtl/units/arm-android directory. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android and cwstring
On 2013-08-01 21:58, Sven Barth wrote: On 01.08.2013 20:43, Torsten Bonde Christiansen wrote: On 2013-07-31 20:57, Sven Barth wrote: On 31.07.2013 20:55, Felipe Monteiro de Carvalho wrote: On Wed, Jul 31, 2013 at 8:51 PM, Sven Barth wrote: The cwstring of Android uses the ICU library libicuuc.so. Is this available in the NDK for one of the higher API levels? It is not in the list for API level 8. I don't know, I have merely quoted the commit message for when cwstring was changed from a stub to a more complete implementation for Android. If it is truly not available in lower API levels then I'd suggest to use fpwidestring anyway... hmmm i can't get fpwidestring to work, it seem that it is not compiled during a normal compiler build. The same goes for all of the collation units. Should i add and special defines to get them compiled or is it a bug in the makefile? How exactly did you compile? As described in the wiki with "make crossall OS_TARGET=android CPU_TARGET=arm ..." in the top level directory? In that case it should be compiled and a fpwidestring.ppu should be located in the $fpcsrc/rtl/units/arm-android directory. ̈́ I did that, but I also included a "crossinstall" which installed the units to somewhere else in my home dir. However now that i compare the $fpcsrc/rtl/units/arm-android with $install_dir/rtl/units/arm-android some of the files are missing - this includes the fpwidestring and collation files... strange? Regards, Torsten. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Android and cwstring
On 01 Aug 2013, at 22:22, Torsten Bonde Christiansen wrote: > On 2013-08-01 21:58, Sven Barth wrote: >> How exactly did you compile? >> >> As described in the wiki with "make crossall OS_TARGET=android >> CPU_TARGET=arm ..." in the top level directory? In that case it should be >> compiled and a fpwidestring.ppu should be located in the >> $fpcsrc/rtl/units/arm-android directory. >> ̈́ > I did that, but I also included a "crossinstall" which installed the units to > somewhere else in my home dir. > > However now that i compare the $fpcsrc/rtl/units/arm-android with > $install_dir/rtl/units/arm-android some of the files are missing - this > includes the fpwidestring and collation files... strange? They're probably missing as implicit units in the makefile. However, even if you get them to install, they will probably crash unless the patch at http://bugs.freepascal.org/view.php?id=24158 is applied. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
