Thread overview | |||||
---|---|---|---|---|---|
|
January 04, 2004 new int vs int.init & value vs reference | ||||
---|---|---|---|---|
| ||||
class Foo(T) { T m_t; this() { m_t = new T; } T t() { return m_t; } T t(T t) { return m_t = t; } } Since this class template has "new T", T must be reference type. Therefore, Foo!(int) cannot be used. I think it is inconvenient. So, I suggest it would be better that "new int" is equivalent to "int.init" in template declarations. And more, when T is a large structure, .t property is not efficient due to copying it. (Large structures may be uncommon in pure D, but they are common when using C's functions or WinAPIs in D.) So, I want references (not pointers) to value-type variables. Foo!(Large) foo; // value type Foo!(ref Large) foo; // reference type "new ref Large" allocates a "Large" object and returns the reference. |
January 04, 2004 Re: new int vs int.init & value vs reference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert | Robert wrote:
> class Foo(T) {
> T m_t;
> this() { m_t = new T; }
> T t() { return m_t; }
> T t(T t) { return m_t = t; }
> }
>
>
> Since this class template has "new T",
> T must be reference type.
> Therefore, Foo!(int) cannot be used.
> I think it is inconvenient.
> So, I suggest it would be better that "new int" is equivalent to "int.init"
> in template declarations.
>
>
> And more, when T is a large structure,
> .t property is not efficient due to copying it.
> (Large structures may be uncommon in pure D,
> but they are common when using C's functions or WinAPIs in D.)
> So, I want references (not pointers) to value-type variables.
>
> Foo!(Large) foo; // value type
> Foo!(ref Large) foo; // reference type
>
> "new ref Large" allocates a "Large" object
> and returns the reference.
What you can do is specialize the template for the Object class, and therefore have two separate template blocks, one for reference types, and the other for value types.
This may cause problems with redundancy, or a proliferation of tiny "helper" templates, though. Maybe a way to specialize and extend a template block is in order. (ie add or change something defined within the general case, and not simply replace the whole of it)
-- andy
|
January 04, 2004 Re: new int vs int.init & value vs reference | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | "Andy Friesen" <andy@ikagames.com> wrote in message news:bt8jc0$c16$1@digitaldaemon.com... > Robert wrote: > > > class Foo(T) { > > T m_t; > > this() { m_t = new T; } > > T t() { return m_t; } > > T t(T t) { return m_t = t; } > > } > > > > > > Since this class template has "new T", > > T must be reference type. > > Therefore, Foo!(int) cannot be used. > > I think it is inconvenient. > > So, I suggest it would be better that "new int" is equivalent to "int.init" > > in template declarations. > > > > > > And more, when T is a large structure, > > .t property is not efficient due to copying it. > > (Large structures may be uncommon in pure D, > > but they are common when using C's functions or WinAPIs in D.) > > So, I want references (not pointers) to value-type variables. > > > > Foo!(Large) foo; // value type > > Foo!(ref Large) foo; // reference type > > > > "new ref Large" allocates a "Large" object > > and returns the reference. > > What you can do is specialize the template for the Object class, and therefore have two separate template blocks, one for reference types, and the other for value types. > > This may cause problems with redundancy, or a proliferation of tiny "helper" templates, though. Maybe a way to specialize and extend a template block is in order. (ie add or change something defined within the general case, and not simply replace the whole of it) > > -- andy I understand you mean C++'s template partial specializations: template<typename T> class C { public: T foo(); }; template<typename T> T C<T>::foo() { return 0; } template<> double C<double>::foo() { return 1; } I want it, too. class C(T) { T foo() !(double) { return 1; } else !(T : Object) { return null; } else { return 0; } } Indeed, it clears up the first problem about "new T". |
Copyright © 1999-2021 by the D Language Foundation