The D Programming Language
in [C++]
|
From: Vladimir Marko on 22 Nov 2006 18:33 Walter Bright wrote: > But I do have a couple challenges for you <g>. [...] > 2) Extend std::string to support strings with embedded 0's. No extension necessary. Got any problems with const char literal[]="abc\x00cba\x00"; std::string str(literal,sizeof(literal)-1); ? Regards, Vladimir -- [ 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 18:39 Earl Purple wrote: > Andrei Alexandrescu (See Website For Email) wrote: > > Frederick Gotham wrote: > > > Walter Bright: > > >> I agree with the need for getting rid of undefined > > >> behavior as much as possible, but in a systems oriented > > >> language it's hard to see how it can be gotten rid of > > >> completely. > > > My opinion is the total opposite: Leave behaviour as > > > undefined all over the place giving plenty of freedom to > > > the implementation. > > Ouch. Unless this is a joke, I can only be happy that your opinion isn't > > shared by many :o). Why would you think undefined (I think you really > > meant "unspecified") behavior is a good thing? > casting a void * to a pointer to a function is undefined behaviour. No it's not. It requires a diagnostic. > But dlsym() which is a POSIX function returns a void * which often > needs to be cast back to a pointer to a function. Yes. But even Posix says not to cast the return value to a void* (since Posix requires, indirectly, that the C compiler refuse to compile the code if you do so). But it's true that using the return value of dlsym() requires undefined behavior: void (*pf)() ; *(reinterpret_cast< void** >( &pf )) = dlsym( ... ) ; (This is undefined behavior, since the cast itself is legal, but using the results of it are undefined 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! ]
From: James Kanze on 22 Nov 2006 18:37 Frederick Gotham wrote: > AJ: > > Can someone with a C++ implementation background actually confirm that > > the great hassle that is UB significantly benefits the implementation? > What great hassle is there with UB? Either you can do something in Standard > C++, or you can't. Simple as. And it is preferable that the compiler tell you when you err, and try to do something that you can't. (A lot of the time it does: try accessing a variable that isn't declared, for example. Or assigning to a constant.) > If one writes portable code whose behaviour is not defined by the C++ > Standard, then that's _their_ problem. Actually, it's more their employers problem. Or the problem of however has to maintain the software. The real problem of course, is that programs are written by human beings. And human beings make mistakes. At least I do; I would never intentionnally write code which was undefined on the platforms I target (although I do make use of things which are undefined by the C++ standard, like dlopen). But I've been known to make mistakes. Of course, if everyone on your team is significantly more qualified in C++ than I am, maybe different rules apply. (But with no false modesty, I've yet to encounter such a team.) -- 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! ]
From: James Kanze on 22 Nov 2006 18:38 Francis Glassborow wrote: > In article <1164168814.447157.127010(a)h54g2000cwb.googlegroups.com>, Greg > Herlihy <greghe(a)pacbell.net> writes > >No, the very fact that it is even possible to write a non-portable > >program is a problem that could only exist because the C++ "Standard" > >is incomplete. In other words, what the Standard euphemistically calls > >"undefined behavior" is nothing more than those areas of the C++ > >language that have yet to be filled in. And if those areas were ever to > >be filled in, then concerns about "portable code" would all evaporate - > >because every C++ program would be portable. > And what you seem to miss is that C++ is a general purpose programming > language designed to be useful on many platforms. There are two major > areas of undefined behaviour: > 1) Places where requiring diagnosis is very expensive (or in some cases, > equivalent to solving the halting problem). This is particularly true of > problems arising from separate compilation. Some possible breaches of > the ODR are very subtle (though any well taught programmer will avoid > them) > 2) Places where portability is essentially impossible because of > different hardware having different requirements. 3) Places where someone guessed that sixies based optimization technology might be able to gain a couple of microseconds (which would be nanoseconds today) if the behavior wasn't specified. IMHO, you 2) is essential, and interestingly enough, doesn't really cause problems. I think compilers could do better with regards to 1), but it's difficult to formulate the standard in such a way that they are required to. And 3) is an embarrasement to the language. > It is interesting to note that even languages like Java that target a > single platform (the JVM) exhibit undefined behaviour. At least C++ has > the honesty to identify the problem areas. In all probability, the next version of the standard will add 4) threading problems. (Which in fact enters into your point 1). Except that unlike most of 1) today, I don't think that compilers can do much to detect it.) -- 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! ]
From: James Kanze on 22 Nov 2006 18:41
Gabriel Dos Reis wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] > | 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. I let that statement go, since Walter didn't bother to define "more powerful", and without that definition, the statement is meaningless. The obvious meaning is obviously not what he meant. I know of libraries which can manage a GUI or an HTML connection---now that's real power, and I've never seen anything like that in a language. Or does D have language primitives to open a window or create a button? -- 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! ] |