Is it logical to return a pointer to a char * you take as function argument?

So how such thing can be used to create such silly nesting functions: Z.reset(...C.reset(B.reset(A.get()))...) so a function would loo开发者_运维技巧ck like

    char * reset(char * buffer)
    {
        ... 
                    return buffer;

    }

so... my question is - such thing is acceptable in C++ simple API you would show to people or not?

My honest answer is that you shouldn't do this in C++ because you shouldn't be using C-style strings in C++. :-)

But yes, it is considered good practice to do this, because it can avoid unnecessary inefficiency losses. See this post by Joel Spolsky on Shlemiel the Painter for a discussion as to why this is.

It is perfectly acceptable, but,

You should not use char* in C++. Use std::string instead.

Technically, this is allowed. Strictly, it is acceptable. But I still wouldn't do it.

The only reason I can think of to engineer a function like this is to support Method Chaining, which I think is an abomination. Opinions on this differ. You may love them, think they are nice & expressive, good for IntelliSense, what have you. Indeed, sometimes it might even be the Right Thing.

Method Chaining aside, I don't see what this gets you that you'd want. In fact, I think it gets you something you don't want: confused semantics. If someone is looking at your header file they are going to see this return and wonder why they need it. They may think it is something it's not, like memory they have to manage or something. Who knows. But the semantics are not entirely clear. So I would avoid it.

Well if you're passing a char* in the first place and modifying it I don't see a need to return it. The only time I think that char* reset(char* buffer) should be the signature is if you return an error message in case something happened that shouldnt have.