LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   STL String: Uninitialized or some null value (http://www.linuxquestions.org/questions/programming-9/stl-string-uninitialized-or-some-null-value-625331/)

Ephracis 03-03-2008 05:17 AM

STL String: Uninitialized or some null value
 
I want to be able to set a string to something like null. And it should not be "" since it can be a valid value.

My function is supposed to look inside an stl vector and return the string at a specified index.

However, if the index is not valid I need a way to return something that will indicate this. And since "" is a string I cannot return that. And I cannot return null either cause that makes the compiler complain.

So I was wondering if there is anything like string::no_val or string::null or something like that which I can use?

Thanks

ta0kira 03-03-2008 06:00 AM

You could take a reference to a string as an argument and return bool, or just make "" imply an error.
ta0kira

Ephracis 03-03-2008 09:31 AM

Quote:

Originally Posted by ta0kira (Post 3076511)
You could take a reference to a string as an argument and return bool, or just make "" imply an error.
ta0kira

No I cannot use "" since it considered a valid name of a group. But I could use a reference and return a bool. Thanks! :D

ta0kira 03-03-2008 10:10 AM

I ran into the same problem a few years ago myself. I was designing a data-input interface and the return was a reference to a string but I needed to indicate an error somehow. Since the interface was an abstract class, I just added an EOF-checking function so if the user of the interface came up with a "" then they could check the EOF function to see if it was the end of data or just a blank line. That's another option.
ta0kira

PatrickNew 03-03-2008 10:57 PM

I think the "C++ way" to do this would be to not return anything if you don't have a valid string - throw an exception. You don't have to go into deriving a complicated exception class, if there's only one thing that can go wrong (null string) then you can just throw an int.

ta0kira 03-04-2008 05:38 AM

Exceptions add a lot of extra stuff to a program, though. Also, I think it's very irritating that the STL does that for things like assigning NULL to a std::string when it really doesn't have to (notwithstanding the standard.) I don't know that the "C++ way" is to throw an exception for a mere error; only if it's something so logically flawed that it doesn't make sense to justify it with a normal error (such as accessing a container element that's outside of the container's boundaries.)
ta0kira

dmail 03-04-2008 08:41 AM

Quote:

Originally Posted by ta0kira (Post 3077557)
I don't know that the "C++ way" is to throw an exception for a mere error; only if it's something so logically flawed that it doesn't make sense to justify it with a normal error (such as accessing a container element that's outside of the container's boundaries.)
ta0kira

Quote:

Originally Posted by Ephracis
...However, if the index is not valid I need a way to return something that will indicate this.

Here is what the Language creator has to say.
Quote:

The C++ exception handling mechanisms are provided to report and handle errors and exceptional events. However, the programmer must decide what it means to be exceptional in a given program. This is not always easy. Can an event that happens most times a program is run be considered exceptional? Can an event that is planned for and handled be considered an error? The answer to both questions is yes. "Exceptional" does not mean "almost never happens" or "disastrous." It is better to think of an exception as meaning "some part of the system couldn’t do what it was asked to do." Usually, we can then try something else. Exception throws should be infrequent compared to function calls or the structure of the system has been obscured. However, we should expect most large programs to throw and catch at least some exceptions in the course of a normal and successful run.

ta0kira 03-04-2008 12:37 PM

I'd say only use an exception if there's a reasonable way to always prevent one that's argument related. In other words, the programmer should be able to avoid an exception by having enough info available to determine if the index is valid. If they choose to disregard that information and still provide a potentially-invalid index then one might consider that malformed code and an exception would be in order.

Exceptions are dangerous a lot of times because they are effectively just a longjmp to the nearest exception handler. This means that unmanaged dynamic memory could be leaked if the stack doesn't contain cleanup code to execute when it unwinds (such as a std::auto_ptr.) It's a bad idea to have an exception thrown across a C function for this reason (i.e. a C function calling a C++-backed function that throws an exception) because C doesn't provide that sort of memory-management ability. In any *nix-specific program it's nearly impossible to avoid that sort of C, so I think significant caution is in order if you intend to support that type of program.
ta0kira

Ephracis 03-04-2008 01:05 PM

It's fun to follow the discussion. Well I went with the usage of a reference and a bool return value, however. And it works.

Thought the discussion about using exceptions are interesting. I haven't been very good at using any exception in my code (ever). So maybe it's time to start now (sigh, another thing to put on my never-ending todo-list).

Quote:

Originally Posted by ta0kira (Post 3077952)
I'd say only use an exception if there's a reasonable way to always prevent an argument-related function. In other words, the programmer should be able to avoid an exception by having enough info available to determine if the index is valid

Actually the developer of the plugin who will call this function has enough information. He can ask how many items there are and of course you cannot have an index below zero. So maybe the best practice would be to use an exception here?

ta0kira 03-04-2008 01:27 PM

Even if you provide an exception, there's no guarantee that the using program will ever see it. The developer can compile either using static built-in C++ libraries, which will prevent an exception from leaving the library itself.

I think returning bool is good enough. If you were returning a reference to a string, however, that might be a good time to use one. Exceptions are unfriendly because their default handling is to end the program. I think it's ironic that modernity supposedly supports exceptions but discourages jumps and gotos. It would be quite a bit different (and more useful) if an exception handler was called in the same way a signal is handled (but with all of the benefits of the C++ portion,) then returned to the instruction immediately after the exception.
ta0kira


All times are GMT -5. The time now is 02:18 PM.