The D Programming Language
in [C++]
|
From: Alf P. Steinbach on 22 Nov 2006 06:14 * Walter Bright: > Alf P. Steinbach wrote: >> * Walter Bright: >>> Alf P. Steinbach wrote: >>>> But even if so, how does an Imaginary type help with that, when x+i*y >>>> can always be represented as Complex(x,y) and vice versa? >>> >>> This explains it better than I can: >>> http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf >> >> Forgive me if I failed to find the quote you intended in that long >> document. > > See page 15. Well, what you snipped from my response was from page 15. Could you be a /little bit/ more specific, please, Walter? E.g., a quote would be nice, if it isn't too much text (or graphics). -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 22 Nov 2006 07:00 "Greg Herlihy" <greghe(a)pacbell.net> writes: [...] | Hasn't anyone ever wondered how exactly the C++ | Standard is able to find so much undefined behavior in the execution of | the most deterministic finite state automaton ever invented - the | modern computer? (1) they are not deterministic. (2) "undefined behaviour" has a very specific meaning technical in the C++ definition text. Look for it in the first clause. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 22 Nov 2006 06:47 AJ <two(a)haik.us> writes: | Gabriel Dos Reis wrote: | > Walter Bright <walter(a)digitalmars-nospamm.com> writes: | > | > [...] | > | > | > I am very happy when I can implement, or extend, some feature without | > | > specific compiler support. | > | | > | There's no way you're going to get std::string, std::vector or | > | std::complex to work as well as core support for such with existing C++ | > | core features. | > | > So, the question is: Can there be better library implementations, or | > can the core language be extended to allow better library | > implementation? (e.g. allow for literal of user-defined types), | > or do you think that there are *intrinsinc* reasons why they must be | > core languages? If yes, could you elaborate on those logical, | > intrinsinc, reasons? | > | | He already has. Sorry, I was looking for logical, intrinsic, reasons. If he had, I've missed it. Upon reading you reply, I searched again; I'm afraid I must have missed it again. | (Dynamic) Strings and (Dynamic) Arrays are just as | common and important in the vast majority of programs as Integers. Dynamic strings and dynamic arrays are important; I'm not sure they are just as important as integers. But considering, for the sake of the argument, that they are equality important, it does not necessarily follow that they must be intrinsic in the language, if the language provides general effective abstraction tools to define strings and arrays in library efficiently. | Integers are an intrinsic part of the language, yet they don't need to. | | I see no indication that a language couldn't get away with a single type | -- bit -- and everything else left to the library. Thus, the same | argument applies to strings and arrays. I'm sure you can exhibit a logical, intrinsic, reason without resorting to proof by analogy -- which is considered by many as fraud. | To be fair, std::string and std::vector are fairly impressive bits of | work, considering how they are constrained. But their deficiencies show | up everywhere. Are their deficiencies intrinsically linguistic that cannot be repaired, or are they library design artefacts? | Can you imagine having to do: | | #include <integer> | | // Binary for 32, because remember, you don't have int literals. | typedef std::integer<0, 0, 1, 0, 0, 0, 0, 0> int32; I don't know what you mean by that. I tried it on my compiler, it choked with: al.C:1:19: error: integer: No such file or directory al.C:4: error: expected initializer before '<' token al.C:6: error: expected ',' or '...' before '&' token al.C:6: error: ISO C++ forbids declaration of 'int32' with no type al.C: In function 'void displayAnswer(int)': al.C:7: error: 'cout' was not declared in this scope al.C:7: error: 'answer' was not declared in this scope al.C:7: error: 'endl' was not declared in this scope al.C: At global scope: al.C:10: error: 'int32' does not name a type | void displayAnswer(const int32& answer) { | cout << "The answer to the life is: " << answer << endl; | } | | const int32 main() { | try { | cout << "2 + 2 = " << int32(1, 0) + int32(1, 0); | cout << endl; | displayAnswer(int32(1, 0, 1, 0, 1, 0)); | | } catch (...) { | return int32(1); | } | | return int32(0); | } Again, please explain the logical idea you wanted to express. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 22 Nov 2006 06:42 Walter Bright <walter(a)digitalmars-nospamm.com> writes: | Gabriel Dos Reis wrote: | > So, the question is: Can there be better library implementations, or | > can the core language be extended to allow better library | > implementation? (e.g. allow for literal of user-defined types), | > or do you think that there are *intrinsinc* reasons why they must be | > core languages? If yes, could you elaborate on those logical, | > intrinsinc, reasons? | | A compiler will always be more powerful than what's possible with the | library, for the intrinsic reason that one can code the compiler to do | whatever one wants to. With a library, you're stuck with what the | compiler chooses to make available. But even for a core language feature, one is also stuck with what the compiler writer has chosen to optimize for, i.e. make available. In 2006, not every C++ compiler supports all core C++98 or C++03 functionalities. Users of popular C++ compilers are stuck with what compilers have decided to make available as language features. For a library solution, I've seen compiler steadily improving support for library functionalities -- think of GCC and its support for C library functions. I'm afraid your speculation is countered by actual data. | I think that's pretty obvious, since no, it is not. | there are no examples of languages where libraries are as powerful as | the compiler. I see libraries as being more powerful than compilers in the sense that libraries allow for development, refinement, of several solutions to the a given problem, with at least the same efficiency as compiler, in a extremely shorter time than compilers. I have been using several implementations of complex classes way long before my favorite compilers decided to have an intrinsic type for complex numbers. Similarly for vectors. | If it was possible, out of the thousands of languages | invented, certainly one of them would have done so? Some have done quite a remarkable job at it; you just need to admit it. That is a separate problem. | To improve upon the current abilities to create user defined types, one can: | | 1) allow user defined literals | 2) allow user defined syntax | 3) allow user defined semantics | | Currently, C++ (and D) only allow (3), and only to a limited extent. | | You've alluded to a C++ proposal for (1), I haven't seen it so have no | useful comment about it. It has been kept not a secret for a while now. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2116.pdf | I know that D, at least, will not have user | defined tokens, for the reason that such would blow the legs off of | third party tools that process source without needing to be full blown | compilers. That is more a problem with D's design philosophy than an intrinsically linguistic issue. | I don't think (2) can ever happen with C++, for the reason that it's | very hard to see how user defined syntax could ever be retrofitted in to | a language that is already the hardest language in existence to parse | (by a wide margin). I don't think your categorization of (2) is adequate. C++ has been offering (3) for more than 2 decades now. There are several ways of doing (2) without necessarily having user defined tokens. One of them is to allow users to attach their meaning to tokens. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 22 Nov 2006 06:49
AJ wrote: > Earl Purple wrote: > <snip> > > casting a void * to a pointer to a function is undefined behaviour. > > But dlsym() which is a POSIX function returns a void * which often > > needs to be cast back to a pointer to a function. > I don't see why there needs to be undefined behavior in this instance, > or even the more general case. > Foo foo; // Well-Defined. > Foo* foo = new Foo; // Well-Defined. > Foo* foo = dlsym<Foo>(); // "Would be" Well-Defined, if it existed. If it existed. dlsym is `extern "C"': there is no C++ binding for Posix. > If the cast/process fails, you could do one of two things: > a) Throw (as does dynamic_cast by reference). > b) Return NULL (as does dynamic_cast by pointer). > See? No need for UB. > C is an arcane, unsafe, weakly-typed, very user-unfriendly language. C++ > is not C :P. But dlsym is C. And dlsym returns a void*, which (typically) points to a function. You can avoid the undefined behavior entirely by declaring a pointer to function in the .so, using dlsym to get the address of the pointer to function, and then calling with two levels of indirection. Which doesn't help lisibility. Or you can count on the fact that Posix defines things that C++ and C leave undefined, and write something like: int (*pf)() ; reinterpret_cast< void*& >( pf ) = dlsym( ... ) ; This is undefined behavior according to the C++ standard; you cannot access a variable other than as its defined type (or as an array of char or unsigned char). Posix, however, requires that all pointers have the same size and representation, and so indirectly, defines this behavior. -- James Kanze (GABI Software) email:james.kanze(a)gmail.com Conseils en informatique orient?e objet/ Beratung in objektorientierter Datenverarbeitung 9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |