[cfe-dev] automatic constructors a la GLSL?

[Michael Price]

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.



> 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/e37fa425/attachment.html>