Displaying 3 results from an estimated 3 matches for "rawpointer".
Did you mean:
rampointer
2014 Jan 04
2
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
...I hadn’t considered AssertVH, and I agree that losing it isn’t an option.
>
> Would it be possible to redesign AssertVH to be non-ABI fragile across debug/release builds? I haven’t looked at it recently, but maybe it could be a pointer to a CallbackVH in the debug mode, or a PointerUnion<rawpointer, callbackvh> or something.
>
> If you want methods to still be inlined in the non-assert case, you still have an ABI break in how you interpret the pointer...
>
I’m suggesting that AssertVH be redesigned: it could be a PointerUnion (in all build modes) and .o files which are built i...
2014 Jan 03
2
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
...nsumers.
I hadn’t considered AssertVH, and I agree that losing it isn’t an option.
Would it be possible to redesign AssertVH to be non-ABI fragile across debug/release builds? I haven’t looked at it recently, but maybe it could be a pointer to a CallbackVH in the debug mode, or a PointerUnion<rawpointer, callbackvh> or something.
> We also have quite a few places in LLVM today that conserve memory usage in non-assert builds by removing unnecessary members of classes. We can say that this makes the ABI more fragile, but it is a valuable space optimization. Chris, are you saying to strongly b...
2013 Nov 12
3
[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote:
>> Even when you have a !NDEBUG build, the platform assert() is pretty
>> crummy on Windows and generates, at best a UTF-16 dump, or sometimes
>> just pops up a dialog. WebKit and other projects take the same approach
>> and define their own assertion macros to deal with this portably.
>>