Pointers have little to no use

[LB]

http://www.cplusplus.com/forum/general/127485/

[D80DSL3A]

OK Your Wrapper class does provide the needed pointer workaround.
Very interesting!

This createList() works as well as the one using a pointer:

refNode& createList( std::istream& is, int& size )
{
    int temp = 0;
    is >> temp;// hopefully this works. Otherwise a one node list comes back with data = 0.

    Wrapper<refNode> head( *new refNode( temp ) );// the 1st, self referential node
    size = 1;

    while( is >> temp )
    {
        head.rebind( *new refNode( temp, head.t ) );// all subsequent nodes
        ++size;
    }

    return head.t;
}

Was that your point? There's a lot in the thread linked to about whether references occupy space in memory. It seemed the conclusion was 'it depends on what you're doing with them'. Evidently, my program forces the references to be implemented as "a pointer underneath", as noted in one thread post.

[LB]

The conclusion of the thread was that the code snippet in the first post is undefined behavior. This is why I steered you toward std::reference_wrapper.

[D80DSL3A]

OK. Good enough then.

[MiiNiPaa]

I just found out that I use raw pointers extensively in my code: http://ideone.com/TmL5d2

[giblit]

http://www.cplusplus.com/reference/iterator/iterator/
According to here they just compare the pointers.

[3hM2Nwbp]

The only time that I can be coerced into using pointers is for my own internal coding that should never see the light of day (and even then, they always come from an implementation found in <memory>). I would never consider exposing one to user-code (nor have I been tempted to for the past couple years).

IMHO *C++* libraries that expect users to muck around with naked pointers are quickly moving to the obsolete bin in my book. The C++ standard library now handles the gory details for us. Why fight it?

note the emphasis on *C++* libraries

C/C++ API monstrosities have always and will always have a bad smell about them.

[giblit]

IMHO *C++* libraries that expect users to muck around with naked pointers are quickly moving to the obsolete bin in my book.

So Qt is on its way to being obsolete? You have to use naked pointers on everything but its a bit different than normal applications. Every parent object destroys(deletes) the children objects.

[3hM2Nwbp]

@giblit -- You won't find me using Qt.

Just out of curiosity, what happens if a user calls delete on an arbitrary pointer returned by the Qt API?

giblit wrote:

Every parent object destroys(deletes) the children objects.

That sounds like a job for automatic (RAII-based) memory management to me. I won't further criticize, as I am not familiar with the API or its authors or even when it was written. If I had to guess, were the library to be rewritten today, things would be implemented differently.

[giblit]

I would assume it is removed from the parents list of children. http://www.digitalfanatics.org/projects/qt_tutorial/chapter02.html

[LB]

@MiiNiPaa: No, you use iterators extensively in your code. The implementation of the iterator happens to be a pointer, but you use it as an iterator.

[firedraco]

No, you use iterators extensively in your code. The implementation of the iterator happens to be a pointer, but you use it as an iterator.

So in this code:

void func1() {
    //stuff
}

void func2() {
    func1();
}

If I called func2 I wouldn't be using func1()? That sounds suspect to me.

[EwCjE3v7]

What is a

Functors

? On the 7th line
http://www.lb-stuff.com/pointers.html

Did you mean Funtions?

[z05DSL3A]

A functor (aka function object) is a class which defines the operator(), so you can have an object that 'looks like' a function.

#include <iostream>
#include <vector>
#include <algorithm>
#include <iterator>

struct IntComparator
{
    bool operator()(const int &a, const int &b) const
    {
        return a < b;
    }
};

int main()
{
    std::vector<int> items{ 4, 3, 1, 2 };
    std::sort(items.begin(), items.end(), IntComparator());
    std::copy(items.begin(), items.end(), std::ostream_iterator<int>(std::cout, " "));
    std::cout << "\n";
    return 0;
}

[EwCjE3v7]

Oh okay, thanks

[MatthewRock]

Truth is, that raw pointers are now much less used then previously, but they still aren't obsolete. You can use them for writing your own classes or data structures.

As for optional parameters, I believe Common Lisp resolved it nicely - you can set any amount of parameters to be optional, and if user doesn't provide them, they are defaulted to the value you choosed (in C it's mostly null, so you could use 0, or anything you want).
However, it could sometimes happen, that user would pass the exactly same value as default to the function. To counter this, there's also a boolean variable that allows you to check if the value is default by itself, or just happens to be the same as default, but provided by user. Sometimes there's a difference.

Back to C++, raw pointers are still useful, in cases where you need maximum speed available, or when it's just easier to use raw pointers, and they don't affect safety.

[LB]

firedraco wrote:

If I called func2 I wouldn't be using func1()? That sounds suspect to me.

Yes, you would not be using func1(). The implementation would be, however.

[Lowest0ne]

So to bring it back, you don't use pointers because there are wrappers for them.

I think this topic would have been better called "I have little or no use for pointers because the code I write is at a high enough level".

I have a use for pointers, it means I don't need to learn every which way of c++ to get what I need done.

[LB]

I use the wrappers because they are self-documenting.

[Telion]

Pointers are very powerful and have a lot of uses that you wouldn't always think about.

A lot of these uses come from the ability to store an object's identity. This means you can make a variable that holds a value representing an object where no other object has the same value, and you don't need to modify the class itself to accomplish this.

This allows you to implement automatic serialization of objects that have cyclical pointers to other objects. See Boost Serialization for an implementation of this.

You've managed to provide ways to get around the need for raw pointers in many common cases, but if you straight up removed them from the language I think you would find yourself stuck after a while.

I also take issue with your suggestion that there should be a function you call to manipulate bytes. C and C++ handle this very elegantly using pointers; the other languages like Java that expect you to call buffer manipulation functions are the problem. Get used to specifying byte indices and type sizes every time because those languages won't do it for you.