- struct and classes always as a pointer and reference disappear... - 4 Updates
- C++ Middleware Writer - 2 Updates
- Amazon search giving me poor results - 3 Updates
- Cross-platform OpenGL-based C++ game/GUI library "neoGFX". - 2 Updates
- "Why I don't spend time with Modern C++ anymore" by Henrique Bucher - 14 Updates
| mrs@kithrup.com (Mike Stump): May 29 01:29AM In article <495c2472-67ba-4bcf-8b5e-2667c06ea74f@googlegroups.com>, >> It does not, nor, can it and call itself C++. >That is correct. May be worth to note that after C++11 we have special >non-throwing new Wow, you must be new around here. We have a special non-throwing new in C++98 as well. :-) Sorry, could not resist. |
| "Öö Tiib" <ootiib@hot.ee>: May 29 01:20AM -0700 On Sunday, 29 May 2016 04:45:11 UTC+3, Mike Stump wrote: > >non-throwing new > Wow, you must be new around here. We have a special non-throwing new > in C++98 as well. :-) Sorry, could not resist. No problem. :-) I have typed 'new' into C++ code on very limited occasions lately. That "lately" has lasted for more than decade. Same is with raw pointers. Naked 'new' feels like dangerous half-operation and raw pointer like unprotected memory address. Code with lot of 'new's looks like written in some low level language ... possibly Java or C#. Downside of it is that apparently I start to forget trivia about 'new'. |
| Rosario19 <Ros@invalid.invalid>: May 29 11:36PM +0200 On Sun, 29 May 2016 01:20:57 -0700 (PDT), 嘱 Tiib wrote: >> 嘱 Tiib <ootiib@hot.ee> wrote: >> >> >and if the system has no memory what return "new"? >> >> >i think return 0 to p... the just above line is my even if it is wrong... etc |
| "Öö Tiib" <ootiib@hot.ee>: May 29 04:03PM -0700 On Monday, 30 May 2016 00:37:02 UTC+3, Rosario19 wrote: > >> >> >i think return 0 to p... > the just above line is my > even if it is wrong... etc Yes I know, it was Mike Stump who cut attributions, I just replied to his post (and did not bother to restore the attributions he cut). |
| woodbrian77@gmail.com: May 29 09:56AM -0700 On Tuesday, May 24, 2016 at 2:57:19 PM UTC-5, Chris Vine wrote: > messages about his faith (and off topic messages about other things > as well) which annoy people on the one hand, and raising pathetic > points about bad language which no one else objects to on the other. Are those who prefer anything goes here the same people who support boost::any being added to the standard? IMO adding "any" to the standard was another mistake. I'd like to see it removed. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: May 29 03:56PM -0700 > Are those who prefer anything goes here the same > people who support boost::any being added to the > standard? I do not understand why and how you mix up and conflate so different things. If people bother to write that they are annoyed by you then they likely are. So ... it is not "anything goes". > IMO adding "any" to the standard was > another mistake. I'd like to see it removed. I will certainly hate it if there will be that 'any' but 'variant', 'optional' and/or 'none_t' will be missing. |
| woodbrian77@gmail.com: May 29 11:18AM -0700 I was looking for C++ books on Amazon.com and so that's all I typed in -- C++. The results are some C++ titles, but many titles that I'm not interested in. For example: Effective C# (Covers C# 6.0): 50 Specific Ways to Improve Your C# Developing SPAs: Working with Visual Studio 2015, AngularJS, and ASP.NET Web API Programming C# 6.0: Create Windows Desktop and Web Applications Mastering Azure Analytics: Architecting in the Cloud with Azure Data Lake, HDInsight, and Spark Programming for the Internet of Things: Using Windows 10 IoT Core and Azure IoT Suite Programming Microsoft Office 365 Oy vey. Is there some trick to get Amazon search to be useful? TIA. Brian Ebenezer Enterprises - Making programming fun again. http://webEbenezer.net |
| woodbrian77@gmail.com: May 29 11:33AM -0700 > I was looking for C++ books on Amazon.com and so that's > all I typed in -- C++. I also sorted by publication date. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 29 02:13PM -0700 Try: +"C++" -"C#" Or on Google.com: site:amazon.com +"C++" -"C#" Best regards, Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 29 07:00PM +0100 Hi, Here is the latest screenshot (red) of my OpenGL-based C++ game/GUI library "neoGFX" (coming soon): http://neogfx.org/temp/red.png Source code can be perused at https://github.com/FlibbleMr/neogfx neoGFX is probably about 60% complete at this stage. /Flibble |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 29 02:10PM -0700 Awesome. Best regards, Rick C. Hodgin |
| Ian Collins <ian-news@hotmail.com>: May 29 11:58AM +1200 On 05/29/16 12:38 AM, Jerry Stuckle wrote: >> http://datacenterfrontier.com/facebook-open-compute-hardware-next-level/ > Nice ability to Google. Now try some *reliable* references. Then ask > some of those big companies why they use big iron. So a post by Facebook discussing their own hardware isn't reliable? -- Ian |
| Jerry Stuckle <jstucklex@attglobal.net>: May 28 08:22PM -0400 On 5/28/2016 11:24 AM, David Brown wrote: > the mainframe world). A solid SSD will give you something like 0.5 GB > per second. So reading /all/ of those files is 15 seconds - at that is > if you don't want to splash out on a couple of disks in a raid system. That shows how little you know. There are many programs in the mainframe world which are much bigger. But you've never seen one, so you think they don't exist. But then all of those files in the Debian repository are pretty much separate. They aren't linked into one huge program (or a few very large programs), are they? > The disk speed is pretty much totally irrelevant in large compile times > (unless you are using a poor OS that has slow file access and bad > caching systems, like Windows - though Win8 is rumoured to be better). Wrong again. I/O speed is quite critical. But you think Debian is the end-all of programs. It isn't. > number of lines of code /compiled/. You only need to read these > multi-MB header files once, but you need to compile them repeatedly. > Thus processor and memory is the issue, not disk speed. Number of lines of compiled code is only part of the issue. > or 18 GB with link-time optimisation (which requires holding much more > in memory at a time). > The idea that you would need a TB or more of ram is just silly. No, Libreoffice is an example of a small to medium sized program. Its' not large at all. But I'm sure it's much bigger than anything you've ever worked on. > issue - in most cases, the code is written by a single person, for a > single purpose on a small embedded system. But sometimes I also have to > compile big code bases for other systems.) I am not going to name any names because they are (or have been) my clients. And those are none of your business. And if you want large code base - I know of at least one which has several hundred programmers working for 3 years just on one version. And they are busy writing code - not drinking coffee. This is what large programs look like. > telling me that they pick Dell servers over Z-Series because of Dell's > excellent reliability record? > Or could it be that you are simply talking nonsense again? I'm saying that every one of your "reasons" is pure hogwash. If you think mainframes are more secure than your xeon systems, than you don't know how to properly implement your xeon systems. And I guess your systems aren't very reliable, either. You've just told me a lot about why people don't want to buy your systems. They want ones designed by competent people. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 28 08:26PM -0400 On 5/28/2016 12:24 PM, David Brown wrote: > <http://www.businessinsider.com/facebook-open-compute-project-history-2015-6?op=1%3fr=US&IR=T&IR=T> > <http://arstechnica.com/information-technology/2013/07/how-facebook-is-killing-the-hardware-business-as-we-know-it/> None of which provide support for your claims. Nice try. > Why not ask IBM, since they have something like 90% of the mainframe > market? > <https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zmainframe/zconc_whousesmf.htm> I don't need to. I worked for IBM for 13 years - the first 5 being in mainframe hardware and the last 8 in mainframe software. During that time I worked with hundreds of IBM mainframe customers. I think I know them pretty well. But then I wouldn't expect an IBM site to be promoting Dell computers. > as "hogwash". > And I don't see "build server" or "compilation of large C++ programs" on > IBM's list. Sure - they're going to promote short lifetimes, no reliability and all the rest? ROFLMAO! Now you've even gone beyond stoopid. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 28 08:27PM -0400 On 5/28/2016 7:58 PM, Ian Collins wrote: >> Nice ability to Google. Now try some *reliable* references. Then ask >> some of those big companies why they use big iron. > So a post by Facebook discussing their own hardware isn't reliable? How unbiased do you think it is? How stoopid are you? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: May 29 12:56PM +1200 On 05/29/16 12:27 PM, Jerry Stuckle wrote: >>> some of those big companies why they use big iron. >> So a post by Facebook discussing their own hardware isn't reliable? > How unbiased do you think it is? So you now claim that Facebook (and by association the likes of Intel, Microsoft and Google) are lying about an open project? -- Ian |
| mrs@kithrup.com (Mike Stump): May 29 01:38AM In article <niahja$m2$1@dont-email.me>, >where all the features of C++ could be maintained (and many more added!) >if we open the language and let people program the compiler itself. >I will publish soon a document explaining this in detail. Sounds fun. I think it would be nice to have a C/C++ successor where more of the features of languages like C and C++ were instead in the library of the new language. That way, people could evolve the language merely by having people select what libraries they wanted to use and refining and extending those libraries. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 28 09:47PM -0400 On 5/28/2016 8:56 PM, Ian Collins wrote: >> How unbiased do you think it is? > So you now claim that Facebook (and by association the likes of Intel, > Microsoft and Google) are lying about an open project? I said they are biased - not lying. But you're obviously too stoopid to understand the difference. About what I would expect, however. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: May 29 02:07PM +1200 On 05/29/16 01:38 PM, Mike Stump wrote: > library of the new language. That way, people could evolve the > language merely by having people select what libraries they wanted to > use and refining and extending those libraries. Maybe they could call them boost? -- Ian |
| "Öö Tiib" <ootiib@hot.ee>: May 29 03:20AM -0700 On Saturday, 28 May 2016 01:30:40 UTC+3, jacobnavia wrote: > where all the features of C++ could be maintained (and many more added!) > if we open the language and let people program the compiler itself. > I will publish soon a document explaining this in detail. Very interesting. With C++ it is actually quite easy to create other languages. Operator overloading, custom literals, templates and preprocessor macros result with very lot of semantic freedom. It is perhaps more important to ask why such things have still only reached quite limited or questionable success. IMHO (YMMV) it is because the mutated code is still compiled on C++ compiler. What it means "compiled"? Lot of attempts to compile (possibly majority of) result with compiler finding something strange in code (or even a reason to reject it totally) and to give diagnostics. With those all immersion is replaced with headache. All useful abstractions do leak. The C++ compiler does not know abstract context of that "leaner language". It is powerful, compile-time Turing-complete compiler. Therefore it spits out gibberish in C++ terms about how it did recursively evaluate it and how it went well for pages and pages and how it failed in some odd meta-programming trick somewhere that user of the "leaner language" is supposed to know nothing about. Do you have ideas how to mitigate that effect? |
| David Brown <david.brown@hesbynett.no>: May 29 01:14PM +0200 On 29/05/16 02:22, Jerry Stuckle wrote: > But then all of those files in the Debian repository are pretty much > separate. They aren't linked into one huge program (or a few very large > programs), are they? Do you really expect anyone to believe that in the mainframe world there are many monolithic (or near monolithic) programs, written in C++, with much more than 1,100,000,000 lines of code? I'd ask for links or references, but I know I'll never see any. >> caching systems, like Windows - though Win8 is rumoured to be better). > Wrong again. I/O speed is quite critical. But you think Debian is the > end-all of programs. It isn't. I just know how compilers work, and what their tasks are. >> multi-MB header files once, but you need to compile them repeatedly. >> Thus processor and memory is the issue, not disk speed. > Number of lines of compiled code is only part of the issue. Certainly it is only part of it, but it is often a reasonable indication - much of the time-consuming tasks of compilation are correlated with the amount of code compiled. > No, Libreoffice is an example of a small to medium sized program. Its' > not large at all. But I'm sure it's much bigger than anything you've > ever worked on. Yes, Libreoffice is much bigger than anything I have worked on. And no, it is not a "small to medium sized program". It is a /big/ program. That does not mean that there are not bigger programs - it means that the vast majority of programs written are very much smaller. And because it is a popular program and an open source program, mostly in C++, it is relatively easy to find information about compilation resources. >> compile big code bases for other systems.) > I am not going to name any names because they are (or have been) my > clients. And those are none of your business. Ah, we should just take your word for it, since you have such a fantastic reputation for honesty. > And if you want large code base - I know of at least one which has > several hundred programmers working for 3 years just on one version. Programmer man-years does not equate to code size. There are projects where people write a thousand lines a day, and projects where people write an average of a few lines a week. > And they are busy writing code - not drinking coffee. This is what > large programs look like. And these folks are all generating hundreds of lines of C++ code per day, every day, for years, all part of the same monolithic program that must be recompiled as a /single/ linked executable program? Because that's what's needed to get anything like what you have been claiming - assuming, of course, that this is merely a new version that builds on an existing code base several times as large. > systems aren't very reliable, either. > You've just told me a lot about why people don't want to buy your > systems. They want ones designed by competent people. You don't have the faintest idea of who I am, what I do for a living, what my company produces, what part I play in that, who our customers are, what they are looking for in their purchases, or anything else about me. The only things you know are the things I have said - such as that I mainly write code for small embedded systems. Yet somehow you can conclude that I make insecure and unreliable xeon systems that people don't want to buy. Is there no end to the drivel you can invent? And just for your example, I actually think that it is perfectly possible to make xeon (or any other cpu) based systems that are as secure as a mainframe, when dealing with appropriate tasks - security is a process that depends on the tasks and the threats. But the question at hand was not whether /I/ could make a secure x86 server, or indeed whether mainframes are or are not inherently more secure than x86 servers. The question was why people choose mainframes, and one of the reasons is that some people /believe/ that mainframes are inherently more secure than x86 servers. It matters not if that belief is true or not. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 29 09:59AM -0400 On 5/29/2016 7:14 AM, David Brown wrote: > are many monolithic (or near monolithic) programs, written in C++, with > much more than 1,100,000,000 lines of code? > I'd ask for links or references, but I know I'll never see any. I really don't care what you believe. You've already proven you are not only stoopid, but unwilling to learn anything that violates your "truth". Here are some real truths. Lines of code is not the only measurement of complexity. Lines of code does not a good way to predict compilation time. Lines of code is a measurement used by those who don't know better. And no, not even Debian has over 1,100,000,000 lines of COMPILEABLE CODE. >> Wrong again. I/O speed is quite critical. But you think Debian is the >> end-all of programs. It isn't. > I just know how compilers work, and what their tasks are. You only THINK you know how compilers work. That is obvious. You need to look at how the hardware works, also. > Certainly it is only part of it, but it is often a reasonable indication > - much of the time-consuming tasks of compilation are correlated with > the amount of code compiled. It is only reasonable to those who don't know better. > it is not a "small to medium sized program". It is a /big/ program. > That does not mean that there are not bigger programs - it means that > the vast majority of programs written are very much smaller. Wrong again. In the mainframe world, it would barely be considered a pimple on your arse. Number of programs bigger or smaller is not a measure of size. But once again you show your stoopidity. Libreoffice is 21 MB in 20 files (at least on the Windows system I'm using now) and another 21MB in DLLs. Doesn't even rate a medium sized program. Although I suspect "Hello World" is a "big program" for you. > And because it is a popular program and an open source program, mostly > in C++, it is relatively easy to find information about compilation > resources. So? >> clients. And those are none of your business. > Ah, we should just take your word for it, since you have such a > fantastic reputation for honesty. No, I'm not going to give you names of my clients. And I really don't care what an idiot like you thinks about my reputation. > Programmer man-years does not equate to code size. There are projects > where people write a thousand lines a day, and projects where people > write an average of a few lines a week. And in the mainframe world, someone only writing a few lines a week would not be employed for long. Maybe that's why you can't find a job. > that's what's needed to get anything like what you have been claiming - > assuming, of course, that this is merely a new version that builds on an > existing code base several times as large. C and C++, yes. And most of it does go into a single program, although it does load various parts of itself when it start. > are, what they are looking for in their purchases, or anything else > about me. The only things you know are the things I have said - such as > that I mainly write code for small embedded systems. I know what you DON'T do for a living - you don't program. Most likely the closest you come to programming is emptying wastebaskets of programmers. > Yet somehow you can conclude that I make insecure and unreliable xeon > systems that people don't want to buy. Is there no end to the drivel > you can invent? Just going by your comments here. They say much more than your claims. > reasons is that some people /believe/ that mainframes are inherently > more secure than x86 servers. It matters not if that belief is true or > not. You made the claim. I just followed it to the logical conclusion. And now you're trying to backpedal as fast as you can. ROFLMAO! Just another example of your incompetence, David. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 29 04:57PM +0200 On 29.05.2016 13:14, David Brown wrote: > are, what they are looking for in their purchases, or anything else > about me. The only things you know are the things I have said - such as > that I mainly write code for small embedded systems. I'm not sure but I think I interviewed with you once, after sending just a silly short e-mail application. It looked like I would get the job and I maybe panicked, I don't know. Anyway I interrupted the interviewer (you?) as he was telling me how good impression I'd made, and his face fell flat, and I didn't get the job. :) Is there by any chance a new Eastern connection to your company? Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: May 29 05:23PM +0200 On 29/05/16 15:59, Jerry Stuckle wrote: > only stoopid, but unwilling to learn anything that violates your "truth". > Here are some real truths. > Lines of code is not the only measurement of complexity. I agree entirely - but it is a good measure of "big". You are the one keen to claim that mainframe programs are so much bigger than anything else. > Lines of code does not a good way to predict compilation time. Lines of code /is/ a good way to predict compilation time, but it is not the only factor. In particular, lines of code /compiled/ is more important than lines of code in total in the sources. And some code is more complex than others, and of course there are many other factors. You might have noticed that I have already mentioned this. > Lines of code is a measurement used by those who don't know better. It is a measurement used by many people, and perhaps /misused/ by people who don't know better. But since you are keen on the "size" of code bases, and keen to demonstrate that "many" mainframe programs are "much bigger" than - for example - the entire Debian source base, then lines of code is an excellent measurement. We could also use total disk space, which might be more accurate (especially for answering the question "how much ram do we need to hold it all in memory") if we had numbers conveniently available. However, the disk usage given in my reference below also includes non-compilable files, such as graphics resources. > And no, not even Debian has over 1,100,000,000 lines of COMPILEABLE CODE. My reference, which I really hope you will view as reliable and accurate, is: <https://sources.debian.net/stats/> Sid, the testing/development repository, currently has 1,139,708,723 lines of source code. That covers a number of different programming languages, and code in Perl, Python, or Bash will not be compilable. You can see figures further down that page detailing the breakdown by language - approximately 445 MLoC of C, and 290 MLoC of C++. But I am not fussy about the exact numbers - I am just giving "Debian" as an example project with an enormous code base, for which figures are openly available. And I would like references or links showing some indication for your claim that /many/ mainframe /programs/ are /much/ bigger than 1.1 GLoC. Note that your claim was for "one or a few huge programs" - unlike the Debian code, which is obviously spread across a great many programs. >> I just know how compilers work, and what their tasks are. > You only THINK you know how compilers work. That is obvious. You need > to look at how the hardware works, also. I also know how a lot of hardware works. I don't know details of mainframes, but I have a fair understanding of the principles. (The details are hard, but the principles are not.) But since I know that during compilation, I/O speed is not critical, it does not matter how fast the I/O speed is on your build machine as long as it can get files on and off the disk fast enough to keep the processors busy. > again you show your stoopidity. Libreoffice is 21 MB in 20 files (at > least on the Windows system I'm using now) and another 21MB in DLLs. > Doesn't even rate a medium sized program. When someone qualified and believable tells me something about code sizes in the mainframe world, I'll believe them. But your claims, with the total lack of any kind of links or references, are not worth the pixels they are written on. >> fantastic reputation for honesty. > No, I'm not going to give you names of my clients. And I really don't > care what an idiot like you thinks about my reputation. It is quite obvious that you don't care what /anyone/ thinks of your reputation here in Usenet. >> write an average of a few lines a week. > And in the mainframe world, someone only writing a few lines a week > would not be employed for long. Maybe that's why you can't find a job. People who write a few lines of code a week do not work on mainframes. > You made the claim. I just followed it to the logical conclusion. And > now you're trying to backpedal as fast as you can. ROFLMAO! > Just another example of your incompetence, David. Well, I am glad you find these threads funny. However, I think your entertainment value as the class clown is running low. Poking you and watching the ensuing nonsense tumble out is fun for a while, but we all reach a point where it gets too silly. It is important, I think, that we make it clear that your posts and claims are mostly completely spurious and have no backing in reality, in case any innocent viewers of these threads (now or in the future) mistakenly believe you. But I think that is already achieved. You have insulted and ridiculed just about every single person who has disagreed with you in c.l.c and c.l.c++, though others have presented references, quotations from standards, logical reasoning, sample code, etc., clearly demonstrating that you manage to get just about everything wrong. I wonder why you ever bother posting in these newsgroups at all. Did you get kicked out of your mythical private discussion groups of "real" programmers? |
| David Brown <david.brown@hesbynett.no>: May 29 09:39PM +0200 On 29/05/16 16:57, Alf P. Steinbach wrote: > I maybe panicked, I don't know. Anyway I interrupted the interviewer > (you?) as he was telling me how good impression I'd made, and his face > fell flat, and I didn't get the job. :) I don't think that was me, though I am involved in technical interviews of candidates. I've emailed you offline with details. mvh., David |
| 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