Building CI that detects ABI breakage is not hard. There is a closed PR in the
arrow repo from me that does exactly this using abi-complicance-checker.
I understand that we will not be able to provide ABI stability on all Arrow
subprojects but having it for a core would be really great. This wou
Le 28/07/2019 à 01:49, Wes McKinney a écrit :
> On Sat, Jul 27, 2019 at 4:38 PM Uwe L. Korn wrote:
>>
>> The PIMPL is a thing I would trade a bit of performance as it brings ABI
>> stability. This is something that will help us making Arrow usage in
>> thirdparty code much simpler.
>>
>
> I q
Hi,
Le 27/07/2019 à 21:04, Wes McKinney a écrit :
> * My understanding is that the PIMPL pattern will perform better for
> non-virtual functions that are called a lot. It'd be helpful to know
> the magnitude of the performance difference
Modern CPUs have indirect branch predictors. If an indir
On Sat, Jul 27, 2019 at 4:38 PM Uwe L. Korn wrote:
>
> The PIMPL is a thing I would trade a bit of performance as it brings ABI
> stability. This is something that will help us making Arrow usage in
> thirdparty code much simpler.
>
I question whether ABI stability (at the level of the shared l
The PIMPL is a thing I would trade a bit of performance as it brings ABI
stability. This is something that will help us making Arrow usage in thirdparty
code much simpler.
Simple updates when an API was only extended but the ABI is intact is a great
ease on the Arrow consumer side. I know that
Wes McKinney writes:
> The abstract/all-virtual base has some benefits:
>
> * No need to implement "forwarding" methods to the private implementation
> * Do not have to declare "friend" classes in the header for some cases
> where other classes need to access the methods of a private
> implementa
