Thread: string reference

  1. #16
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by cpjust View Post
    Also, what if the function starts out written correctly & returning an auto_ptr, but later as the code evolves, someone decides that they want to keep a local copy of the pointer before returning it. The proper thing to do would be to switch to smart_ptr's, but then that would change the function signature and require all calling code to be changed also...
    you are right, but I see that in a more positive manner: if a local copy of the pointer is hold, then the whole semantic changes. everybody involved should be aware of the fact, that the caller doesn't own the returned pointer alone any more. imagine someone else resets the pointers you thought is in your (alone) ownage.
    a collateral API change is an effective way to signal the change of semantic to everybody who should care.

  2. #17
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by matott View Post
    It returns a concatenated string of name and another string. But if the specified name doesn't exist, the function has to indicate this. I could just figure out one solution: throwing an exception. But I think this is not very useful in this case. Can you imagine another solution (like returning iterator::end (), but for strings).
    If you want to return a reference, you have to return a reference. There's no such thing as a NULL reference. So, you can either throw an exception, or design your function like this:

    Code:
    bool find(const string &a, string &b);
    It returns the result in the b reference, and returns "true" or "false" to indicate whether it failed. If failure is a common occurrence, this is probably the best method. If failure is very UNcommon, I'd throw an exception instead.

    EDIT: I've made the input string const, as it should have been.
    Last edited by brewbuck; 08-20-2007 at 02:49 PM.

  3. #18
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    shouldn't the input string better be a const-reference in this case?
    and shouldn't the decision about exception or not depend on the state of exception safety of the code base in the first place?

  4. #19
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Well, actually the code should always be exception safe, especially when dealing with std::string. It might throw a std::bad_alloc pretty much at any time it is manipulated.

    C++ code should provide at least the basic exception guarantee absolutely everywhere. Otherwise, reuse becomes a real hassle. The basic exception guarantee says that, no matter where (within the language rules) an exception is thrown, the program's state remains internally consistent, even if the exact state is unspecified.

    The other two forms are the strong exception guarantee and the nothrow guarantee. The nothrow guarantee, obviously, says that the operation won't ever throw. The strong guarantee says that in case of an exception, the operation is a no-op and the state is the same as before.

    To illustrate, let's look at a hypothetical string::append method. It gives the nothrow guarantee if it never throws at all. If memory failures are handled using exceptions (e.g. std::bad_alloc), it can only give this guarantee if it knows that it has enough space internally.
    The method can give the strong guarantee if, no matter where through the method an exception is thrown, the string will remain completely unchanged and no memory is leaked. Only if the operation completes successfully will the string have changed.
    The method can only give the basic guarantee if it cannot guarantee that the string remains unchanged. For example, if the method was implemented by appending the characters of the appended string one by one, and any of these append sub-operations can throw, only the basic guarantee is fulfilled, because although the string is in an internally consistent state, it is unknown what exactly its contents are.

    If the method might, on an exception, leak memory or have a dangling or unhandled null pointer - in other words, if the thing leaks resources or might crash if further touched - it can give no exception guarantee at all. In modern C++ code, this is quite unacceptable, in my opinion. No exceptions to this rule - the systems where the effort of making code exception-safe is too great typically don't support exceptions in the first place.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #20
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    thank you, interesting post.
    off topic: Has anyone a nice reference giving advice how to achieve the different levels of exception safety practically in common situations?

  6. #21
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Scott Meyers devotes an item several pages long to the topic in Effective C++, 3rd edition. (The item is new in this edition. If you have an earlier one, get the 3rd. A lot is new, and it's worth it.)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #22
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545

  8. #23
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by pheres View Post
    shouldn't the input string better be a const-reference in this case?
    and shouldn't the decision about exception or not depend on the state of exception safety of the code base in the first place?
    Yes, I should have made the input string reference const.

    As for non-exception-safe code... I wouldn't recommend writing anything of the sort.

  9. #24
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by pheres View Post
    thank you, interesting post.
    off topic: Has anyone a nice reference giving advice how to achieve the different levels of exception safety practically in common situations?
    If you strive to avoid using pointers, this goes a long way toward making your code exception-safe. Use exception-safe container objects. Hold data by value whenever possible. I've written very large programs without ever using a pointer.

    The other thing to be careful about is multithread logic. This can be severely damaged by exceptions. Again, it's important to use as few pointers as possible. Take advantage of the automatic deconstruction of local objects -- a smart pointer will make local pointers safe to use. If you must multithread, the boost library provides some key features to make things exception-safe.

    Whenever you type the "*" character, you should immediately think "What about exceptions?"

  10. #25
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Whenever you type the "*" character, you should immediately think "What about exceptions?"
    I would think about exceptions whether I'm using pointers or not. Most of the STL containers and other code can also throw exceptions...

  11. #26
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by cpjust View Post
    I would think about exceptions whether I'm using pointers or not. Most of the STL containers and other code can also throw exceptions...
    It's not about whether exceptions can be thrown, it's whether or not you have to do anything special about it. If you've got a vector of pointers, and an exception kicks you out of that local frame, you just leaked a bunch of memory. If the vector contained the data by value, you're automatically covered.

    Of course you always have to think about it. But with enough experience you get to the point where you just intuitively know if exceptions are going to be problematic.

  12. #27
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    hm,
    I'm still very unshure about exceptions.
    are the std containers exception safe?
    and would you sign the statement: C++ & multithreading with pthread (c-lib) & exeception safety at the same time is not possible?

    if not: How for example would the following fragment made exception safe:

    thread 1:

    lock A
    // work
    unlock A

    thread 2:

    lock A
    // work
    // do something what possibly throws
    unlock A

    is wrapping the lock-logic into a resource manager class (like auto_ptr) the only possibility?

  13. #28
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by brewbuck View Post
    If you've got a vector of pointers, and an exception kicks you out of that local frame, you just leaked a bunch of memory. If the vector contained the data by value, you're automatically covered.
    if I want to avoid copying using a vector of shared_ptr should be equally well?
    A vector of references isn't very practical I guess, because the referenced objects are destructed while the originator leaves scope and the references all becomes invalid

  14. #29
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by pheres View Post
    is wrapping the lock-logic into a resource manager class (like auto_ptr) the only possibility?
    Maybe not the only possibility, but it's a good method. RAII -- there's nothing wrong with it.

  15. #30
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    If the vector contained the data by value, you're automatically covered.
    It also depends on the type of guarantee your code should uphold. If you want to provide the String Guarantee, pointers aren't the only thing to worry about.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. reference string
    By chocolatecake in forum C Programming
    Replies: 6
    Last Post: 05-14-2009, 06:02 AM
  2. Undefined Reference Compiling Error
    By AlakaAlaki in forum C++ Programming
    Replies: 1
    Last Post: 06-27-2008, 11:45 AM
  3. Compile Error that i dont understand
    By bobthebullet990 in forum C++ Programming
    Replies: 5
    Last Post: 05-05-2006, 09:19 AM
  4. How to: Use OpenGL with Jgrasp
    By Pickels in forum Game Programming
    Replies: 3
    Last Post: 08-30-2005, 10:37 AM
  5. Classes inheretance problem...
    By NANO in forum C++ Programming
    Replies: 12
    Last Post: 12-09-2002, 03:23 PM