"Andrew Koenig" <ark@research.att.com> skrev i melding
news:yu99ofiticbz.fsf@europa.research.att.com...
> I would like to see a realistic example of a program in which the
> proposed feature would be useful.
>
I found this problem when I tried to make a class that
enables me to use iterators, smart pointers, plain pointers and other
pointer imitators
as paramters to a function. The class looks basically something like this:

template <typename X>
class Ptr_t
{
    private:
        X *value;
    public:
        template <typename Y>
        Ptr_t(Y *in)
        {
            value=in;
        }

        template <typename Y>
        Ptr_t(const Y &in)
        {
            value=&*in;
        }

        X &operator*() const
        {
            return *value;
        }

        X *operator->() const
        {
            return value;
        }

        operator bool() const
        {
            return value;
        }

// etc...
};

The use of this class are as follows:

void print(Ptr_t<string> s)
{
    if (s)
        cout<<*s<<endl;
    else
        cout<<NULL<<endl;
}

int main()
{
    auto_ptr<string>  aptr(new string("auto_ptr"));
    print(aptr);

    print(new string("plain"));

    vector<string> vec;
    vec.push_back("iterator");
    print(vect.begin());

    string *p=NULL;
    print(p);

    print(NULL);  // Error here

    return 0;
}

(#include and using omitted)
This gives an error because NULL is an integer and matches Ptr_t(const Y
&in).
If we had a std::null I would add the following to Ptr_t:

Ptr_t(null_t)
{
    value=null;
}

and used print(null) instead of print(NULL).
This example is not realistic but the class Ptr_t is, and the problem is.

Atle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Atle> If we had a std::null I would add the following to Ptr_t:

Atle> Ptr_t(null_t)
Atle> {
Atle>     value=null;
Atle> }

Atle> and used print(null) instead of print(NULL).  This example is
Atle> not realistic but the class Ptr_t is, and the problem is.

Is the idea that you want std::null to have a magic type named
null_t that is used for no other purpose?

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Andrew Koenig <ark@research.att.com> wrote in message news:<yu99ofiticbz.fsf@europa.research.att.com>...
> I would like to see a realistic example of a program in which the
> proposed feature would be useful.

template<class Itf> class smart_com_pointer
{
public:

    smart_com_pointer & operator= (Itf *);
    smart_com_pointer & operator= (IUnknown *);
};

smart_com_pointer<IMyComInterface> p;

p = 0; // ambiguous, must add operator=(int) to resolve.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Andrew Koenig <ark@research.att.com> wrote in message news:<yu99ofiticbz.fsf@europa.research.att.com>...
> I would like to see a realistic example of a program in which the
> proposed feature would be useful.

A theoretical argument:

Write a function f(a, b) that is equivalent to a = b. Test this function on

char * p;

f(p, 0);
f(p, "literal");

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Peter> Andrew Koenig <ark@research.att.com> wrote in message
Peter> news:<yu99ofiticbz.fsf@europa.research.att.com>...
>> I would like to see a realistic example of a program in which the
>> proposed feature would be useful.

Peter> template<class Itf> class smart_com_pointer { public:

Peter> smart_com_pointer & operator= (Itf *); smart_com_pointer &
Peter> operator= (IUnknown *); };

Peter> smart_com_pointer<IMyComInterface> p;

Peter> p = 0; // ambiguous, must add operator=(int) to resolve.

And how would your proposed feature solve this problem?

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Andrew Koenig" <ark@research.att.com> skrev i melding
news:yu99pu37pwtq.fsf@europa.research.att.com...
> Peter> Andrew Koenig <ark@research.att.com> wrote in message
> Peter> news:<yu99ofiticbz.fsf@europa.research.att.com>...
> >> I would like to see a realistic example of a program in which the
> >> proposed feature would be useful.
>
> Peter> template<class Itf> class smart_com_pointer { public:
>
> Peter> smart_com_pointer & operator= (Itf *); smart_com_pointer &
> Peter> operator= (IUnknown *); };
>
> Peter> smart_com_pointer<IMyComInterface> p;
>
> Peter> p = 0; // ambiguous, must add operator=(int) to resolve.
>
> And how would your proposed feature solve this problem?
>
With the proposal a operator=(null_t) must be added instead of
operator=(int).
Since operator=(int) is valid for all integers the operator=(null_t) is an
improvement since
it is just valid for the null pointer constant std::null.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Andrew Koenig" <ark@research.att.com> skrev i melding
news:yu99y9hvq488.fsf@europa.research.att.com...
> Is the idea that you want std::null to have a magic type named
> null_t that is used for no other purpose?
Yes.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Andrew Koenig <ark@research.att.com> wrote in message news:<yu99pu37pwtq.fsf@europa.research.att.com>...
> Peter> Andrew Koenig <ark@research.att.com> wrote in message
> Peter> news:<yu99ofiticbz.fsf@europa.research.att.com>...
> >> I would like to see a realistic example of a program in which the
> >> proposed feature would be useful.
>
> Peter> template<class Itf> class smart_com_pointer { public:
>
> Peter> smart_com_pointer & operator= (Itf *); smart_com_pointer &
> Peter> operator= (IUnknown *); };
>
> Peter> smart_com_pointer<IMyComInterface> p;
>
> Peter> p = 0; // ambiguous, must add operator=(int) to resolve.
>
> And how would your proposed feature solve this problem?

The idea is to eliminate magical things from the language that act in
a special way but this is not reflected in the type system. If I can
name the type of the null pointer magic constant, I can add an
overload that only takes null pointers, not arbitrary integers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Andrew Koenig <ark@research.att.com> wrote in message
news:<yu99ofiticbz.fsf@europa.research.att.com>...

> I would like to see a realistic example of a program in which the
> proposed feature would be useful.

Useful in what way?  One of the aspects I find useful about having a
special type for null is what it cannot do: trying to pass it to a
vararg, or trying to instantiate a template on it.  Obviously, I can't
show you a working program which would use this feature:-).  On the
other hand, I'm willing to bet that there are still a number of Unix
programs which use either 0 or NULL as the last argument to execl,
even though the language standards say clearly that it is undefined
behavior.  (On my Solaris system, man execl says to do exactly this.)

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orient   e objet
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany, T   l.: +49 (0)69 19 86 27

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Atle Slagsvold" <atleslag@online.no> wrote in message news:<_w4a8.2335$%m1.42193@news4.ulv.nextra.no>...
> This is a proposal to replace NULL and 0.

Good.

> The reason NULL and 0 should be replaced is the overloading
> capabilities built into C++. Another reson is that NULL is ugly and a macro
> and 0 is a magic number.

I agree

[example snipped]

I am not sure this will work though because compilers are under orders
to treat '0' in a magical way when it comes to pointers. Not so for
std::null. What is needed IMO is a token that is treated magically in
just the same way that '0' is. Unfortunately the community is divided.
Not everyone wants another magic token when the standard says to use
'0'.

One could say that null should be cast and then it would work but then
one could always cast 0 to make its use as a pointer clear. The
trouble is a cast in the latter case is un-necessary and will not be
liked by some.

Regards,

Andrew M.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I would like to see a realistic example of a program in which the
proposed feature would be useful.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> I am not sure this will work though because compilers are under orders
> to treat '0' in a magical way when it comes to pointers. Not so for
> std::null. What is needed IMO is a token that is treated magically in
> just the same way that '0' is. Unfortunately the community is divided.
> Not everyone wants another magic token when the standard says to use
> '0'.

This is a proposal to use std::null as this magic token in the standard.
Using plain 0 or NULL would then be considered bad style, but it would be
legal.

Atle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

This is a proposal to replace NULL and 0.
The reason NULL and 0 should be replaced is the overloading
capabilities built into C++. Another reson is that NULL is ugly and a macro
and 0 is a magic number.
Example:
#include <iostream>
using namespace std;

void func(void *)
{
    cout<<"pointer"<<endl;
}

void func(int)
{
    cout<<"int"<<endl;
}

int main()
{
    void *ptr=NULL;
    func(ptr);
    func(NULL);
    func(0);
}

This is the output I want:
pointer
pointer
int
This is the output I get:
pointer
int
int

My solution to this problem is to add the following to the next C++
standard:

namespace std
{
enum null_t
{
    null
};
}

This may be in a headerfile, but I would prefer it to be automatically
available.
A better option is to make it a builtin type, but i suspect this would lead
to problems
with existing code.

Then null is detectable on type and my example above is replaced with:

#include <iostream>
using namespace std;

void func(null_t)
{
    cout<<"pointer"<<endl;
}

void func(void *)
{
    cout<<"pointer"<<endl;
}

void func(int)
{
    cout<<"int"<<endl;
}

int main()
{
    void *ptr=null;
    func(ptr);
    func(null);
    func(0);
}

Not only does it work as expected. It also looks better.

--
Atle Slagsvold - Software Development Engineer
THALES COMMUNICATIONS AS - http://www.thalesgroup.no


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]