>From: "Terje Slettebų" <[EMAIL PROTECTED]> > >From: "Gennaro Prota" <[EMAIL PROTECTED]> > > > In some old newsgroup post, searched through Google a while ago, I > > also read that the committee rejected a proposal to allow the > > generalized form f(T) with T=void, but I've never read the proposal > > itself (I didn't find it at that time). Maybe Dave can do something to > > raise the dead though ;-) > > Why would we want that? What is this useful for?
FWIW, the f(void) notation was introduced in C++ for compatibility with C (D&E, p. 41): "C with Classes introduced the notation f(void) for a function f that takes no arguments as a contrast to f() that in C declares a function that can take any number of arguments of any type without any type check. My users soon convinced me, however, that the f(void) notation wasn't elegant, and that having functions declared f() accept arguments wasn't intuitive. Consequently, the result of the experiment was to have f() mean a function f that takes no arguments, as any novice would expect. It took support from both Doug McIlroy and Dennis Ritchie foe me to build up the courage to make this break from C. Only after they used the word "abomination" about f(void) did I dare give f() the obvious meaning. However, to this day, C's type rules are much more lax than C++'s, and ANSI C adopted "the abominable f(void)" from C with Classes." Further, he says: "Unfortunately, ANSI C adopted f(void) so I had to introduce f(void) into C++ for ANSI C compatibility." (http://technetcast.ddj.com/tnc_program.html?program_id=9). After having broken C programs to introduce f() as a way of unambiguously specifying no parameters, in C++, why would we want to go back to the C way of doing things, with f(void)? Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
