"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:ak108p$18il$1@digitaldaemon.com...
> It reminds me: Smart pointers would need the ability to redefine the
member
> operator. Is it feasible in D?

In a garbage collected language, is there a need for smart pointers?

"Walter" <walter@digitalmars.com> wrote in message news:ak0efd$1lp2$2@digitaldaemon.com...

> D does not have a distinction between class and function templates. An entire group of declarations of any kind can be within a template body, including classes, functions, variables, enums, nested templates, etc.

   It's like a "template namespace", which is something I've always wanted
in C++.

Salutaciones,
                       JCAB

Hi,

"Walter" <walter@digitalmars.com> wrote in message news:ak147n$273f$1@digitaldaemon.com...
> In a garbage collected language, is there a need for smart pointers?

I'm not sure, considering try/catch/finally. But there are lots of C APIs
out there returning POD structures with special free functions.
fopen()/fclose() and opendir()/closedir() are simple examples of this, MAPI
with MAPIFreeBuffer() is another. Even if D itself is garbage collected,
many applications written in D will use such APIs, and GC will not solve all
their problems. If I was to use the GC to clean up, I would need something
like:

    interface Free { void special_free(void *); }

    template TSmartPointer(T, F : Free)
    {
       class SmartPointer {
           this(T* t) { m_t = t; }
           ~this() { F.special_free(m_t); }
          T* m_t;
       }
    }

    class CloseFile: Free
    {
        void special_free(void* fp) { fclose((FILE*)fp); } // I don't check
the result, I know - slap me.
     }

    instance TSmartPointer fileClosing(FILE, CloseFile);

    FILE* fp = fopen("name", "r");
    fileClosing.SmartPointer closeÍt = new fileClosing.SmartPointer(fp);
    ... now access it using fp

Clearly, that is too tedious. try/finally would probably be a better solution...

Regards,
Martin M. Pedersen

"Juan Carlos Arevalo Baeza" <jcab@JCABs-Rumblings.com> wrote in message news:ak16eg$2q07$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ak0efd$1lp2$2@digitaldaemon.com...
> > D does not have a distinction between class and function templates. An entire group of declarations of any kind can be within a template body, including classes, functions, variables, enums, nested templates, etc.
>    It's like a "template namespace", which is something I've always wanted
> in C++.

Exactly!

"Walter" <walter@digitalmars.com> wrote in message news:ak11s6$1lac$1@digitaldaemon.com...

> You're right, there is a subtle difference there. I think if the rule were if T is in the specialization, then the value of T is extracted. If T is
not
> in the specialization, T is whatever the whole specialization type is (or
> derived from it).

   Or you can use a different operator to make it even simpler to parse. =>
and := come to mind...

   Still, using runtime interfaces for this sounds a little wrong to me.

   One thing that I don't like is not having numeric/value template
parameters.

   And, now that we're at it, "TemplateInstantiations are always performed
in the scope of where the TemplateDeclaration is declared, with the addition
of the template parameters being declared as aliases for their deduced
types", so what's the semantics of this:

---
void func(int) { ... }

template Tpl(T) {
  void anotherfunc(T t) {
    func(t);
  }
}

void func(bool) { ... }

instance Tpl(bool) tplBool; // How?

tplBool.anotherfunc(false); // How?
---

   I guess that with the non-need for function prototypes, this particular
example is solvable in D. But I'm thinking especially of templates defined
in one module and used in another.

Salutaciones,
                       JCAB

"Walter" <walter@digitalmars.com> wrote in message news:ak147n$273f$1@digitaldaemon.com...

> In a garbage collected language, is there a need for smart pointers?

   Butofcourse. Smart pointers and memory management don't necessarily have
to be related at all. The fact that most smart pointers are only used to
manage memory doesn't mean that has to be the case. For example, I have a
buncha smart pointers that manage file access. They are "smart" because they
will manage the ownership of the file, and "pointers" because they emulate a
pointer to an interface with members that perform operations on the file.

   The way you have D set up, you just can't do this, anyway, which I still
think is a real pity and the thing that kills D (alongside with Java) for
me. Ahem... Not that I'm not duly impressed...

Salutaciones,
                       JCAB

"Juan Carlos Arevalo Baeza" <jcab@JCABs-Rumblings.com> wrote in message news:ak1fat$2c87$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ak11s6$1lac$1@digitaldaemon.com...
> > You're right, there is a subtle difference there. I think if the rule
were
> > if T is in the specialization, then the value of T is extracted. If T is
> not
> > in the specialization, T is whatever the whole specialization type is
(or
> > derived from it).
>    Or you can use a different operator to make it even simpler to parse.
=>
> and := come to mind...
>    Still, using runtime interfaces for this sounds a little wrong to me.

It's still compile time, just a bit extra work for the semantic pass. Not too tough, C++ templates are far worse <g>. I just have to adapt the argument type deduction code from that, meanwhile whacking off about 90% of it.

>    One thing that I don't like is not having numeric/value template
> parameters.

Just use them as class members, and pass the class type.

>    And, now that we're at it, "TemplateInstantiations are always performed
> in the scope of where the TemplateDeclaration is declared, with the
addition
> of the template parameters being declared as aliases for their deduced types", so what's the semantics of this:
>
> ---
> void func(int) { ... }
>
> template Tpl(T) {
>   void anotherfunc(T t) {
>     func(t);
>   }
> }
>
> void func(bool) { ... }
>
> instance Tpl(bool) tplBool; // How?
>
> tplBool.anotherfunc(false); // How?

It doesn't matter if some functions are before and some after the use of it,
the compiler sees all of them when doing the semantic analysis. This just
doesn't have the problems/bugs inherent in the C++ model of not knowing
about anything ahead of it in the source file. Hence, the call func(t) will
resolve to func(bool), regardless of the lexical positioning of func(int)
and func(bool).



>    I guess that with the non-need for function prototypes, this particular
> example is solvable in D. But I'm thinking especially of templates defined
> in one module and used in another.

If func() is defined in a different module than template Tpl() and is not
visible in the scope of template Tpl(), then you'll get a "func undefined"
message when the instance Tpl(bool) is compiled regardless of whether func()
is visible at the scope of instance Tpl(bool) or not.

This is fundamentally different than the way C++ works - C++ tries to do it both ways, with some names getting resolved at template declaration scope, and some at template instantiation scope, depending on whether a name is "type-dependent" or not.

"Juan Carlos Arevalo Baeza" <jcab@JCABs-Rumblings.com> wrote in message news:ak1ht1$753$1@digitaldaemon.com...
>    The way you have D set up, you just can't do this, anyway, which I
still
> think is a real pity and the thing that kills D (alongside with Java) for me. Ahem... Not that I'm not duly impressed...

Even if you don't use D, I've found your comments about it to be very valuable. Are you sure that all the other neat stuff in D doesn't tempt you? <g>

Wow, one day since this was posted and all these emails.

I was wondering about this syntax sugar.

    //Where foo is an template
    import foo(int);

Then you could use all the methods like C functions.

    x = Max(a,b);

Ofcourse problems would occur when there are more then one...

    import foo(int);
    import foo(float);

But the complier could work that out.

"Walter" <walter@digitalmars.com> wrote in message news:ajvgsb$6gt$1@digitaldaemon.com...
> www.digitalmars.com/template.html
>
> Notice how short it is <g>. Ok, what did I miss?
>
>

"Walter" <walter@digitalmars.com> wrote in news:ak0uas$rqn$1@digitaldaemon.com:

> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns9271999977E06patcodemooncom@63.105.9.61...
>> Does the statement "Semantic analysis is not done until instantiated." mean that the tempate will pick up variables and functions in the scope in which it is instantiated?
> 
> Nope. The only thing it will pick up from the instantiation scope is the template argument types.
> 

Have you see C++ template usage like this?

template<class T>
class Foo
{
  public:
  int addToClassFunc(int param)
  {
    T* pT = static_cast<T*>(this);

    return pT->classFunc() + param;
  }
}

class Bar : public A, public Foo<Bar>
{
  int classFunc()
  {
    return 12;
  }
};

Bar b;
b.addToClassFunc(5); // return 15


Of course D doesn't have multiple inheritance.
But do you really need it to be able to do
functionality aggregation like the C++ example
above?