- No exceptions, no STL - 9 Updates
- [FYI] 1.68.0 deadline for new libraries approaching - 7 Updates
- calls to hash function in unordered_set - 3 Updates
- High horse - 2 Updates
- [FYI] 1.68.0 deadline for new libraries approaching - 1 Update
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 12 10:13AM On Mon, 2018-06-11, Melzzzzz wrote: > Rant: my new job at embedded programming ;) Because of policy decisions, or technical limitations? I can imagine avoiding dynamic allocation, so e.g. malloc(), plain operator new, std::vector would be unusable ... but std::array would still be ok and useful. Then there was the infamous Embedded C++ standard, which disallowed things like namespaces ... > So I am now C/C++ programmer... Well, there are worse fates. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Jun 12 02:05PM +0200 On 12/06/18 12:13, Jorgen Grahn wrote: > I can imagine avoiding dynamic allocation, so e.g. malloc(), > plain operator new, std::vector would be unusable ... but > std::array would still be ok and useful. Even seemingly innocent classes like std::array can pull in a range of extra code. It is not easy to use bits of the STL without getting a whole pile of extras - including malloc, exception handling, printf functionality, etc. There are other libraries available that can be a better choice for more resource-constrained systems. Of course, it all depends on what sort of embedded programming it is - it could be anything from a small 8-bit microcontroller with 16K flash to a massive multi-core system that is embedded in a box. > Then there was the infamous Embedded C++ standard, which > disallowed things like namespaces ... The "Embedded C++" standard was an abject failure. The theory was that it should support all features of C++ that did not lead to extra code space or run time. This is, of course, a pointless idea - C++ already has the goal of zero overhead for features that you don't use. If you want to avoid the overhead of multiple inheritance, don't use it. The only parts of C++ that can lead to extra code (mostly as static tables) even when you don't use them are exceptions and RTTI - and compilers generally let you disable these. Lack of namespaces was just the most famous example of how thoughtless EC++ was. >> So I am now C/C++ programmer... > Well, there are worse fates. Indeed - you could be a Windows programmer :-( |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 12 11:09AM -0400 On 06/12/2018 08:05 AM, David Brown wrote: > On 12/06/18 12:13, Jorgen Grahn wrote: >> On Mon, 2018-06-11, Melzzzzz wrote: ... >>> So I am now C/C++ programmer... >> Well, there are worse fates. > Indeed - you could be a Windows programmer :-( Speaking of which - I've taken on a new project. The position description said: Requirements: • C++ software programming experience • Windows and Visual Studios 2015 working knowledge. • Bachelor's in Computer Science, Software Development, Computer Engineering or Software Related Field of Study • Minimum of two years' experience as a C++ coder Desired: • Prior experience with M&S software coding. • Prior experience with building M&S environment/terrain generators. • Qt Graphical User Interface (GUI) Software experience. • Five years of relevant experience desired. Apparently not all of the "requirements" were actually required - six years of C++ experience is the only thing I have which matches anything on either of those two lists. I only wrote code for Windows for less than a year, in 1995, and that wasn't my main task at the time. I had some experience on DOS systems before that, but most of my career has involved Unix-like systems. My BS was in Physics. I've written only a couple of small GUI programs, one in VMS Fortran, and another in IDL - I've never used Qt. Would anyone care to recommend some texts I should study to cover the other items on those lists? |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jun 12 05:38PM > On Mon, 2018-06-11, Melzzzzz wrote: >> Rant: my new job at embedded programming ;) > Because of policy decisions, or technical limitations? Don't know yet. Will see, if I can do anything about it ;) -- press any key to continue or any other to quit... |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jun 12 05:40PM >>> So I am now C/C++ programmer... >> Well, there are worse fates. > Indeed - you could be a Windows programmer :-( Heh, I looked this job because of Linux+C++ ;) -- press any key to continue or any other to quit... |
| woodbrian77@gmail.com: Jun 12 10:42AM -0700 On Tuesday, June 12, 2018 at 7:05:39 AM UTC-5, David Brown wrote: > whole pile of extras - including malloc, exception handling, printf > functionality, etc. There are other libraries available that can be a > better choice for more resource-constrained systems. I don't think you get malloc or printf if you use std::array. But in general, can't argue with that. > >> So I am now C/C++ programmer... > > Well, there are worse fates. > Indeed - you could be a Windows programmer :-( Hmm. I'm a Windows programmer to some extent. It's not the end of the world, but I'm glad to be able to work primarily on other platforms. Brian Ebenezer Enterprises - Was Eisenhower the last decent President? http://webEbenezer.net |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 12 07:23PM On Tue, 2018-06-12, Melzzzzz wrote: >>> Rant: my new job at embedded programming ;) >> Because of policy decisions, or technical limitations? > Don't know yet. Will see, if I can do anything about it ;) If it was me, I'd hope it's the latter. Very limited systems have their charms. (And on the other hand, people tend to dislike when you try to change their stupid decisions.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| legalize+jeeves@mail.xmission.com (Richard): Jun 12 08:23PM [Please do not mail me a copy of your followup] James Kuyper <jameskuyper@alumni.caltech.edu> spake the secret code >Would anyone care to recommend some texts I should study to cover the >other items on those lists? I'll give it a shot. >Requirements: >* Windows and Visual Studios 2015 working knowledge. There used to be books on VS, before the web was used to look things up, but generally your best bet now is to rely on the MSDN documentation in order to get the details. Use a tailored google search to avoid stuff from the "Microsoft Community" sites. IMO, those community "answers" are worthless for developers. Stick to the MSDN documentation or even use the built-in help links (which just invoke the web browser to a URL now anyway). Aside from familiarizing yourself with keyboard shortcuts and menus, etc., the big difference here is going to be the build sytem. If you're using CMake, then you won't care about how VS organizes stuff because you'll be generating project/solution files from CMake. Otherwise, the basics are: - A solution file (*.sln) is a bag of projects. Commit this file. - A solution options file (*.suo) is custom options you have set for your solution, like which project should be started when you launch the debugger. Do not commit this file. Later editions of VS put stuff in a .vs folder. Similarly, do not commit this folder. - A project file (*.vcxproj) is a bag of source files along with commands for how to build them into a target: library (static or dynamic) or executable (console of Windows subsystem). - In C++ projects, the view of files in the Solution Explorer is not necessarily 1-to-1 with the organization of files on disk. While this is typical, it is not required. The *.vxproj.filters files hold the mapping from files on disk to files in the Solution Explorer. Commit these files. - Per-project user settings are stored in *.vcxproj.user files; don't commit these files. - All compile flags and options for a target and the corresponding source files are found through the Properties item on the context menu for the item (project or file) in the Solution Explorer pane. - VS defines a bunch of variables for a solution and a project that allow you to parameterize the compiler options. You will see these in the settings as $(SolutionDir). - VS organizes the build into different settings for every combination of "Platform" (e.g. Win32 and x64) and "Configuration" (e.g. Debug, Release). When changing settings through the Properties dialog, make sure you have the correct setting for Platform and Configuration from the drop-down menu or you will be confused why your changes aren't taking effect. The most common use case is to select "All Configurations" and "All Platforms" so that the settings are applied uniformly. - While the Properties dialog box is open, you can click on items in the Solution Explorer pane to switch the settings shown to you in the Properties box. This is a little unexpected because the Properties dialog box is modal. - Bags of common compiler settings can be parameterized into "Property Sheet Pages". This is more of an advanced thing, but helps you keep funky settings consistent between files and projects. - Dependencies between targets are manipulated through the "References" folder in Solution Explorer. Use "Add Reference..." from the context menu on the References folder to setup dependencies between targets. - If your Solution has lots of targets, it can be useful to group them into "Solution Folders" just for organizing purposes. It is cosmetic only and has no bearing on how/when projects are built. Solution Folders are recorded in the .sln file, so they persist in source control. >Desired: >* Prior experience with M&S software coding. >* Prior experience with building M&S environment/terrain generators. This sounds really market specific -- "modeling and simulation environment/terrain generators"? Any chance your new position is with Rockwell Collins? :-) I don't have specific advice here. >* Qt Graphical User Interface (GUI) Software experience. In my experience, once you learn one GUI toolkit, they are all the same more or less. Qt has some things that make it a little funky like the moc processor that generates signal/slot boiler plate code for wiring up the events (signals) emitted by UI elements with the handlers (slots) that process the events. Unless you want to be disgusted, don't dig into the Qt implementation too deeply :-). However, unlike VS there are good books out there for Qt. Ones I have read and would recommend are: "C++ GUI Programming with Qt 4" by Jasmin Blanchette, Mark Summerfield <https://amzn.to/2JBCCV8> "Advanced Qt Programming: Creating Great Software with C++ and Qt 4" by Mark Summerfield <https://amzn.to/2t3TkFB> The titles are self-explanatory. Both have Amazon "Look Inside" previews. You probably won't need the advanced book unless you need to really dig into the model/view framework used in Qt. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "ΓΓΆ Tiib" <ootiib@hot.ee>: Jun 12 03:31PM -0700 On Tuesday, 12 June 2018 00:46:29 UTC+3, Ian Collins wrote: > > that these will be available before the committee > > formally adopts them. > For once I agree with you :) Note that the exception propagation scheme like described in that document was how these were usually implemented in nineties. Most of the FUD and nausea about how inefficient those are have its roots in that time. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 12 01:53PM -0400 On 6/12/2018 1:01 PM, π Good Guy π wrote: > With over 950 million devices now running Windows 10, customer satisfaction > is higher than any previous version of windows. I find that difficult to believe. Everyone I know has issue after issue with Windows 10, mostly related to updates breaking things, or changing behavior. One computer we have has to have the HP printer driver re-installed after each update. Windows 10 is the most unreliable operating system Microsoft has released. It is consistently breaking functionality which previously worked since Windows XP and even Windows 95/98 eras (which were pre-Windows 2000 and the modern kernel design). Rock solid, stable apps that have literally run for 20 years are now breaking and need software modifications to workaround the issues. I'm sorry, but I view Windows 10 as wholly unreliable and would not recommend it for business or casual use. I have seen too many users ready to leave for the day, or start their machine, only to have it complete an installation that takes an hour or more. The only reason people are buying Windows 10 is because they have no choice if they want to run Windows software under a currently supported OS. I'm still hoping React OS makes it. Once it's up and running beyond beta stage (or maybe even to beta stage), you'll see countless users leaving Microsoft's horrid spyware operating system. -- Rick C. Hodgin |
| SilverSlimer <.m@nsn.s>: Jun 12 04:21PM -0400 On Tue, 12 Jun 2018 13:53:26 -0400, "Rick C. Hodgin" >I'm still hoping React OS makes it. Once it's up and running beyond >beta stage (or maybe even to beta stage), you'll see countless users >leaving Microsoft's horrid spyware operating system. I don't think that there is much for you to really hope for with ReactOS. If anything, Wine within Linux is more likely to become a decent, daily compatibility layer than ReactOS is to become a decent, usable operating system. It sucks that legacy software (and hardware) stops working with a new edition of Windows but it was to be expected. Microsoft wants to sell new versions of the same software and help out its third-parties by making you upgrade your hardware. As such, decreasing support for older software they can no longer making any money from makes a lot of sense for them. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 12 04:35PM -0400 On 6/12/2018 4:21 PM, SilverSlimer wrote: > ReactOS. If anything, Wine within Linux is more likely to become a > decent, daily compatibility layer than ReactOS is to become a decent, > usable operating system. React OS has active development and is fairly stable. I ran it in VirtualBox a couple months back and it was impressive. > making you upgrade your hardware. As such, decreasing support for > older software they can no longer making any money from makes a lot of > sense for them. Yes. And it doesn't have to be like that. In my view, it's a real slap-in-the-face to all of the developers and users out there who paid to have software written, and now it suddenly doesn't work simply be- cause Microsoft chose to not support some feature that would not have taken much effort to maintain for backward compatibility. Other OSes do it, for example. It's the danger with monopolies. -- Rick C. Hodgin |
| nospam <nospam@nospam.invalid>: Jun 12 04:41PM -0400 In article <pfpaq8$g5b$2@dont-email.me>, Rick C. Hodgin > cause Microsoft chose to not support some feature that would not have > taken much effort to maintain for backward compatibility. Other OSes > do it, for example. it's up to the developers update their own apps. > It's the danger with monopolies. microsoft no longer has a monopoly. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 12 05:15PM -0400 On 6/12/2018 4:41 PM, nospam wrote: >> taken much effort to maintain for backward compatibility. Other OSes >> do it, for example. > it's up to the developers update their own apps. I categorically disagree with you. It should be up to the OS vendor to maintain backward compatibility. Those features they expressed in a prior version of their OS, for example, were relied upon by people who spent hours and months to develop software which utilizes them. For a company to then later break that functionality solely or the purposes of wanting to sell new copies of their OS ... that's about the worst kind of unethical behavior you can have toward your customers. And I consider your attitude to be ill-informed. People's labor matters. People's creativity, resourcefulness, the effort they put into their product to get it working properly and even distributed. To step forward and tell that person, and all of the other people out there like they are, that their labor does not matter and a decision is being made to ruin your product ... I don't know how you can get much worse than that in the software industry. Things don't have to lose functionality to move forward. The same software built on the 16-bit 8086 CPUs back in the late 70s will run on today's hardware if they rely on BIOS, for example, and you buy a BIOS-supporting motherboard. New functionality can be added without breaking anything old. >> It's the danger with monopolies. > microsoft no longer has a monopoly. Technically that's true, but in practice it's not. There are no competitors to the Windows operating system that run Windows software. You can use WINE and a few others that may or may not work. But for the Windows ecosystem, you're stuck with what Microsoft gives you. -- Rick C. Hodgin |
| Char Jackson <none@none.invalid>: Jun 12 04:43PM -0500 On Tue, 12 Jun 2018 13:53:26 -0400, "Rick C. Hodgin" >not recommend it for business or casual use. I have seen too many >users ready to leave for the day, or start their machine, only to >have it complete an installation that takes an hour or more. As part of my job, I interface with IT teams from many different business organizations all over the US. In my experience, business adoption of Windows 10 is very low, for all of the well-known reasons. By a large margin, I see Windows 7 in the field, and to a lesser extent Windows 8. Windows 10 is in a distant 3rd place, but probably growing. Of the organizations that have taken the plunge to Windows 10, however, something interesting keeps popping up. People whose leadership teams have mandated the use of Windows 10 are using it to their advantage. It's very well known that Win 10 requires frequent periods of downtime while the PC tends to its own activities, so users are starting to openly talk about using that as an excuse to take extended breaks. Not extended breaks from doing their work, exactly, but extended breaks where they ignore their IM and email systems. Extended breaks where they can ignore people from their management chain. When asked why they didn't reply to a time-sensitive email or why they ignored an IM, they say, "Windows 10." Everyone who uses it knows how embarrassingly awful it is, so no further questions are ever asked. Personally, I used a Windows 10 laptop for work for about a year and it would have been fine if everyone I met also used Windows 10. That way, they'd know about its issues and they'd fully understand when I'm ready to work but *it* is not. Other people running Windows 10 totally get that, and they even seem to accept it, but to the people who have stayed with the more reliable versions of Windows, the look on their faces tells all you need to know. As a result, I got permission to upgrade back to Windows 7 and all is once again well. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 12 06:22PM -0400 On 6/12/2018 5:43 PM, Char Jackson wrote: > Of the organizations that have taken the plunge to Windows 10, however, > something interesting keeps popping up. People whose leadership teams > have mandated the use of Windows 10 are using it to their advantage. We had similar discussions with Windows 8 in that managers wanted their staff using applications, not being distracted by active blocks which are shiny and animated. In my profession we have users who buy Windows 10 machines, so we have to have developmental platforms which are Win 10, Win 8, and Win 7. And We supported Win XP until Microsoft stopped releasing updates for it. I would prefer Windows 7. It's the most stable and robust OS Microsoft produced in their traditional line. > with the more reliable versions of Windows, the look on their faces > tells all you need to know. As a result, I got permission to upgrade > back to Windows 7 and all is once again well. We have a couple developers who are still on Windows 7 and do not want to upgrade. I would not have upgraded to Windows 7 except my machine hardware failed. They wouldn't repair it, so I had to get a new one and they didn't offer a Windows 7 down-grade. I tried to install one manually, but the hardware was not supported in Windows 7, so I'm stuck with Windows 10. The kernel itself is not bad. No versions of Windows have had bad kernels. It's all the layers they add on top, and specifically with Windows 8 and 10 it's the fluff and spyware they add to the system, which tracks your use and reports back to Redmond. I really wish companies would stop doing that. It's enough to sell your product and let people use it. You don't need to monitor and own their pattern of use, data, and effective lifestyle choices on the machine. That kind of intrusion is, in my honest opinion, vulgar. It is like some peeping Tom pervert watching you as you go. Such a thing should only be done under court order, and only when you are under suspicion for some crime. I truly hate Microsoft for what they do to people world-wide. And I have tried with great passion to create an alternative to their intrusion, as well as the one by Intel and their vPro out-of-band hardware-derived back doors. People don't want to rock the boat. They don't want to contribute to a hardware and software effort that seeks to do it differently, that has at its core a real purpose in focusing on end-users and their needs, even empowering them by giving away the source code for not only the kernel, drivers, and software, but also the hardware it's running. Such things should be open so people everywhere can see what they're using, and where they're able through technical know-how and prowess, step up and contribute the better thing, or the new extension. It's how we're supposed to be: people helping people to be better and do more. Business interests are completely backwards as they focus on money first, and other things well after their money con- siderations. People first. All people. And then we watch how the people use that free gift that was given to them by those who came before, and thrive in so doing. To be absolutely clear: This is a teaching effort I'm on about. We have to teach people to be this way, and demonstrate by our own efforts that we seek the same. -- Rick C. Hodgin |
| Frank Tetzel <s1445051@mail.zih.tu-dresden.de>: Jun 12 09:52AM +0200 > Here, with g++ 4.8.4 it also hashes 2047 times, > but if 'noexcept' is removed from MyHash::operator() it hashes 1024 > times. Interesting. I also asked on the gcc-help mailing list and got pointed to the following documentation: https://gcc.gnu.org/onlinedocs/libstdc++/manual/unordered_associative.html#containers.unordered.cache It is caching the hash values as erase() and swap() are not allowed to throw by the standard. So, it cannot call a potential throwing hash function and has to cash the hash values. Why it needs and generates the hash value of one element multiple times during insertion is still unclear to me. I guess, I just have to step through the code with a debugger and try to understand it. |
| Frank Tetzel <s1445051@mail.zih.tu-dresden.de>: Jun 12 09:57AM +0200 > MyHash& operator=(const MyHash&) = delete; > Good to know when you happen to have relatively slow non-throwing > hasher. ;) libstdc++ of gcc has a type trait as an extension to mark a hash function as fast or slow, but your way might also work for other STL implementations. https://gcc.gnu.org/onlinedocs/libstdc++/manual/unordered_associative.html#containers.unordered.cache |
| "ΓΓΆ Tiib" <ootiib@hot.ee>: Jun 12 01:26PM -0700 On Tuesday, 12 June 2018 10:58:20 UTC+3, Frank Tetzel wrote: > function as fast or slow, but your way might also work for other STL > implementations. > https://gcc.gnu.org/onlinedocs/libstdc++/manual/unordered_associative.html#containers.unordered.cache Exactly! The libstdc++ code that I posted nicely explained in comments that since it can't easily make assignable iterators without non-assignable hasher it picks to cache the hashes. Sure, we can use (when everything else fails) implementation-specific thing like the specialization in your link: namespace std { template<> struct __is_fast_hash<MyHash> : std::false_type { }; } That works when libstdc++ is the *only* library used. Otherwise we have to make it conditionally compiled side-by-side with similar hacks for other library implementations to avoid some cryptic noise about that "__is_fast_hash" being wrong specialization of unknown template. OTOH making hasher non-assignable is totally portable and will challenge every standard library implementation with similar issue. ;) |
| Juha Nieminen <nospam@thanks.invalid>: Jun 12 05:48AM > } > The latter, of course, can never be made correct, no matter how many unit > tests are made to pass TDD unit tests should test what the function is *specified* to do. "With this input, the function should return this value." You can write a test for that. If the function is buggy, it's under-specified. Which is a problem in most programming. The programmer simply has a vague idea of what a function ought to do, but doesn't think of edge cases, incorrect input, and so on. There's often a distinct lack of "but what if I give it this pathological input?" thinking. In the above code a unit test would specify what happens if the input is too long to fit into a double. If there's a unit test for that, then the implementation cannot simply ignore that edge case. |
| Daniel <danielaparker@gmail.com>: Jun 12 10:33AM -0700 On Tuesday, June 12, 2018 at 1:48:48 AM UTC-4, Juha Nieminen wrote: > > tests are made to pass > In the above code a unit test would specify what happens if the input is > too long to fit into a double. It's not that the input is "too long", but rather that certain sequences of digits, such as "0.1" or "0.2", don't have exact representations as doubles. It's the accumulation of these errors within the summation that can produce incorrect digits in the result. TDD people would need some insight into floating point numbers to be confident that they had sufficient test coverage, as they could easily pick tests that would fortuitously pass. But nobody with insight into floating point numbers would ever use the code shown above in the first place. I find it interesting that the three github projects (sajson, pjson, gason) actually did. Perhaps a more common case is ad hoc parsers. Lots of people write ad hoc parsers that use some regular expression checking, some substring checking, and write some tests to see that they "work", at least for correct input. But it doesn't take that much more effort to first write out the grammar in a formal notation, and then implement a simple parser to process the terms of that grammar. And you'd get a clear error message for incorrect input practically for free. Generally speaking, TDD over emphasizes the role of tests as a specification of a problem, and their simultaneous validation of that specification. Whatever heuristic value TDD offers, it's biggest claims can't be justified. Daniel |
| "π Good Guy π" <hello.world@example.com>: Jun 12 06:01PM +0100 One week from tomorrow master will closed for new libraries. Upcoming dates: * 20-Jun: Boost 1.68.0 closed for new libraries and breaking changes * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release The Boost Release Team <https://www.boost.org/> -- With over 950 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
| 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