future of the C++
in [C++]
|
Prev: Generating a derived class from a base class
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: Walter Bright on 11 Jul 2010 17:38 Mathias Gaunard wrote: > On Jul 6, 8:27 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > >> C++ const falls short in 3 areas: >> <const doesn't work for compiler optimizations> > > I don't think "it falls short" is the right thing to say. It is correct when referring to the ability of the compiler to make any use of const to generated better code, or to enforce functional programming. > It was simply not made to represent physical constness of objects in memory, > but rather logical constness. I suppose that depends on what the thinking was that went into the specification of const. I don't know what it was. The "mutable" modifier clearly was targeted at logical constness, but I think that came later. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 11 Jul 2010 17:37 Andre Kaufmann wrote: > Walter Bright wrote: >> Mathias Gaunard wrote: >>> On Jul 8, 2:16 pm, Walter Bright <newshou...(a)digitalmars.com> wrote: > >> [...] >> On windows, seg faults are catchable as C++ exceptions. > > Do you mean the "bug", where it was possible to catch C++ exceptions, if > structured exception handling was enabled for an older version of VC ? No, as I don't know anything about how various versions of VC handle SEH. The Digital Mars C++ system allows catching of any Win32 system exceptions with the usual catch statements. > Under Windows7 / Vista it's quite hard to catch a structured exception > caused by an access violation (seg fault) and convert it to a C++ > exception. Why? It's pretty simple with Win32. Do you mean Win64, which has a very different implementation of SEH? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 11 Jul 2010 17:40 Mathias Gaunard wrote: > On Jul 10, 7:58 pm, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > [...] >> But it's a rather new standard, so no wonder that multiple compilers >> "think/interpret different" ;-). > > It's not "think/interpret different", it's "not implemented yet". What's not implemented yet, to use auto in that context ? Even if it would be implemented, not all C++ compilers support all C++0x features and even if they do there is no guarantee that all C++ compilers have implemented the C++ standard 100% correctly. The more complex the standard is, the more compilers will lack features and the more implementation errors will occur. I know that, by having to support multiple C++ compilers for many years. >> It's also a good example, that the verbosity C++ forces us to use is >> contra productive regarding portability. >> IMHO the more complex the code is, the more problems you get regarding >> portability (between compilers and platforms) > > That's C++0x. Of course you're going to have problems if you use a > compiler that is lacking the C++0x features it uses. I was not referring to C++0x, but the code itself. It's too verbose and not readable. If boost.Phoenix is used, then the code is readable. It's nice that a library is able to "fix" that, but I don't think it's efficient to use a library for such features, that should be part of the language itself. And I think the argument and mantra "don't change the language, for features" that can be implemented in code doesn't count here, since IMHO auto keyword and type inference has been introduced too restricted. There may have been good reasons for that, however. Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 11 Jul 2010 18:52 Mathias Gaunard wrote: > On Jul 8, 4:56 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > >> Sample: F# pattern matching >> >> let f x = match x with >> | int -> "integer" >> | _ -> "other" >> >> let value = f 8 >> printfn "%A" value >> >> Prints: "integer" > > This is actually valid OCaml, but f "" prints "integer" as well, and > you do get a warning saying the case is unused. O.k. in that case it's a dumb example. I've played around with pattern matching and it depends on the code, if the compiler is able to do static compilation or emits dynamic code. The same is true for C++. A good global optimizer, will also be able to emit static code or optimize the code by removing switch statements, if the compiler can track the function calls to the first one, which uses a static parameter. What I don't know yet, if the simpler syntax allows the F#/OCaml compiler to optimize better. But anyways I prefer readability over optimization, since commonly the performance is more influenced by the general design of an application, but how good the optimization of the compiler is. Andre -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 11 Jul 2010 22:14
In article <i1d7n7$q3i$1(a)news.eternal-september.org>, Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >Mathias Gaunard wrote: >> >>> C++ const falls short in 3 areas: >>> <const doesn't work for compiler optimizations> >> >> I don't think "it falls short" is the right thing to say. > >It is correct when referring to the ability of the compiler to >make any use of const to generated better code, or to enforce >functional programming. And more :-( I am afraid that 'const' is a dog's dinner, and has been used for so many different purposes that it is unsatisfactory for all of them. Quoting the original C90 rationale: "The syntax and semantics of const were adapted from C++" and "const is specified in such a way that an implementation is at liberty to put const objects in read-only storage". I was not involved with C++ in the 1980s, so can't comment about the former, but the latter is very wrong - and, yes, I know that it was a definite intent, because I was involved. There were several mistakes made with const in C90, where WG14 didn't realise the consequences until after the language started to be used - and I must accept my share of the blame for that. It can sometimes be used to put objects in read-only storage, but many compilers don't bother, as it has so many restrictions on doing so. >> It was simply not made to represent physical constness of objects in memory, >> but rather logical constness. > >I suppose that depends on what the thinking was that went into the >specification of const. I don't know what it was. The "mutable" >clearly was targeted at logical constness, but I think that came >later. As I said, there were lots of intents as what 'const' should do, but I know only some of them - and relatively few of the ones that are in C++ but not in C. Most of the common C/C++ aspects were neither the physical constness of objects in memory nor logical constness, but restrictions on lvalue use to improve optimisability (again the original C90 rationale makes that clear). Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |