C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Re: Unpopular C++ ideas Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Risto Lankinen Guest Posted: Thu Apr 01, 2004 6:15 pm    Post subject: Re: Unpopular C++ ideas "James Kuyper" <kuyper (AT) wizard (DOT) net> wrote Quote: rlankine (AT) hotmail (DOT) com ("Risto Lankinen") wrote in message news:<vPsac.12785$k4.264657 (AT) news1 (DOT) nokia.com>... What entitles the compiler to assume that <exp> is always true in (<exp>||*0)? If exp is false, then *0 is evaluated, which means that the program has undefined behavior. Therefore, anything is allowed, including code optimizations based upon an incorrect assumption that exp is true. Wow! This is an insanely smart utilization of the "reductio ad absurdum"-type proof of the theorem (<exp>==true). What makes it interesting is that a thinking *machine* can be made to understand it! A lot of weird stuff has been done with templates, but of all C++ idioms that I 've seen that are both cool and wacky at the same time, this one gets the prom queen. Thanks a lot for explaining! - Risto - --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Andrei Alexandrescu Guest Posted: Thu Apr 01, 2004 6:16 pm    Post subject: Re: Unpopular C++ ideas "Niklas Matthies" <usenet-nospam (AT) nmhq (DOT) net> wrote in message Quote: As I wrote in another post, I think it would be better to have a new primitive that takes an expression that is convertible to bool and tells the compiler "you may assume that if this expression would be evaluated, the result converted to bool would be true". Let me try to explain that there is no need for a new primitive. Consider this function: bool foo(int n) { if (!(n >= 0)) abort(); return n >= 0; } I claim that the compiler only needs to know that abort() never returns in order to optimize this function just as well as: bool bar(int n) { super_duper_assert(n >= 0); return n >= 0; } This is because, if the compiler performs standard flow analysis on foo, it will collect on the second line of the function the flow analysis fact that n >= 0. Quote: While in many situations '<exp> || <undefined behavior>' is formally equivalent, it qualifies as a rather obscure hack in my opinion. I definitely agree with that! To answer to all posts that replied to mine, I guess all I'm saying is that instead of thinking of building assert as a language mechanism, we should think of what's needed for programmers to define their own assert-like facilities. The answer is guarantees on standard flow analysis. They are already in place for most compilers (most compilers warn, for example, when a function never returns from a branch). Andrei --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top thp@cs.ucr.edu Guest Posted: Thu Apr 01, 2004 6:52 pm    Post subject: Re: Unpopular C++ ideas Niklas Matthies <usenet-nospam (AT) nmhq (DOT) net> wrote: + On 2004-03-29 18:08, [email]thp (AT) cs (DOT) ucr.edu[/email] wrote: [...] +> Suppose that a given C++ implementation were modified so that: +> (1) When NDEBUG is defined, "assert(<exp>)" expands to say +> "(<exp>||*0)" +> (2) Since all's fair when "<exp>" is false, the expression +> "(<exp>||*0)" generates no code, and + + It does generate code when <exp> produces side effects. I would prefer + <exp> to be never evaluated at runtime in NDEBUG mode, just as with + the current assert(). And this requires language support. IIRC, it's always considered bad programming for the argument to assert to have side effect. + As I wrote in another post, I think it would be better to have a + new primitive that takes an expression that is convertible to bool + and tells the compiler "you may assume that if this expression would + be evaluated, the result converted to bool would be true". It's my impression that the Standards committee is very reluctant to introduce new keywords. Consider, for example, how many times the keyword "static" has been reused. + While in many situations '<exp> || <undefined behavior>' is formally + equivalent, it qualifies as a rather obscure hack in my opinion. Agreed. But it's an "obscure hack" that isn't exposed to public view. In fact, the assert macro already contains a hack to make it a real expression equivalent (in all but side effects) to "0", when "NDEBUG" is undefined. Tom Payne --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Niklas Matthies Guest Posted: Fri Apr 02, 2004 1:07 am    Post subject: Re: Unpopular C++ ideas On 2004-04-01 18:52, [email]thp (AT) cs (DOT) ucr.edu[/email] wrote: Quote: Niklas Matthies <usenet-nospam (AT) nmhq (DOT) net> wrote: + On 2004-03-29 18:08, [email]thp (AT) cs (DOT) ucr.edu[/email] wrote: [...] +> Suppose that a given C++ implementation were modified so that: +> (1) When NDEBUG is defined, "assert(<exp>)" expands to say +> "(<exp>||*0)" +> (2) Since all's fair when "<exp>" is false, the expression +> "(<exp>||*0)" generates no code, and + + It does generate code when <exp> produces side effects. I would prefer + <exp> to be never evaluated at runtime in NDEBUG mode, just as with + the current assert(). And this requires language support. IIRC, it's always considered bad programming for the argument to assert to have side effect. Yes. But consider (in NDEBUG mode): int n = ... assert(is_prime(n)); ... // n not modified here bool b = is_prime(n); If the compiler can see the implementation of is_prime() and can deduce that it is a pure function (no side effects, and the result only depends on the argument), then it can optimize away both calls and translate the last line as: bool b = true; But if it can't deduce that, then *both* calls have to be performed. In particular, the first one has to be performed *even though* the information provided by the assert() has become useless in that case. So, the question is not whether the expression actually has side effects or not, but whether the compiler can see that it has no side effects. Therefore I would rather let the compiler not have the expression unnecessarily evaluated just-in-case. Otherwise it becomes a pessimization rather than an optimization. Quote: + As I wrote in another post, I think it would be better to have a + new primitive that takes an expression that is convertible to bool + and tells the compiler "you may assume that if this expression would + be evaluated, the result converted to bool would be true". It's my impression that the Standards committee is very reluctant to introduce new keywords. Consider, for example, how many times the keyword "static" has been reused. It doesn't need to be a keyword. Like with assert(), a macro would be fine. Quote: + While in many situations '<exp> || <undefined behavior>' is formally + equivalent, it qualifies as a rather obscure hack in my opinion. Agreed. But it's an "obscure hack" that isn't exposed to public view. IMHO the facility _should_ be exposed seperately, i.e. not just as the behavior of assert() in NDEBUG-mode. Assert() doesn't allow very fine-grained control, so many will want the behavior available for building their own assert-like facilities. Currently it's quite compiler-specific which UB expressions, if any at all, have the desired effect on compilation. There would likely be great improvements with a dedicated facility. And, of course, the UB hack doesn't work when we don't want the expression to be evaluated. -- Niklas Matthies --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top John Nagle Guest Posted: Fri Apr 02, 2004 1:07 am    Post subject: Re: Unpopular C++ ideas Here's the problem: Example: char tab[100]; void printstars(int fd, int n) { for (int i=0; i<n; i++) { assert(i < 100); // in practice, the assert is in some collection class tab[i] = '*'; } write(fd,tab,n); } Now clearly this will fail at the assert if n>100, just before it would subscript out of range. But the assert is executed on every iteration of the loop, which is safe but inefficient. One would like this optimized to char tab[100]; void printstars(int fd, int n) { assert(n<=100); // hoisted by compiler for (int i=0; i { tab[i] = '*'; } write(fd,tab,n); } which is far more efficient. But that code will fail "early", before any of the loop iterations are executed. The final value in "tab" will be different than if the program were allowed to run up to the failure point. So the compiler can't perform that optimization unless it knows more about "assert". If we get this right, it will be possible to put many more asserts in collection classes without impacting inner loop performance. John Nagle Andrei Alexandrescu (See Website for Email) wrote: Quote: "Niklas Matthies" As I wrote in another post, I think it would be better to have a new primitive that takes an expression that is convertible to bool and tells the compiler "you may assume that if this expression would be evaluated, the result converted to bool would be true". Let me try to explain that there is no need for a new primitive. Consider this function: bool foo(int n) { if (!(n >= 0)) abort(); return n >= 0; } I claim that the compiler only needs to know that abort() never returns in order to optimize this function just as well as: bool bar(int n) { super_duper_assert(n >= 0); return n >= 0; } This is because, if the compiler performs standard flow analysis on foo, it will collect on the second line of the function the flow analysis fact that n >= 0. While in many situations '<exp> || <undefined behavior>' is formally equivalent, it qualifies as a rather obscure hack in my opinion. I definitely agree with that! To answer to all posts that replied to mine, I guess all I'm saying is that instead of thinking of building assert as a language mechanism, we should think of what's needed for programmers to define their own assert-like facilities. The answer is guarantees on standard flow analysis. They are already in place for most compilers (most compilers warn, for example, when a function never returns from a branch). Andrei --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Niklas Matthies Guest Posted: Fri Apr 02, 2004 4:17 am    Post subject: Re: Unpopular C++ ideas On 2004-04-02 01:07, John Nagle wrote: Quote: Here's the problem: snip Just to avoid confusion: What John Nagle is proposing is different from what I am proposing. Both suggestions are quite orthogonal to each other--John Nagle's applies to non-NDEBUG mode, mine to NDEBUG mode. -- Niklas Matthies --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Ian McCulloch Guest Posted: Fri Apr 02, 2004 3:38 pm    Post subject: Re: Unpopular C++ ideas John Nagle wrote: Quote: Here's the problem: Example: char tab[100]; void printstars(int fd, int n) {for (int i=0; i<n; i++) { assert(i < 100); // in practice, the assert is in some collection class tab[i] = '*'; } write(fd,tab,n); } Now clearly this will fail at the assert if n>100, just before it would subscript out of range. But the assert is executed on every iteration of the loop, which is safe but inefficient. One would like this optimized to char tab[100]; void printstars(int fd, int n) {assert(n<=100); // hoisted by compiler for (int i=0; i { tab[i] = '*'; } write(fd,tab,n); } which is far more efficient. But that code will fail "early", before any of the loop iterations are executed. The final value in "tab" will be different than if the program were allowed to run up to the failure point. So the compiler can't perform that optimization unless it knows more about "assert". But it is possible for the compiler to hoist the comparison out of the loop anyway, even if it knows nothing about assert() : void printstars(int fd, int n) { int LoopEnd = std::min(n, 100); for (int i=0; i { assert(true); tab[i] = '*'; } for (int i=LoopEnd; i { assert(false); tab[i] = '*'; } write(fd,tab,n); } To my non-compiler-implementer's eye, this doesn't look any harder to recognize than the case where the compiler knows that assert() is special; as a bonus it doesn't (potentially) change the observable behaviour of the program, or require any changes in the standard. Cheers, Ian McCulloch --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top thp@cs.ucr.edu Guest Posted: Fri Apr 02, 2004 3:39 pm    Post subject: Re: Unpopular C++ ideas Niklas Matthies <usenet-nospam (AT) nmhq (DOT) net> wrote: + On 2004-04-01 18:52, [email]thp (AT) cs (DOT) ucr.edu[/email] wrote: [...] +> IIRC, it's always considered bad programming for the argument to +> assert to have side effect. + + Yes. But consider (in NDEBUG mode): + + int n = ... + assert(is_prime(n)); + ... // n not modified here + bool b = is_prime(n); + + If the compiler can see the implementation of is_prime() and can + deduce that it is a pure function (no side effects, and the result + only depends on the argument), then it can optimize away both calls + and translate the last line as: + + bool b = true; + + But if it can't deduce that, then *both* calls have to be performed. + In particular, the first one has to be performed *even though* the + information provided by the assert() has become useless in that case. + + So, the question is not whether the expression actually has side + effects or not, but whether the compiler can see that it has no side + effects. Therefore I would rather let the compiler not have the + expression unnecessarily evaluated just-in-case. Otherwise it becomes + a pessimization rather than an optimization. + [...] + IMHO the facility _should_ be exposed seperately, i.e. not just as the + behavior of assert() in NDEBUG-mode. Assert() doesn't allow very + fine-grained control, so many will want the behavior available for + building their own assert-like facilities. Currently it's quite + compiler-specific which UB expressions, if any at all, have the + desired effect on compilation. There would likely be great + improvements with a dedicated facility. + + And, of course, the UB hack doesn't work when we don't want the + expression to be evaluated. How about the idiom of defining a simple macro, assume(exp), that expands to "(((exp)||*0),0)" when NDEBUG and SMARTCOMPILER are defined and to "assert(exp)" otherwise. As you point out, in NDEBUG-and-SMARTCOMPILER mode the evaluation exp will be suppressed only if the compiler can determine that exp has no side effects. So, for expression that call external functions, the programmer can use assert. Tom Payne --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Niklas Matthies Guest Posted: Fri Apr 02, 2004 9:24 pm    Post subject: Re: Unpopular C++ ideas On 2004-04-01 18:16, "Andrei Alexandrescu (See Website for Email)" wrote: Quote: "Niklas Matthies" <usenet-nospam (AT) nmhq (DOT) net> wrote in message As I wrote in another post, I think it would be better to have a new primitive that takes an expression that is convertible to bool and tells the compiler "you may assume that if this expression would be evaluated, the result converted to bool would be true". Let me try to explain that there is no need for a new primitive. Consider this function: bool foo(int n) { if (!(n >= 0)) abort(); return n >= 0; } I claim that the compiler only needs to know that abort() never returns in order to optimize this function just as well as: bool bar(int n) { super_duper_assert(n >= 0); return n >= 0; } This is because, if the compiler performs standard flow analysis on foo, it will collect on the second line of the function the flow analysis fact that n >= 0. The difference is that the compiler can't optimize away the test and the abort() call in the first version (unless it happens to know from global flow analysis that n >= 0 always holds for any actual call to foo()). It _can_ optimize foo() to: bool foo(int n) { if (!(n >= 0)) abort(); return true; } No debate about this. But the "super_duper_assert" version is intended to let the compiler *always* optimize the function to bool bar(int n) { return true; } in NDEBUG mode, because the programmer explicitly tells the compiler "look, I promise that n >= 0 will always hold for calls to bar()". See the difference? More generally: For any given boolean expression (at a specific position in source code), flow analysis results into one of the following: T: the expression will always be true F: the expression will always be false TX: there are control paths for which the expression will be true, but for the other control paths nothing can be said FX: there are control paths for which the expression will be false, but for the other control paths nothing can be said TFX: there are control paths for which the expression will be true, and some others for which the expression will be false, but for the remaining control paths nothing can be said X: nothing can be said for any of the control paths Let's assume the programmer believes that the expression will always be true. In general, one chooses between the following two policies: 1) Trust the programmer, unless the compiler can prove at translation time that the programmer is wrong (i.e. when F or FX or TFX). 2) Don't trust the programmer, so if it can't be proven at translation time that the programmer is correct, then perform a check at runtime and complain loudly if it fails (i.e. when not T). Assert() in non-NDEBUG mode caters to policy 2. Assert() in NDEBUG mode sort-of caters to policy 1, only that the compiler is not actually allowed to trust the programmer (i.e. to assume that the assert condition is true) nor to complain (= fail compilation) if it can prove that the programmer is wrong. Consider the simple (if bogus) program: #define NDEBUG #include <cassert> #include <cstdlib> int main(int argc, char * argv[]) { assert(argc == 1); return argc == 1 ? EXIT_SUCCESS : EXIT_FAILURE; } The compiler is _not_ allowed to optimize main() to int main(int argc, char * argv[]) { return EXIT_SUCCESS; } Neither is it allowed to do so with your abort() solution: int main(int argc, char * argv[]) { if (argc != 1) abort() return argc == 1 ? EXIT_SUCCESS : EXIT_FAILURE; } It can only optimize it to int main(int argc, char * argv[]) { if (argc != 1) abort() return EXIT_SUCCESS; } And now consider the UB solution: int main(int argc, char * argv[]) { (argc == 1) || (* (int *) 0 = 5); return argc == 1 ? EXIT_SUCCESS : EXIT_FAILURE; } This - finally - lets the compiler optimize main to: int main(int argc, char * argv[]) { return EXIT_SUCCESS; } And I believe that "hello compiler, you're allowed to trust me that <expr> is true" is a common enough thing for a programmer to say to warrant a generic, articulate language construct for this purpose: int main(int argc, char * argv[]) { __assume(argc == 1); return argc == 1 ? EXIT_SUCCESS : EXIT_FAILURE; } -- Niklas Matthies --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Andrei Alexandrescu Guest Posted: Fri Apr 02, 2004 9:24 pm    Post subject: Re: Unpopular C++ ideas "John Nagle" <nagle (AT) animats (DOT) com> wrote Quote: Here's the problem: [snip] So the compiler can't perform that optimization unless it knows more about "assert". Sorry, this is not the case. All the compiler needs to know in your examples is that when passing more than 100 as an argument, the program will terminate abruptly. That's _all_ it needs to know. Knowledge about abort() terminating the program and a simple if statement is everything that's needed. void printstars(int fd, int n) { for (int i=0; i { if (!(i < 100)) abort(1); tab[i] = '*'; } write(fd,tab,n); } In the example above, if the compiler knows abort() actually aborts the program (reasonable since it's a standard library function), it is able to hoist the test and perform it only once. Andrei --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Niklas Matthies Guest Posted: Fri Apr 02, 2004 11:16 pm    Post subject: Re: Unpopular C++ ideas On 2004-04-02 15:39, [email]thp (AT) cs (DOT) ucr.edu[/email] wrote: Quote: Niklas Matthies <usenet-nospam (AT) nmhq (DOT) net> wrote: + On 2004-04-01 18:52, [email]thp (AT) cs (DOT) ucr.edu[/email] wrote: : How about the idiom of defining a simple macro, assume(exp), that expands to "(((exp)||*0),0)" when NDEBUG and SMARTCOMPILER are defined and to "assert(exp)" otherwise. As you point out, in NDEBUG-and-SMARTCOMPILER mode the evaluation exp will be suppressed only if the compiler can determine that exp has no side effects. So, for expression that call external functions, the programmer can use assert. When writing assume()/assert(), I don't want to think about whether the expression involves such calls or not, especially since whether a function is inline or not can change over the code's lifetime, and for template code can also depend on the compilation unit where it's instantiated. I simply want to say "hello compiler, you're free to assume that the following condition holds (and free to abort compilation if you can prove that it doesn't hold)". I'd also like the facility to not depend on any compilation mode or macro being defined. For example, one might want to select the mode depending on a template parameter (think policy traits). -- Niklas Matthies --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top John Nagle Guest Posted: Fri Apr 02, 2004 11:17 pm    Post subject: Re: Unpopular C++ ideas Is NDEBUG in the standard? John Nagle Animats Niklas Matthies wrote: Quote: On 2004-04-02 01:07, John Nagle wrote: Here's the problem: snip Just to avoid confusion: What John Nagle is proposing is different from what I am proposing. Both suggestions are quite orthogonal to each other--John Nagle's applies to non-NDEBUG mode, mine to NDEBUG mode. -- Niklas Matthies --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top John Nagle Guest Posted: Sat Apr 03, 2004 12:10 am    Post subject: Re: Unpopular C++ ideas The question is what happens BEFORE the program aborts. How much work can the program omit before aborting, once it's clear that the program is doomed to abort. Presumably you couldn't hoist an assert through a function call that did output. It's not clear why making "abort" special is better than making "assert" special. Right now, compilers don't know much about either. John Nagle Andrei Alexandrescu (See Website for Email) wrote: Quote: "John Nagle" <nagle (AT) animats (DOT) com> wrote in message news:%Z%ac.17227$bL3.9172 (AT) newssvr27 (DOT) news.prodigy.com... Here's the problem: [snip] So the compiler can't perform that optimization unless it knows more about "assert". Sorry, this is not the case. All the compiler needs to know in your examples is that when passing more than 100 as an argument, the program will terminate abruptly. That's _all_ it needs to know. Knowledge about abort() terminating the program and a simple if statement is everything that's needed. void printstars(int fd, int n) { for (int i=0; i { if (!(i < 100)) abort(1); tab[i] = '*'; } write(fd,tab,n); } In the example above, if the compiler knows abort() actually aborts the program (reasonable since it's a standard library function), it is able to hoist the test and perform it only once. Andrei --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Dave Harris Guest Posted: Sun Apr 04, 2004 5:25 pm    Post subject: Re: Unpopular C++ ideas [email]nagle (AT) animats (DOT) com[/email] (John Nagle) wrote (abridged): Quote: 1. Move unsafe library functions to new header files. Rather than break existing code, perhaps you could add a new header which contains declarations which make the unsafe functions illegal to use. Eg: // DisableUnsafeFunctions.h enum unsafe_ { unsafe }; char *strcat( char *a, const char *b, unsafe_ = unsafe ); // Calls like strcat( dest, src ) are now ambiguous. For the next standard, it is probably better to have "depreciated" The advantage of DisableUnsafeFunctions.h is that it does not require language changes so you can start using it straight away. -- Dave Harris, Nottingham, UK --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Nicola Musatti Guest Posted: Mon Apr 05, 2004 3:30 pm    Post subject: Re: Unpopular C++ ideas [email]SeeWebsiteForEmail (AT) moderncppdesign (DOT) com[/email] ("Andrei Alexandrescu (See Website for Email)") wrote in message news:<c4hhq8$2h92ci$1 (AT) ID-14036 (DOT) news.uni-berlin.de>... [...] Quote: To answer to all posts that replied to mine, I guess all I'm saying is that instead of thinking of building assert as a language mechanism, we should think of what's needed for programmers to define their own assert-like facilities. The answer is guarantees on standard flow analysis. They are already in place for most compilers (most compilers warn, for example, when a function never returns from a branch). I agree with you. In fact I believe this is an area where the C heritage has probably damaged C++. In the traditional C way of thinking the programmer always does flow analysis better than the compiler. Thus we have libraries that always leave checks to the programmer, instead of the IMO superior approach of always checking in the library and providing ways to disable checks locally (did anybody mention twenty year old Pascal compilers)? With a correct combination of heuristics (the compiler "knows" the standard library), inlining and flow analysis all a programmer would be left to do is to explicitly disable checks that are too expensive to perform and that couldn't be removed/hoisted by the compiler. Any assert facility would benefit from the same approach too. Cheers, Nicola Musatti --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.