Straw Poll: Return True or False?
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
Test for existance first, then attempt delete.
-
That's right, the question didn't indicate that the method did anything more complex. And, if it did, it's possible an enum would be required if a return value was needed to indicate what occured.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
:-D If I have to choose from them,I would choose FALSE. But I would like to design that function to return how many it would have deleted items. And if exception error would happen,that function would return negative number. Because to have more infomation makes that function more useful. But to make that function more useful makes programer more distressful.
-
Test for existance first, then attempt delete.
That's inefficient, the delete will do the check for existence (a second time).
-
But what if your collection is actually a database? (I wasn't referring, literally, to a .NET collection)
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
Chris Maunder wrote:
But what if your collection is actually a database?
Follow the already well-established database model and return an integer representing the number of rows affected. Because with a database, it's just as important to know that you deleted 150 rows as it would be to know that you didn't delete any. (More important, IMHO.)
Grim
(aka Toby)
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL GO
(0 row(s) affected)
-
I would vote the little known third option,
TRALSE, since this was neither TRUE nor FALSE and it might be nice to know the true outcome here...:-D
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that.'" - Tommy (Tommy Boy)
"Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School)At times I use an enum;
{ Good , Bad , Ugly } -
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
I'm thinking enums: eLookHereMateYourAskingMeToDeleteSomethingThatJustDoNotExistYouTwit eYouCallThatAnIndexIveSeenBetterIndicesOnAFisherPriceCalculatorYouTwit eItsLockedAskMeLaterYouTwit eRaviAteItYouTwit eDeleteThisYouTwit eOKYouTwit Pretty much covers the most likely scenarios, and makes the error log a little more interetsing. A more difficult case can occur if the ham sandwich is deleted after Ravi has eaten half of it, especially if garbage collection is running in promiscuous mode. Then you should use a real programming laguage.
-
This is a trick questions. None of the answers are fully acceptable. The question doesn't leave room for a third option of returning a status code which can take at least 3 values. Then, the answer would be to just return a separate, third value if the element to be deleted wasn't found! In my philosophy classes I was thought there are actually three states of truth: true, false, and undecided.;) The reason we're stuck with just true and false in programming seems to have something to do with the 0 and 1 values of independent bits.
-
That's inefficient, the delete will do the check for existence (a second time).
How so? Psuedo Code if (list.contains(item)) { bool bOK = list.delete(item); //Do something here we bOK if you want } This would skip delete calls to items that no longer exist. The delete just deletes, it doesn't do a check on existance.
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
Long time lurker, first time commenter... Personally though regardless of how you get there you only want True or False if the function succeeds or fails in deleting the item from the collection. If it doesn't exist it has done neither and you really do need to handle that. It is unlikely that if you carefully created the collection the case of neither happening is highly unlikely but it can, and will, happen. Improper, or worse yet no, error handling is a pox and while it is tedious and annoying the long term benefits to error/exception handling are worth it. If I must pick one though... False, as nothing was deleted. Even in that it should send up a flag somewhere as, presumably, the point is to get rid of the item.
"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." - Ralph Waldo Emerson, Essays. First Series. Self-Reliance.
-
The question was: "If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or" You said you voted '1'. Surely if I call delete, and the item DOES exist, it's going to return true ? And so, if it doesn't exist, it's also going to return true. When will it return false ? I'm not sure I see how removing an item from a list is going to fail, when the item is in there. Or am I missing something ?
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
Surely if I call delete, and the item DOES exist, it's going to return true ? And so, if it doesn't exist, it's also going to return true. When will it return false ?
You'd return FALSE if it existed and you couldn't delete it! (from a generic sense, anyways.)
Christian Graus wrote:
I'm not sure I see how removing an item from a list is going to fail, when the item is in there.
It could fail if deleting required actually removing some object that was locked as well as a reference in a list, say, a file. I think that in most cases, not finding the item should return TRUE as the concept is likely to be: "Make sure that it doesn't exist". Given all the answers I've read, if you were concerned with a concept of "I was expecting it and if it doesn't exist, there's a problem" then I'd suggest that the return should not be Boolean but an enumerate with values like: I deleted it like you asked I couldn't find it, are you nuts? I couldn't get rid of the blighter Giving your enumerated type values like those above would certainly add some levity to your code!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
Return NULL... end of discussion. Heheheheeeeee :laugh:
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
A boolean is really wrong here. You need at least three possible outcomes. Claude
-
:laugh: Yeah but the HRESULT is only zero or non-zero and you have to call another function/method to find out why it failed. Where have I seen that before...
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
Who cares? I mean...just get back to work and code something useful. ;P -- modified at 17:42 Wednesday 2nd May, 2007
-
Uhm, you could return false if something went wrong (No DB connection, index out of range e.g.). In that case a returncode or Exception would be more convenient. But that wasn't the question.
--------------- don't P A N I C
...boolean is too restrictive for this task. Return a string (ideally from an enum). Then you can describe most of the likely exceptions / outcomes exactly as you wish. If you insist on being ultra efficient, using bits or bools wherever possible, it's your choice. But these days we've all got so much RAM...
'Make the 'puter work harder so you don't have to.'
-
Here's a philosophical question: If you have a function that is meant to delete an item from a collection and the item you wish to delete doesn't exist, do you: 1. Return TRUE since the final outcome (not having that item) has been fulfilled, or 5. Return FALSE because since the function couldn't find the item, it couldn't actually delete it. Vote now.
cheers, Chris Maunder
CodeProject.com : C++ MVP
The 9 things Microsoft should be announcing at MIX07 (but won't)
I see three different outcomes here. 1. The item is found and deleted. Final result: the item is not in the collection. 2. The item is not found in the collection. Final result: the item is not in the collection. 3. There is an error while either looking for the item or trying to delete it. Final result: unknown (unpredictable) Since when the function works fine, the item is finally not in the collection (therefore that's something you already know), it would be useful to use the return value to know something you wouldn't know otherwise, like if the item was there in the first place or not (TRUE if the item was deleted, FALSE if it wasn't there). In case 3, where something went wrong, I think the best choice is to throw an exception, since it's an abnormal case. Besides, it can go wrong in many different ways, and a TRUE/FALSE result wouldn't help much in finding the cause.
-
Number 1 is the way I would go with it. Actually I can't see how anyone would ever pick 5 unless they are some sort of control freak. 1 accomplishes the job painlessly.
"110%" - it's the new 70%
You're right. I am a freak. Just how much of a freak, you'd never believe. But apart from that, I am not convinced by your argument: 1. There is nothing in the question that says you *have* to define TRUE as success. In some languages, 0 is the code for success, and this casts to FALSE. 2. The purpose of the call *could* be to free up the disk space occupied by the item, in which case, the function has *failed*. So I would return FALSE. Alternatively, both (1) and (2) could be the case. Which would make your answer correct, but in a rather freaky sort of way, no? My blog:http://allwrong.wordpress.com[^]
-
How so? Psuedo Code if (list.contains(item)) { bool bOK = list.delete(item); //Do something here we bOK if you want } This would skip delete calls to items that no longer exist. The delete just deletes, it doesn't do a check on existance.
Jon Raynor wrote:
This would skip delete calls to items that no longer exist. The delete just deletes, it doesn't do a check on existance.
Not necessarily, unless item.contains() returns a reference (or the collection holds a reference to the last looked up element internally in some way or another) to the item it would not skip the second lookup for items that exist and will be deleted. To avoid the second lookup you would have to do something like this: ITEMREF ref = NULL; ref = list.contains(item); // NULL = no item found, non-NULL is ref to item if(ref != NULL) { BOOL bOK = list.delete(ref); if(!bOK) shoutOutErrorMessageToTheWorld(); } Maybe this is what you meant, but your pseudo code does not indicate that.