[cfe-dev] automatic constructors a la GLSL?

[Michael Price]

On Thu, Sep 9, 2010 at 1:12 PM, Michael Price <michael.b.price.dev at gmail.com
> wrote:

>
>
> On Thu, Sep 9, 2010 at 12:47 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Sep 9, 2010, at 4:23 AM, Dominic Laflamme wrote:
>>
>> I am porting a bunch of GLSL code over to LLVM and am wondering how I can
>> setup constructors for a certain type.
>>
>> example:
>>
>> <snip>
>>
>> typedef float float4 __attribute__((ext_vector_type(4)));
>>
>> float4 float4(float r, float g, float b, float a )
>> {
>>
>> float4 ret = {r,g,b,a};
>> return ret;
>>
>> }
>>
>> float4 float4(float r, float g, float b )
>> {
>>
>> float4 ret = {r,g,b,1.0};
>> return ret;
>>
>> }
>>
>> </snip>
>>
>> Of course this wont work since the function are using the same name, but
>> any idea how I can setup these types of constructors? Should I declare
>> float4 as a struct and overload the constructors? Can the ext_vector_type
>> extension provide some help?
>>
>>
>> In C++, you could certainly just make float4 a class that wraps a vector
>> and has an implicit conversion to vector type.  Alternatively, if you're
>> willing to use different function names, you can just make these overloaded
>> functions.  Otherwise I don't think there's a reasonable solution short of
>> inventing a crazy new language feature.
>>
>
> In C++0x, it would be better to use the staticly-sized std::array<intval>
> type rather than a dynamically sized vector.  Or maybe even a std::tuple.
>
>
>>
>> It's not unreasonable for us to support direct-initialization of vector
>> types a la 'float4(a,b,c,d)' as a generic form of vector initialization in
>> C++, but obviously that wouldn't extend to the three-argument version.
>>
>>
> Also in C++0x, you could use std::initializer_list construction to achieve
> this.  Calling syntax would be:
>
> float4 f1 = {2.0, 2.0, 2.0, 2.0);
> float4 f2 = {2.0, 2.0, 2.0};  // std::initializer_list ctor would recognize
> only three elements and do the 'right' thing for the alpha.
>
>
Sorry, that closing parenthesis should be a closing curly brace...


>
>
John.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
> Too bad we don't have that support yet.. :(
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100909/8cc47e30/attachment.html>