- "Why < cstlib > is more complicated than you might think" - 4 Updates
- "Current Proposals for C++17" - 1 Update
| Ian Collins <ian-news@hotmail.com>: Mar 04 08:20AM +1300 Juha Nieminen wrote: > Yeah. His argument against using C and abhorring C++ is, essentially, > that C automatically leads to good and efficient code, while C++ > automatically leads to very inefficient and problematic code. Maybe he is correct in the case of the Linux kernel. The way code gets added I can see why he would think like that! -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Mar 04 08:25AM +1300 Wouter van Ooijen wrote: > exeactly this (C++ on embedded systems, especially realy small > micro-controllers)? It is my favourite subject, but I have a hard time > finding people and ideas in this direction. Not that I have found. Where I have been involved with small embedded C++ projects, all of the useful information has been in the project coding guidelines. Maybe those of us in this field should be making more noise, if only to counter some of the ancient FUD that is still doing the rounds! -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Mar 04 08:27AM +1300 David Brown wrote: > applicable to modern microcontrollers, modern tools, modern programmers > and modern projects - but many (especially those arguing against C++) > are based on outdated issues or myths. Alas, most of the "reasons" against C++ are soft: someone in the company with a loud voice has a flea up (usually) his arse about C++. Linus being a good example! -- Ian Collins |
| David Brown <david.brown@hesbynett.no>: Mar 03 09:26PM +0100 On 03/03/16 20:25, Ian Collins wrote: > coding guidelines. > Maybe those of us in this field should be making more noise, if only to > counter some of the ancient FUD that is still doing the rounds! Sometimes C++ discussions turn up in comp.arch.embedded, and sometimes embedded discussions turn up here in comp.lang.c++. Both are appropriate newsgroups for this sort of thing. But I don't know of any dedicated sites or publications. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 27 05:19AM +0100 On 27.02.2016 01:54, Richard wrote: > actively improved, proven viability in the marketplace and portable among > platforms. > C doesn't have it. Right. > Python doesn't have it. Well, CPython ships with Tk/Inter (I think it was called). Which is standard in the sense that it's always there, as a basic GUI. > JavaScript doesn't have it. Oh, for JavaScript it's just HTML. > NodeJS doesn't have it. An embarrassment of riches. First of course basic HTML, both on the web, in web apps (including Android phone apps), and e.g. Windows HTML applications (old but still going technology). But then also the two variants of whatever it was called, that was used to build the editor, that the Microsoft "Code" editor is based on (and still uses that). Sorry I'm not more clear on this. I could research it. In fact that's the plan, but I'm not there yet. :( > FORTRAN doesn't have it. > Java doesn't have it. Well, at first Java had AWT, and then Swing built on AWT. At which point, as I recall, they changed the namespaces, breaking lots and lots of code. Infuriating. > C# doesn't have it. C# is like NodeJS, just too many GUI toolkits now. But the main basic C# GUI stuff is Windows Forms. I believe Mono has Windows Forms support? > Library the union of all available libraries on the internet, how > about we sovle the dependency and package system in a reasonable way? > Hell, how about we get modules deployed and widely used? Good ideas all, I agree. And there is already experimental support for modules in Visual C++. Which reminds me to try that out! :) But I think that one should start at the absolutely first little thing that one needs to deal with to do C++ programming. And that is of course the `main` function. Happily Microsoft recently informed me they'll fix their lack of direct support for standard `main` in GUI subsystem programs, in some forthcoming release. Well, at least I chose to interpret the wording that way. But [1]judge for yourself. :) Then, I think it would be nice to get basic type support in place, in particular character encoding value types and ditto string literals, as in my work-in-progress [2]cppx library, or thereabouts. Well not just international text handling support, but also, hm, dates!, and a decimal type sufficient for handling national scale monetary amounts, and, little things like getting -- for Pete's sake -- [3]a `std::pi` constant! It's all the little stuff that makes the language usable. Having each project and person reinvent the wheel again and again and again, is IMHO sub-optimal. Well the Poco library does some of this. But for some reason I've never used Poco -- have any reader? > Either of those is way more [expletive removed] important than a UI > library in the standard. Yes I agree. :) Cheers!, - Alf Notes: [1] <url: https://connect.microsoft.com/VisualStudio/feedback/details/2128262/missing-c-11-standard-macro-stdc-hosted> [2] <url: http://alf-p-steinbach.github.io/cppx/> [3] `M_PI` is already de facto standard, but not part of the C++ standard. It surprised me, once, to realize how much innovation the committee's been doing, while /not/ standardizing widely used existing practice. Anyway, more info: <url: http://stackoverflow.com/questions/1727881/how-to-use-the-pi-constant-in-c> |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment