2

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 loock 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?

Rella
  • 65,003
  • 109
  • 363
  • 636
  • 1
    strcpy() kicked that door open, not exactly an endorsement. Okay for functions returning std::string with RVO, for C functions it obfuscates memory management IMO. Fluent programming is, well, don't get me started. – Hans Passant Jan 19 '11 at 21:43

4 Answers4

4

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.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
  • Hm... So should I use std::string for raw rgb data?) – Rella Jan 19 '11 at 23:30
  • @Kabumbus- I'd suggest using a custom struct for that data. Use the type system to your advantage - give names to the R, G, and B field data if you can. But if you must use raw RGB data, then yes, a std::string would probably be a good choice. – templatetypedef Jan 19 '11 at 23:46
3

It is perfectly acceptable, but,

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

Xavier V.
  • 6,068
  • 6
  • 30
  • 35
2

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.

Community
  • 1
  • 1
John Dibling
  • 99,718
  • 31
  • 186
  • 324
  • In C (I know this is a C++ question), could be used for shorthand. e.g.: `const char *T_to_str(char *buf, T foo); ... T foo; char buf[256]; printf(T_to_str(buf, foo));`. Not great, but a possible use-case. – Oliver Charlesworth Jan 19 '11 at 22:23
1

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.

Jesus Ramos
  • 22,940
  • 10
  • 58
  • 88
  • I think you meant to say "Modifying *what the pointer points to*." Modifying the pointer itself will not be visible from outside of the function's scope as a copy of the pointer is passed in (i.e., a pointer to a pointer would be required) – Ed S. Jan 19 '11 at 21:41
  • Thanks Ed, I meant so say that I just thought most people would understand. But The others bring up a good point (I've been doing C too long) that he should use std::string instead because of decreased performance of c-string operations. – Jesus Ramos Jan 19 '11 at 21:45