[cfe-dev] objc++ enhancements for new c++ features

[Duncan P. N. Exon Smith via cfe-dev]

> On Mar 20, 2018, at 14:08, James Gregurich via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 
> 
>> On Mar 20, 2018, at 3:46 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>> 
>> On 20 Mar 2018, at 20:06, James Gregurich <bayoubengalml at mac.com <mailto:bayoubengalml at mac.com>> wrote:
>>> 
>>> 
>>> 
>>>> On Mar 20, 2018, at 1:09 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk <mailto:David.Chisnall at cl.cam.ac.uk>> wrote:
>>>>> 
>>>>> 1) making blocks movable so that they can capture things like unique_ptr<> and still be moved off the stack 
>>>> 
>>>> This should be relatively simple.  Although the interface is a copy, it is effectively a move operation (it either increments a reference count or modifies the source to use forwarding pointers).  I don’t see why blocks in C++11 or later shouldn’t always use move constructors for __block-qualified variables where available.
>>> 
>>> What would need to happen to push the concept forward?
>> 
>> Someone to actually do the work.
> 
> I could do it with some hand holding. I have no experience with compiler development or the clang codebase, but pointed in the right direction, I could figure it out.

Thanks for getting involved – if you add me to any reviews, I can help you find appropriate reviewers at Apple.

>> Objective-C methods don’t support overloading (with Apple runtimes, at least), so you’d need to generate only one.
> 
> which is the answer I expected. One could still manually implement the other if needed.
> 
>> 
>> Why do you use std:: pointers for this?  Before ARC existed, I created a C++ smart pointer class that just called retain / release. When ARC was introduced, I extended it to use the same functions that ARC uses, so you can use ARC-like smart pointers in a non-ARC codebase.  Is there a reason why you need these to be std::shared / weak pointers, which imply some different semantics?
> 
> why roll my own when I can use the standard ones? they work perfectly fine with custom deallocators to call [release] in the non-arc case.
> 
> you can't do threading-friendly weak pointers without ARC using only retain/release. Why write some new mechanism when the standard one works fine and makes for wonderfully maintainable code? The only issue remaining is making weak_ptr<> a little smarter to handle ARC correctly.

I agree it would be great to get ARC-managed pointers working well in std::shared_ptr and std::weak_ptr.  The usual subtlety with templates is that __strong doesn't show up in C++ mangling, so it's not straightforward to avoid ODR violations when ARC and MRR translation units are linked together.  I think this is solvable, but I doubt it's trivial.

>>> https://gist.github.com/bayoubengal/e4877efd84b32fb48b4fb00fb1e4a5c9 <https://gist.github.com/bayoubengal/e4877efd84b32fb48b4fb00fb1e4a5c9>
>> 
>> There isn’t enough information in that gist for me to understand what the desired behaviour is.
> 
> 
> the idea is to change the compiler to handle the following syntax:
> 
> 
> auto tmpCalcuStringLmbda = @lambda( -[cMyClass calculateStringValue:withNumber:]  );
> 
> 
> the compiler would automatically generate the following code:
> 
> 
>    auto tmpCalcuStringLmbda = [](cMyClass* theObjPtr, NSString* theValue1Ptr, size_t theValue)
>    {
>       return [theObjPtr calculateStringValue: theValue1Ptr withNumber: theValue];
>    };
> 
> 
> in essence, the compiler would create a lambda whose signature matches the signature of the selector declaration.  calling the lambda calls the selector passing in the arguments.
> 
> once you have a lambda declared, that could be passed to template machinery in the usual way.

I'm skeptical of inventing an ObjC++-specific terse lambda syntax.  I'm tempted to let C++ evolve/improve lambda syntax first.

>> A SEL typed parameter.
>> 
> 
> that isn't a convenient mechanism as the template machinery has no way to deduce the signature of the method. you end up have to manually cast the IMP. having the compiler handle the type checking on the invocation would be much preferable.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180321/d49948fe/attachment.html>