Thread: How does returning values from functions work?

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Xupicor View Post
    Still, you can't escape learning pointers when learning C++. Even in 2016.
    Right, but there's a difference between using them just for the sake of it and where it's necessary. For parameters, that's just doing it for the sake of it.

    As to char* s = "string literal" that implicit conversion was deprecated in C++98, and since C++11 there's no conversion anymore in the language. GCC in C++11 (and C++17...) mode spits out "just a warning", as does Clang in default mode:
    Right! I forgot they had already removed this from the language since 2011. Another good reason to switch books/tutorials. This is just not valid C++.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Nasal Demon Xupicor's Avatar
    Join Date
    Sep 2010
    Location
    Poland
    Posts
    179
    For parameters, that's just doing it for the sake of it
    Sorry for replying as late as I do... I'd have to slightly disagree.
    I think these are both perfectly good usages of C++ in context of modern C++:
    Code:
    //...
    void do_stuff(T& required) {
        use(required);
    }
    
    void do_stuff(T* optional) {
        if (optional) use(*optional);
    }
    Since we don't claim ownership in any case - we're not responsible for any memory management, and as such - it sounds perfectly fine to me. I mean, I wouldn't bash anybody for that code. The pointer here has a reason to be here as it does something that a reference cannot offer us, and since we don't allocate any memory for it - we don't have to worry about releasing it either, we just work with it as-is.
    I do admit though, that if there are ways to avoid this pointer being passed in the code - then that's may be the better way to go, at least in some instances, as I wouldn't exactly jump on using a raw pointers just because I can... But we shouldn't be irrationally scared of them either when it comes to some trivial cases like this.

    Now, for pointers that are "owning" memory - that's a different matter. I'd argue we should learn proper manual memory management at some point (if it should be sooner rather than later, or the opposite is... debatable), as it's an important thing to understand. But other than that - I'd argue we should never actually write a single delete in our code, unless we're implementing our own smart pointer. It may sound quite strong, but we do have std::unique_ptr and std::shared_ptr after all, and we should use them to manage memory lifetimes for us if we can't use other tools like standard containers, etc.

    Also, just because we're using a smart pointer doesn't mean we shouldn't ever use the raw pointer acquired from its .get() - when the smart pointer already ensures that the resource will be alive and released when appropriate, we could just pass the raw pointer around without fear and with better performance (example change in this direction: [RocksDB] Use raw pointer instead of shared pointer when passing Stat… * facebook/rocksdb@5b825d6 * GitHub), or we could also pass around references, where appropriate. This of course is only valid if we're sure we cannot possibly end up with a pointer or reference to a resource that was already released. This can be ensured if the code is properly written, especially if we used a smart pointer to manage that in the first place, as we did in this hypothetical.

    In some other examples where we might need a pointer but we would like to avoid even a smart pointer - we could possibly mitigate that need by using std::reference_wrapper<T>.

    What I'm trying to say, in short, is that pointers shouldn't probably be avoided outright, because they're not always "dangerous" or "bad".
    The sad state of the matter, though, is that in many places C++ is still being taught as if it's C with Classes or C++98, using outdated tools and these unfortunate students have little idea about standard containers, not to mention smart pointers (if they even hear about those in the classroom). But that doesn't mean we should bash on every usage of pointers just because bad teachers teach them badly.

    Now, Elysia, I'm not trying to make it sound like you do - I just wanted to comment on that particular example of using pointers for parameters. Turned out to be a tad more than that. Still, differences of opinions aside - keep fighting the good fight. I think from your posts on the board one can gather a pointer or two to guess that your heart is definitely in the right place.

  3. #18
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,608
    The pointer here has a reason to be here as it does something that a reference cannot offer us, and since we don't allocate any memory for it - we don't have to worry about releasing it either, we just work with it as-is.
    Want to point out that when a parameter is optional, the function will do something with or without that thing anyway, which your example doesn't exactly show. The pointer is NULL and the function then returns.

    I forgot they had already removed this from the language since 2011.
    The C-string is being used in an immutable context anyway, so I would just make it const. That would still compile, even today.

  4. #19
    Registered User
    Join Date
    Nov 2012
    Posts
    1,393
    Quote Originally Posted by Elysia View Post
    First and foremost, you shouldn't be using C-style strings. You can probably google to find tons of good answers as to why not, so I'm going to avoid saying why.
    Your comment about implicit char* conversion is fine, but you are overstating your point with such a general verbot on all C-style strings. For example, using a const char * is just fine. e.g.

    Code:
    cout << "Howdy\n";

  5. #20
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    To be fair, I'm saying we don't want to see const char* str = "Something" anywhere. Passing around "strings" is fine.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. write() and read() int values from socket returning wrong values.
    By Premjith P S in forum Linux Programming
    Replies: 8
    Last Post: 11-29-2012, 02:59 PM
  2. Returning values from functions
    By JayCee++ in forum C++ Programming
    Replies: 4
    Last Post: 10-12-2011, 11:38 AM
  3. Returning values from functions
    By g001 in forum C++ Programming
    Replies: 3
    Last Post: 10-01-2007, 03:42 AM
  4. returning multiple values from functions?
    By jamesn56 in forum C++ Programming
    Replies: 5
    Last Post: 08-23-2005, 01:10 PM
  5. Functions and Returning Values
    By jrahhali in forum C++ Programming
    Replies: 5
    Last Post: 08-22-2004, 12:13 PM

Tags for this Thread