- Are there any asm-instructions to support OOP - 5 Updates
- Preprocessor output into Class processor - 1 Update
- Does std::regex need to be so large? - 1 Update
| "daniel...@gmail.com" <danielaparker@gmail.com>: Aug 28 05:28PM -0700 On Friday, August 28, 2020 at 3:04:22 PM UTC-4, Jean-Marc Bourguet wrote: > That's for sure the place where most of last 20 years evolution of C++ is > taking place. And I said most to be prudent, I'm unable to think of one > improvement related to object oriented programming. Well, there's the final specifier and the override specifier introduced with C++ 11. And modern compilers do a very good job of devirtualizing when possible. In a significant number of cases there is no cost to a polymorphic structure versus the alternatives. And then there's std::pmr::polymorphic_allocator, which makes using stateful allocators much simpler. Daniel |
| boltar@nuttyella.co.uk: Aug 29 02:37PM On Fri, 28 Aug 2020 17:17:16 +0200 >long as hi-end audio suppliers and customers are honest about this, and >don't pretend the sound is quantitatively "better", there's nothing >wrong or "phoolish" about it. Depends how much money they are spending. Anyone who spents 5 figure numbers on say an amplifier because it has "warmth" from a bunch of valves and large heat sinks IMO is a fool. But then I tend to think the same about guys who blow a fortune on a lambo or ferrari so each to their own. >that exists primarily for money laundering. The process goes like this. > A drug baron in, for example, Mexico, sends packets of drugs into the >USA by plane drop. The American distributor picks it up, and sells it. I'll take your word for this, I've never heard about it. Certainly a clever way to do it. >judging. You clearly know little of the high-end gaming world, and the >high-end audio world, and know little of either. You're right, I know little about the high end gaming world , but you're wrong about the audio side. I've been into audio since I was a teenager, not only hifi but musics sythesizers too so Ihave a pretty good idea whats what. |
| boltar@nuttyella.co.uk: Aug 29 02:45PM On Fri, 28 Aug 2020 16:23:49 +0000 (UTC) >> artifact of H264 because SD streams just used to break up into blocks. >You are making stuff up as you go, aren't you? >What will you conjure up next? LOL :) Says the man who posted this with a straight face: "Next time you are watching a movie, pay attention to when the camera eg. pans slowly horizontally, and notice how the movement is done in quite noticeable little jumps, rather than being completely smooth." Err no, thats nothing to do with the frame rate you div. A constant frame rate doesn't produce noticably jerky motion unless the film is from the 1920s. The jerkiness is down to the digital codec and if you'd ever watched 24fps films filmed and replayed on 35mm you'd understand this but I guess you're too young. Google "H264 jerky" if you don't believe me. Or don't , I couldn't care less. |
| David Brown <david.brown@hesbynett.no>: Aug 29 07:31PM +0200 On 28/08/2020 17:32, Stephen Fuld wrote: > distributor pays for the cables in cash, doesn't the cable manufacturer > have the same problem of either making large cash deposits to his bank, > or transferring them across borders as the the distributor would have? I have only heard of this in America, where large bundles of cash apparently don't cause the same concern to the authorities as they would in many places in Europe. Anyway, it would be the drug reseller in the USA who has the bundles of cash, and spends it in the hi-fi shop. The hi-fi is a legitimate business, and has no (apparent) direct connection to the criminals. As far as the shop is concerned - and as far as the shop's bank is concerned - they buy ridiculously expensive cables from a supplier in Mexico. They add a markup, and sell them to customers in the USA - who are legally entitled to pay by cash if they want. When the shop buys cables from the manufacturer in Mexico, it can use normal international bank transfers, because all the money is now "clean". |
| Juha Nieminen <nospam@thanks.invalid>: Aug 29 06:48PM > pans slowly horizontally, and notice how the movement is done in quite > noticeable little jumps, rather than being completely smooth." > Err no, thats nothing to do with the frame rate you div. What do you mean? Of course it has everything to do with framerate. Suppose you only show every 24th frame of the movie at 1-second intervals. Which means the movie is now 1 Hz. Rather obviously you will see huge jumps every second, when the camera pans horizontally. The same goes for 2 Hz, just twice as often, and 4 Hz, and 10 Hz etc. At 24 Hz it starts being a lot less noticeable, but if you pay close attention to it, you can still see the jumps, how the movement is not completely smooth, but makes these little jumps at very frequent intervals. Compare that to eg, the same movie being filmed and shown at 60 Hz. Now it's practically impossible to see any jumps and it will look extremely smooth. Just because you don't believe and/or understand it doesn't mean it's not true. Just try it for yourself. > Or don't , I couldn't care less. Rather obviously you care a lot, given that you can't stop responding. |
| David Brown <david.brown@hesbynett.no>: Aug 29 07:24PM +0200 On 28/08/2020 18:14, Frederick Gotham wrote: > microcontrollers with less than a megibyte of RAM/ROM that don't have > a C++ compiler. My new preprocessor will make it a lot easier to port > C++ code with polymorphic classes to C. Code that is written in C++ with polymorphic classes will not be suitable for such small microcontrollers in the first place. So there is no benefit from an easier way to port the code - if the code in C++ is too demanding, then the whole code structure of the source is too demanding for the target. Either the code needs re-written from scratch in C, or the user needs a bigger microcontroller (there are 32-bit devices for less than half a dollar - there are rarely good reasons for starting new projects with brain-dead 8-bit CISC microcontrollers. The prime reason for using them is to continue and expand on existing designs, in which case software in a new language is out of the question). And note that people use C++ on 8-bit devices already, if the device is reasonably flexible (such as AVR's, rather than PIC's, 8051's, COP8's, and that kind of device). If you think your project will be fun, great. |
| boltar@nuttyella.co.uk: Aug 29 02:51PM On Fri, 28 Aug 2020 16:14:39 +0000 (UTC) >> You think a 486 couldn't do 60hz? >Not at 1920x1080 32-bit color, no. >Maybe at 0.1 Hz. If even that. You'd be surprised what a 486 could do when programmed properly. I had 640x400, 16 bit full motion video running on mine back in the 90s with a humble Matrox Millenium video card. And plenty of early setop TV boxes actually ran a CPU core much less powerful, albeit with hardware decoding. >> Anyway, so what? The point still stands >> that similar graphics >You have a strange definition of "similar". Similar type of demo. >illumination, dynamic shadows and volumetric lighting on a NES... >at 1x1 resolution 2 colors. Clearly the NES is as powerful at >graphics as modern PCs. Now you're just being stupid. My point was that rather humble demo of how supposedly good web assembly is was nothing of the sort. |
| 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