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: George Neuner on 7 Jul 2010 12:37 On Wed, 7 Jul 2010 07:30:34 CST, Mathias Gaunard <loufoque(a)gmail.com> wrote: >On Jul 7, 3:21 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > >> Function objects yes. But the C++ compiler hasn't any notion of semantic >> of the function (internals) anymore - it has generated code. > >I do not really understand what you're talking about, I think Andre is complaining about the lack of introspection. >and neither why it would be a problem. The point of a function object (or any closure-like device) is to use it generically. C++'s lack of runtime multiple dispatch and the inability to readily identify built-in types (char,int,double,etc.) passed in a vararg/stdarg list prevents easy use of FOs having different argument specs (think APPLY in Lisp). Emulating multiple dispatch with argument type checking gets messy very quickly. You need to create both a method to describe the FO's (or worse, function pointer) arguments and a method to identify built-in types passed as list arguments, and then pattern match the arguments you receive against the FO's requirements. If you have a number of FOs to match with arguments - a table of plug-ins maybe - identifying the right one can be painful: you basically have the choice between a function using some kind of heterogeneous list argument (vararg or not) or creating a typed overload for each choice - which may not be possible if you need to dispatch on the runtime types of C++ objects. >> You can't (that easily) pass function objects to another function > >There is nothing hard about it. >Either take it as a template argument or use type erasure with >std::function (but once you erase the type, you necessarily make any >function object monomorphic, as you have to specify a signature). std::function defeats the purpose entirely - it removes the ability of the compiler to type check arguments even for a normal call. >> use pattern matching (e.g. if parameter number2 is of type int and has >> value 5 then emit that code). > >Pattern matching is a feature of sum types, not of functions. They are >tagged unions of different possible types, and pattern matching is a >process that happens at runtime. Note typical statically compiled >implementations do not do any code generation at runtime, so it's >basically a switch or a an indirect function call. I'm sure you have a point to make but it is eluding me. Pattern matching is not a "run time" or "compile time" thing, nor is it a "feature" of sum types ... sum types are sets - pattern matching (and unification in general) is defined over tuples, not sets. How exactly do you think a C++ compiler determines which overload of a function to call? Hint, it's described in �13.3.1 on page 292 of the current draft (n3090). The problem is that C++ overload resolution only matches static types at compile time, so there is no _good_ way to perform multiple dispatch on runtime object types. >You can do the same thing with boost::variant ... Which is a long-winded way to accomplish 1/3 of runtime multiple dispatch ... namely it solves identification of the argument's runtime type. You still need a way to describe function argument lists and to match the list of variant arguments to the descriptions. >> Hm, but this ABI standard (wasn't aware of it) isn't part of the C++ >> standard ? > >No it isn't, it's an industry standard. Sorry, but you are misinformed. ABIs are register level function linkage specifications which, by nature, are CPU (or CPU family) specific. There isn't any "industry standard" ABI - it isn't even possible to define one. A number of popular (or past popular) chip families have multiple incompatible ABIs because OS and compiler vendors could not agree on one. Examples of families (or closely related chips) that sported multiple ABIs include but are not limited to: x86(-32), 68K, 29K, VAX, 8080/Z80 and 6502/65816. >All platforms follow the Itanium C++ ABI adapted to their architecture, That statement doesn't even make sense. You can be certain that the ABIs for PowerPC, ARM, SPARC, etc. most definitely are NOT adapted from the Itanium. >except the windows platforms that follows the Microsoft ABI. If there is a common ABI for a platform, it should be supported by all compilers for all languages. George -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: George Neuner on 7 Jul 2010 12:38 On Wed, 7 Jul 2010 06:11:44 CST, nmm1(a)cam.ac.uk wrote: >Walter Bright <walter(a)digitalmars-nospamm.com> wrote: >> >>Does anyone use the [IEEE 754R] decimal formats? > >Not yet, obviously. But the reason for their introduction was the >belief that they will. We shall see. I doubt we'll see much use until popular hardware (read "x86" and maybe also ARM) supports decimal directly. AFAIK, only the Power6, z10 and a couple of oddball chips currently have decimal capable FPUs. Power is certainly not "rare" but I don't think there are enough installations to deserve calling it "popular" ... and the Power6 hasn't been out long enough for most Power users to have upgraded. George -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 7 Jul 2010 12:47 In article <i12g45$3ha$1(a)news.eternal-september.org>, Walter Bright <walter(a)digitalmars-nospamm.com> wrote: > >>> I have no problem with, for example, a "fast float" compiler switch >>> that explicitly compromises fp accuracy for speed. But such behavior >>> should not be enshrined in the Standard. >> >> Eh? The standard has the choice of forbidding it or permitting it. Are >> you seriously saying that it should be forbidden? C++ is already slow >> enough compared to Fortran on numeric code that making it worse would be >> a bad idea. >> >> What I am saying is that such matters are not currently specified >> by the standard, and therefore a conforming implementation is free >> to choose what it supports and what it makes the default. > >I understand that's your position. I disagree with it. The standard >should set a higher bar for accuracy. Eh? I don't think that you DO understand! I was stating what the standard specifies, and not stating that it should do what it does. I agree that I did also state that your definition of accuracy is misguided, and I am afraid that I stand by that. A better one would be needed for standardisation. >The standard setting a higher bar does not impair in any way an >implementation offering a switch to enable faster floating point >with decreased accuracy. Oh, yes, it does! Currently, the language standards (i.e. Fortran, C and C++) have no concept of a default environment, and implementations are either conforming or not conforming. If you make any difference from your preference non-conforming, I can assure you that most Tier 1 vendors' compiler teams will be forbidden from implementing anything else, even as an option. That's from actual experience, working in collaboration with them, incidentally. What you are wanting is a new standards concept. I have no objection in principle, but have failed dismally to get a much simpler one adopted by any of the ones that I have tried (i.e. the concept of mandatory warnings). Good luck, but please get that adopted first. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Stanley Friesen on 7 Jul 2010 12:57 Andre Kaufmann <akfmnews(a)t-online.de> wrote: >joe wrote: >> Andre Kaufmann wrote: >>> Agreed, C# and Java strings are not perfect, but better than C++ >>> standard strings regarding Unicode. I think C# has been influenced by >>> Windows Unicode support. >>> >> >> What is wrong with fixed-width Unicode (UCS-2 or UCS-4)? If someone has >> put those out in the dumpster, then I'm a garbage-picker! You make it >> sound like fixed-width is evil. Do tell what you think/are thinking! > >I don't think it is evil, have I stated that ? Well, at the very least UCS-2 only implements a subset of Unicode. Admittedly it is by far the most commonly used subset, but it still leaves out an entire category of users . Of course I am the sort of guy that like to view Web pages with Runic letters correctly :-) -- The peace of God be with you. Stanley Friesen [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ian Collins on 7 Jul 2010 12:57
On 07/ 8/10 08:16 AM, Walter Bright wrote: > Mathias Gaunard wrote: >> I personally don't understand the point of non-recoverable exceptions >> at all. If they're non recoverable, it means it is something that >> should *never* happen, and therefore is a bug in the program itself. >> The program might as well abort and terminate directly. Trying to >> clean up in the face of something that should never happen in the >> first place cannot work, and might actually lead to even more errors. > > Yes, you're quite right. > > Being able to catch them, however, can make debugging a program easier. Isn't a breakpoint on abort() a better alternative? I wouldn't want any unwinding or object clean-up to occur under those conditions. Along with the risk of more damage being done, valuable state information may be lost. -- Ian Collins [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |