putting pointers to objects in a set

Started by
21 comments, last by DevFred 14 years, 8 months ago
Quote:
Yup. Failing to return a specific value from a function of type int is bad, and in the case of main() it should be explicitly return EXIT_SUCCESS;

It is permissible for main() to omit the return statement; the behavior is as if return 0 had been specified.

The standard considers EXIT_SUCCESS relevant directly to exit() (and the value of EXIT_SUCCESS is not specified), where its semantics are the same as 0. Since the return statement in main has the effect of leaving the function and calling std::exit with the return value, 0 is just as acceptable a value.
Advertisement
Quote:Original post by ScottMayo
Failing to return a specific value from a function of type int is bad

Wrong.
Quote:
3.6.1 Main function (5)

A return statement in main has the effect of leaving the main function (destroying any objects with automatic storage duration) and calling std::exit with the return value as the argument. If control reaches the end of main without encountering a return statement, the effect is that of executing
return 0;
On the other hand, why a set? Why not a list? Isn't the only thing you get out of this that when you insert the same pointer more than once it has no effect? But why insert the same pointer more than once in the first place?
Quote:Original post by ScottMayo
On the other hand, there is rarely reason to order things by address. You just wouldn't use set for that, you're paying for useless ordering. Which in itself bugs me; I don't know why a set, which is not a term that implies ordering to me, has to be ordered in the first place. They should have been called set and ordered_set. Yeah. Someone fix the standard.
The primary issue I see is that unordered_set makes a very lousy set implementation. Sure, it fulfils the basic requirements (unique elements, quick insertion and inclusion testing), but how often do you use a set for just that? And implementing the set operations (union, intersection, difference, etc.) on an unordered_set is not a happy place to be...

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

How about if you (ugh) reinterpret_cast to int?
I thought about reinterpret_cast, but the result of that would be just as unspecified, wouldn't it ;)
Quote:
3.6.1 Main function (5)

...If control reaches the end of main without encountering a return statement, the effect is that of executing
return 0;


Ick. I stand corrected, but what an ugly addition. Just what the language needed, a special case for main() that makes it look like int functions in general will return 0 if you fall out. I think I'll stick to return 0 (or the more correct EXIT_SUCCESS).
Quote:Original post by DevFred
I thought about reinterpret_cast, but the result of that would be just as unspecified, wouldn't it ;)
Doesn't casting a pointer to an integer immediately take you all the way into the realm of 'undefined'?
Quote:Original post by ScottMayo
I think I'll stick to return 0 (or the more correct EXIT_SUCCESS).
It is the 'correct' part that keeps tripping you up - return 0 is equally correct, the standard guarantees it [smile]

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Quote:Original post by swiftcoder
Quote:Original post by DevFred
I thought about reinterpret_cast, but the result of that would be just as unspecified, wouldn't it ;)
Doesn't casting a pointer to an integer immediately take you all the way into the realm of 'undefined'?

No, just implementation defined, as long as the integer is large enough. From the standard, section 5.2.10 paragraphs 4 and 5:
Quote:
A pointer can be explicitly converted to any integral type large enough to hold it. The mapping function is implementation-defined....

A value of integral type or enumeration type can be explicitly converted to a pointer. A pointer converted to an integer of sufficient size (if any such exists on the implementation) and back to the same pointer type will have its original value; mappings between pointers and integers are otherwise implementation-defined.

Quote:Original post by swiftcoder
It is the 'correct' part that keeps tripping you up - return 0 is equally correct, the standard guarantees it [smile]


It guarantees... something.

http://bytes.com/groups/c/215177-exit_success-guaranteed-always-zero

See post #15. It's language lawyering at the hyper-fine-grained nitpick level, but he's right - there's a reason the standards committee didn't just outright define EXIT_SUCCESS as 0 explicitly, and the reason has to do with the influence of DEC on the C standards committee, back in the bad old days of VMS. EXIT_SUCCESS and 0 can mean different things, though both have to indicate "some kind of" success. The distinction probably died with VMS. But I learned EXIT_SUCCESS back in the day. :-)

Great. Next time I write a main(), I'm going to sit there for five minutes, fretting over return 0, return EXIT_SUCCESS, or }. And I'll do it even though I Know Perfectly Well it doesn't matter. *sigh*

This topic is closed to new replies.

Advertisement