Sent from my iPad
Sent from my iPad
Begin forwarded message:
From: Sharon Kahn <sharon62kahn@gmail.com>
Date: May 25, 2016 at 8:17:41 AM CDT
Subject: Fwd: 入围奥斯卡最佳短片的宋代画风动画片
Tuesday, May 31, 2016
Fwd: 入围奥斯卡最佳短片的宋代画风动画片
Sent from my iPad
Sent from my iPad
Begin forwarded message:
Digest for comp.lang.c++@googlegroups.com - 22 updates in 3 topics
| JiiPee <no@notvalid.com>: May 31 01:50AM +0100 On 30/05/2016 23:43, JiiPee wrote: > or C++11/14. But I think there is an essential difference as C++11 is > much safer etc. So your code becomes less risky with better language, > I think. So it does matter, at least somewhat. dont we agree that its the old: "the right tool for the right job"? sometimes is VB sometimes C++. And, There is also this personal preference issue: I personally could not imagine creating a complex game library with VB, ... at least for me it matters. But maybe for somebody else VB would be better. People are different... some languages are better for my thinking than others I think. |
| JiiPee <no@notvalid.com>: May 31 01:58AM +0100 On 30/05/2016 15:29, Jerry Stuckle wrote: >> --- news://freenews.netfront.net/ - complaints: news@netfront.net --- > Nope, just when they are trolling. Like yours here. > But I know I'm trying to teach the pig to sing. what am trying to say, that there might be other factors which are more important than "getting a faster compiler". like these: http://stackoverflow.com/questions/1073384/what-strategies-have-you-used-to-improve-build-times-on-large-projects 1. Forward declaration 2. pimpl idiom 3. Precompiled headers 4. Parallel compilation (e.g. MPCL add-in for Visual Studio). 5. Distributed compilation (e.g. Incredibuild for Visual Studio). 6. Incremental build 7. Split build in several "projects" so not compile all the code if not needed. how about consentrating on those? its possible they shortens the compilation time much much more than changing languages or compilers. |
| mrs@kithrup.com (Mike Stump): May 31 01:18AM In article <nihk25$j8p$1@jstuckle.eternal-september.org>, >> Some indefinite mysterious "factors"? >Code complexity is the main one. In languages like C++, template >complexity and instantiation is another one. Very true, meta programming, either by cpp usage or templates does have a way of expanding compile times. Additionally, headers for C++ tend to inflate compile times faster than plain C. It is hoped for C++ that modules can help improve compile times here; only time will tell if they do. http://clang.llvm.org/docs/Modules.html for the interested. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 09:42PM -0400 On 5/30/2016 6:43 PM, JiiPee wrote: > everything... they have limited budject I think. so they chose what is > more important and how many it affects. Thats how the C++ commitea also > thinks I know. You seem to be repeatedly disagreeing. And if you don't disagree, why even bring it up? > or C++11/14. But I think there is an essential difference as C++11 is > much safer etc. So your code becomes less risky with better language, I > think. So it does matter, at least somewhat. I said nothing about C++11, C++14 or any other version. It's just another of your red herrings. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 09:42PM -0400 On 5/30/2016 8:50 PM, JiiPee wrote: > not imagine creating a complex game library with VB, ... at least for me > it matters. But maybe for somebody else VB would be better. People are > different... some languages are better for my thinking than others I think. Which is another of your red herrings. None of this has anything to do with compile time for C++ programs. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 09:47PM -0400 On 5/30/2016 8:58 PM, JiiPee wrote: > what am trying to say, that there might be other factors which are more > important than "getting a faster compiler". like these: > http://stackoverflow.com/questions/1073384/what-strategies-have-you-used-to-improve-build-times-on-large-projects No, let's be honest. What you're trying to say is the just because compile times are not important to YOU they are not important to anyone else. Everything else is red herrings. > needed. > how about consentrating on those? its possible they shortens the > compilation time much much more than changing languages or compilers. They can, when applied properly. But most programmers use as many of these as possible already. And we still have problems with compile time. Intelligent programmers do not compile every module every time. We use make files or equivalent, for instance. We use compiled headers where possible. In many cases parallel compilation doesn't offer significant advantages, and distributed compilation has it's own problems - like spending big bucks on multiple computers just to compile. Every argument you have brought up is pure horse hockey. You're better off just admitting that there are many programmers in this world who work on complicated programs and do have compile time problems. The fact you don't is really immaterial to the rest of the world. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| jacobnavia <jacob@jacob.remcomp.fr>: May 31 10:30AM +0200 Le 29/05/2016 à 12:20, Öö Tiib a écrit : > 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? Errors If an error occurs when compiling the template to be executed in the compiler environment an error message is issued with line/reason of the error. That is why is better to use precompiled binaries to associate the compile time function to an event. That means faster compile times since the compiler has less work to do: just load that function. If an error occurs when compiling the generated code, the error message can only be Error when compiling code generated by the "xxx" compile time function. If the generated code contains lines (and it is not only a huge expression in a single line), a line number is given relative to the start of the generated code |
| "Öö Tiib" <ootiib@hot.ee>: May 31 05:29AM -0700 On Tuesday, 31 May 2016 11:30:33 UTC+3, jacobnavia wrote: > error. That is why is better to use precompiled binaries to associate > the compile time function to an event. That means faster compile times > since the compiler has less work to do: just load that function. The problem is not so much about compile time but relevance of information contained in produced error messages. For example "syntax error at line 42" is too few information for me. I will stare at the line 42 in confusion for a while. For another example 40 pages of log of how compiler got stuck after pile of expanding (not written by me) macros, deducting arguments of (never before seen by me) templates of trait classes and resolving ambiguity between overloads (again not by me) is too lot of information for me. I will also stare at the line I wrote that caused it all in confusion for a while. The 'static_assert' is tricky to put to some places and when the condition is complex then it makes compilation slower too. > If the generated code contains lines (and it is not only a huge > expression in a single line), a line number is given relative to the > start of the generated code I do not understand the meaning of above sentences. Somehow those feel partial expressions. There may be something obvious that I miss. Can you please try to say same in some other words? |
| JiiPee <no@notvalid.com>: May 30 08:08PM +0100 On 30/05/2016 15:28, Jerry Stuckle wrote: > compiling is lost productivity. > And I never said it was a problem for *all* C++ programmers. But *YOU* > said it was not a problem for ANY C++ programmers. I guess one question is that how many percentage faster other languages compile the same project (done with same structures)? Also , I do not think we should only think on factor (how quickly is compiled). We should take into consideration ALL factors, like how good the langauge is... how long it takes to develop the code, how easy is to maintain the code etc etc. Compiling is only on factor in regards to things taking time. How much faster other languages compile the same project? |
| jacobnavia <jacob@jacob.remcomp.fr>: May 31 02:52PM +0200 Le 31/05/2016 à 14:29, Öö Tiib a écrit : > I do not understand the meaning of above sentences. Somehow those feel > partial expressions. There may be something obvious that I miss. Can you please > try to say same in some other words? The compiler produces a stream of lexical events: Start program, end program, start function, end function, etc. You can tell the compiler to call a function that you have written at any event generated by the compiler. That function can generate either binary data or C code, like templates do. There are several possibilities of errors: If you associate a function source code with some event, the compiler will compile that function in the fly, and execute it within the compiler environment. There can be errors in the source code of the function so that it is not loaded. In that case the compiler will tell you the reason and the source code line where the error is detected. Now, if that function generates code in the form of C code (say), errors can occur when compiling that generated code because an error in the generated C. That corresponds to an error when instatiating a template. Note that even if there are superficial similarities between what I propose and what exists now in the form of templates, there are vast differences. Since you can examine all the compiler environment, you can implement the "concepts" idea of Bjarne very easily: you can check the types of any variable or function, etc, and see immediately if it corrseponds to the types you want to support. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 06:21PM -0400 On 5/30/2016 3:08 PM, JiiPee wrote: > maintain the code etc etc. Compiling is only on factor in regards to > things taking time. > How much faster other languages compile the same project? It makes no difference what other languages do. They are not being used. And yes, compiling is one factor. But it is an important one because it is wasted programmer time. How good the language is is pretty unimportant, also. What IS important is how good the programmer is. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: May 30 11:43PM +0100 On 30/05/2016 23:21, Jerry Stuckle wrote: > It makes no difference what other languages do. They are not being > used. And yes, compiling is one factor. But it is an important one > because it is wasted programmer time. I dont think nobody disagrees. But as I said, Microsoft cannot do everything... they have limited budject I think. so they chose what is more important and how many it affects. Thats how the C++ commitea also thinks I know. > How good the language is is pretty unimportant, also. What IS important > is how good the programmer is. in a way true. but on the other hand, if your statement is the only truth, then that would mean that it does not matter if we use 90 s C++ or C++11/14. But I think there is an essential difference as C++11 is much safer etc. So your code becomes less risky with better language, I think. So it does matter, at least somewhat. |
| scott@slp53.sl.home (Scott Lurndal): May 31 02:24PM >> Line rate, of course. Our customers would not purchase them otherwise. >That's not answering the question. No network operates at the >theoretical maximum speed except for possibly short bursts.\ The controllers will run at 40Gbps, which is line rate. And yes, there are networks that operate at much faster than 40Gbps. >> As does the 2x 40Gbps + 16 6Gbps SATA, even leaving out the PCIe. >Wrong, 16 SATA cannot concurrently access memory, much less along with >the network and PCIe. You obviously have no clue as to what you're talking about. We've designed the SoC to maintain full bandwidth on all external ports, and we've tested that it does so. There's a nice crossbar switch with sufficient bisectional bandwidth to support 48 cores and the aforementioned I/O devices concurrently. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 31 12:31PM -0400 On 5/31/2016 10:24 AM, Scott Lurndal wrote: >> That's not answering the question. No network operates at the >> theoretical maximum speed except for possibly short bursts.\ > The controllers will run at 40Gbps, which is line rate. Continuously? And you expect me to believe that? Unlike you, I am not an idiot. I actually *understand* data transfer. > And yes, there are networks that operate at much faster than > 40Gbps. And exactly where are those speeds? Considering a single fiber can handle 10GBS, and even then they don't claim continuous data transfer at that rate. > we've tested that it does so. There's a nice crossbar switch with > sufficient bisectional bandwidth to support 48 cores and the aforementioned > I/O devices concurrently. Oh, I know EXACTLY what I'm talking about. And 16 SATAs cannot transfer data concurrently at full speed. But then now I understand why your systems are less secure and less reliable than mainframes. Smart people know you're statements are full of crap - and don't believe anything else you say about your systems, either. They go elsewhere where people don't try to bullshit them. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| scott@slp53.sl.home (Scott Lurndal): May 31 05:12PM >And exactly where are those speeds? Considering a single fiber can >handle 10GBS, and even then they don't claim continuous data transfer at >that rate. https://en.wikipedia.org/wiki/100_Gigabit_Ethernet#100G_Port_Types |
| JiiPee <no@notvalid.com>: May 31 07:08PM +0100 On 25/05/2016 09:09, Juha Nieminen wrote: > language. It would be one of the silliest possible reasons to change > the entire programming language to something completely different and > incompatible. I kind of agree here. Me also, I have worked in software company and also done other projects 25 years and compilation has not been major problem never. Was a bit slow in 90 s but today its not slow with the same (kind of) projects as the computers are very fast. the point again: for most of the programmers, lets say > 95% , its not an issue at all. maybe even 99%, donno.... > be telling others to change their language because *you* have to > work with such codebases. It's not a problem that affects > everybody. exactly. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 31 03:24PM -0400 On 5/31/2016 1:12 PM, Scott Lurndal wrote: >> handle 10GBS, and even then they don't claim continuous data transfer at >> that rate. > https://en.wikipedia.org/wiki/100_Gigabit_Ethernet#100G_Port_Types Which does not answer the question. So you have no answer. Sorry, your ignorance of reality is showing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Jun 01 08:37AM +1200 On 06/ 1/16 04:31 AM, Jerry Stuckle wrote: > And exactly where are those speeds? Considering a single fiber can > handle 10GBS, and even then they don't claim continuous data transfer at > that rate. Fiber speeds are way higher than that and 40GbE can run over copper as well as fiber. Intel 10/40 GbE chips are becoming mainstream on Xeon server boards. I use 10 GbE copper in my home network which will happily run at full speed. >> I/O devices concurrently. > Oh, I know EXACTLY what I'm talking about. And 16 SATAs cannot transfer > data concurrently at full speed. They can, common 8 port SAS/SATA controllers use 8xPCIe lanes which provide ample bandwidth for 8 or 16 SATA drives. -- Ian |
| legalize+jeeves@mail.xmission.com (Richard): May 31 10:14PM [Please do not mail me a copy of your followup] no@notvalid.com spake the secret code >also done other projects 25 years and compilation has not been major >problem never. Was a bit slow in 90 s but today its not slow with the >same (kind of) projects as the computers are very fast. It depends on how well you have cared for your build system over time. It also depends on if you use Windows or linux as your development environment. For the same code, it seems that edit-compile-test cycles go faster on linux than on Windows. This seems to come down to some issues with the NTFS file system (that were addressed in Windows 8 and beyond) and the tool chain. There are many issues that enter into "how long does my build take". Some of these can be laid at the feet of the compiler. Some of these are due to a poorly structured build. If you have a well structured build, you might not notice compile times. If you have a poorly structured build, you might be incorrectly blaming the language for your experience. Let's make this concrete with an example. I have worked on projects where it was considered a "good thing" to put all extern function declarations in a single header file. Because every global function declaration is in this single header file, every source file includes this header file. If you add a new global function, remove an existing global function, or change the signature of an existing global function -- including renaming it -- then every single source file in your entire project needs to be recompiled, whether it used that function or not. Imagine a system created with these sorts of "rules" emplaced upon it by its team. This is a system and a culture that creates unnecessarily long compile times, yet it doesn't really have anything to do with C++. Good modularity is not being practiced on such a team. They almost had the right idea. They thought "group similar things together", but instead of considering similarity on a semantic basis ("When you use one of these functions, you end up using most if not all of them because they are all related"), they thought on a syntactical basis ("all of these identifiers are functions", "all of these identifiers are global variables"). I covered some of these design principles for C++ libraries in this talk: <http://www.slideshare.net/LegalizeAdulthood/consuming-and-creating-libraries-in-c> One aspect of TDD for C++ that I found enjoyable is that my edit-compile-test cycle times were reduced dramatically while working on a class. Compiling and linking together my tests often takes much less time than compiling and linking the entire application. The testing cycle time is automatic (run by the build) and doesn't require me to manually fiddle with the application to verify that I've made forward progress. Manual/automated integration testing still comes into play but it comes in far fewer cycles and after my unit tests are passing when I've already caught most of my bugs. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 31 06:39AM On Sat, 2016-05-28, Öö Tiib wrote: > Search it up, it must be in C++ textbook you use for learning it. > The union objects can be elements of containers and arrays. > Can you tell ... why you have such a great wish? What you need it for? My guess (and it's only a guess) is that: - He's used to Python. - The right solution is on a higher level: to learn to design in C++ without that feature. The good news is that I've used both, and don't feel limited by the lack of the feature in C++. Mixed containers fit nicely with other Python features, but are kind of alien in C++. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| ram@zedat.fu-berlin.de (Stefan Ram): May 31 01:15AM >I guess one question is that how many percentage faster other languages >compile the same project (done with same structures)? Languages don't compile projects. Compilers compile source code. That being said, when a C++ source code set has been changed, sometimes many files have to be recompiled. Compilers for other languages possibly might compile the same amount of source code even slower, but they might have to do so less often, because »modules« in other languages might be more »loosely coupled« and thus don't have to be completely recompiled that often. |
| ram@zedat.fu-berlin.de (Stefan Ram): May 31 01:41AM >Very true, meta programming, either by cpp usage or templates does >have a way of expanding compile times. When one has a java.util.ArrayList<o> object in Java, and the objects of type o get bigger, the classes storing these objects do not have to be recompiled, because they never store the objects directly, just pointers. And the size of the pointers has not changed. An ::std::vector<o> in C++ stores the objects directly and thus would have to be recompiled. That's why C++ vectors sometimes are faster, at least when small objects are stored. When one introduces pimpl into the objects to avoid recompilation, the advantage of the direct storage is also lost. A C++ programmer does not like to trade execution speed for compile time, because otherwise he would have chosen Java in the first place. A very sophisticated build system might use PIMPL for development to reduce compile times and then turn PIMPL off for test and production releases. But this would be a source of another level of complexity and therefore error-prone. |
| 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. |
Fwd: 黃智賢的一篇文章
Sent from my iPad
Sent from my iPad
Begin forwarded message:
From: Jensie Tou <pandjtou@aol.com>
Date: May 26, 2016 at 7:21:02 PM CDT
To: Nancy Chao <nancyhychao@yahoo.com>, Dolores Kuo <doloresmkuo@gmail.com>, tsoongtotherim@aol.com
Subject: Fwd: 黃智賢的一篇文章
Sent from my iPad
Begin forwarded message:Subject: Fwd: 黃智賢的一篇文章介紹個民進黨菁英立法委員黃偉哲的妹妹黃智賢給大家認識，她是下面這篇文章的作者，大膽說出心中多年的怨言，台灣本省人看了，都會不高興，但還是值得，有人敢把心中的想法 ，坦白說出，還真希望台灣人都能看到本文。荒謬的台獨史觀！（黃智賢）蔣介石到臺灣做了千錯萬錯三大錯誤。第一：沒讓日本人戰後賠款及殺掉所有做日本人、漢奸的臺灣人（包括早期從大陸來到臺灣好幾十代中國臺灣人）。第二：三七五減租政策，只給早期移民到臺灣中國農民包括假農民，而與他從1949年從中國撤退到臺灣的生意人、軍人、老兵、農民、學者一無所有。我爸爸是老兵，我們住在高雄貧民違章建築，20年搬了6次家，當房子要被都市更新，我們被迫拆遷沒任何賠償，我母親需要非常辛苦出外打工縫衣服養活五個小孩，因老兵無收入養家。蔣介石時代沒有給這些老兵任何照顧，但卻給臺灣人誰耕種誰就有許多土地，並在那時土地重劃時，許多臺灣假農民（日本佔據臺灣時代的漢奸在土地重劃時，從政府手中拿了許多錢送孩子去美國，歐洲等國家出國讀書，許多人成了台獨份子，因為他們不是日本人漢奸子女，就是日本浪人子女，眾所周知如李登輝爸爸，蔡英文爸爸，蘇貞昌爸爸及親戚等都是在日本人統治臺灣時，幫助日本人殺了許多早期（200年前從中國移民到臺灣的中國人）包括山地原住民近23萬人，其中包括我母親的祖先。第三：在二二八事件遇難死亡的老兵及外省人家屬，沒有任何賠償及立紀念埤。蔣經國先生對臺灣的貢獻有目共睹。唯一做錯一件事，就是選了一位日本人留下在臺灣私生子李登輝成了中華民國總統；李登輝當選中華民國總統在20年前，開始在臺灣做日本人漢奸，進一步在臺灣分化早期 200年前從中國移民到臺灣的中國人，（或受日本統治時代）及1949年隨著蔣介石到台灣的中國人 (熟稱外省人)的感情。這就是國民黨與民進黨的對立延至今天！寫到這裡我就心痛，因中國人到那裡都不團結，媚日本人及對美國人太容忍。我建議中國大陸政府有三件事可以做。如民進黨在2016年在臺灣得到政權，不與大陸合作，不承認九二共識，並在臺灣倡導台獨，大陸可採取以下舉措:1. 限制大陸人旅遊到臺灣或縮小交流，我看臺灣經濟能撐多久。2. 限制大陸購買臺灣農產品，購買魚鰻苗包括台獨份子在臺灣最大區域台南、高雄。3. 對台獨分子列入黑名單，並查台獨份子在大陸設立的公司稅收。我想這些民進黨台獨份子會嚇出尿屎。因為平常在臺灣狐假虎威，做日本走狗的假皇民，一提到他們個人口袋利益在大陸或臺灣會消失，我相信他們就會嚇了閉嘴。這就是典型假皇民（台獨分子）。臺灣80後出生的年青人真是可悲。因為在台獨民進黨分化下，臺灣己走入死胡同。在臺灣年青人找不到工作，縱使找到工作，薪水還停留在我們90年代的臺灣薪水，可憐吧！董媽媽：這些都是事實，可惜馬英九第一次當選總統後，就應該把李登輝和陳水扁28年來製造的分裂，撥亂反正，什麼都沒有做，郝龍斌臺北市長也沒有把【大中至正】重新掛回去，在台灣的中國國民黨已經變成台灣國民黨了！只有民進黨可以任意作為，臺南市長，可以一晚把所有蔣公的銅像拆除！阿扁是凍結國統會，並沒有撤銷，馬英九連形式上的恢復都不敢！奈何！（鏗鏘有力，擲地有聲! ）親愛的朋友：看完如贊同請努力努力轉發讓大家都知道，我很敬佩黃智賢能把臺灣中國人心聲及真心話講出來。
從我的 iPhone 傳送
Sent from my iPad
Begin forwarded message:
Subject: Fwd: Jokes--
笑話三則
笑話一
如果有來生我不做你的紅顏，不做你的知己，不做你的愛人，不做你的任何人，我寧願做你的手機。
那樣的話你會每天把我捧在你手裏，把我貼在你的臉上，把我放在你的唇邊，我知道你的一切亦瞭解你的所有。
如果有一天你匆忙間把我忘在那裏會著急的四處尋找，不是我粘著你而是你離不開我，你若欺負我，我便死機給你看！
笑話二
如今人人都在玩手機，若干年後墓碑上只刻二維碼，路過時拿出手機掃一掃一生的故事就出來了，愛過誰，恨過誰，還牽掛著誰… 這叫"掃墓"，這還不是最可怕的，最可怕的是你掃完後收到一條消息上面寫著：對方已同意添加你為好友！
笑話三
一隻鸚鵡飛到臺灣總統府軍警要抓它，鸚鵡說："你敢，我找我弟弟！"，隨後鸚鵡大喊；"英九，英九，我是英五啊！"
今年這只鸚鵡又飛到總統府，軍警說："你弟弟下臺了"，鸚鵡說："我知道，我找我妹妹"，鸚鵡大喊："英文，英文，我是英武啊！"
You received this message because you are subscribed to the Google Groups "E19buddies" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e19buddies+unsubscribe@googlegroups.com.
To post to this group, send email to e19buddies@googlegroups.com.
Visit this group at https://groups.google.com/group/e19buddies.
For more options, visit https://groups.google.com/d/optout.
Fwd: 绝对好文：透彻分析蔡英文上台后台海局势！ wong
Sent from my iPad
Sent from my iPad
Begin forwarded message:
From: Dolores Kuo <doloresmkuo@gmail.
Subject: Fw: Fwd: Fw: 绝对好文：透彻分析蔡英文上台后台海局势！ wong
To:
--
Sent from My iPad
Digest for comp.programming.threads@googlegroups.com - 2 updates in 2 topics
| bleachbot <bleachbot@httrack.com>: May 30 11:27PM +0200 |
| Ramine <ramine@1.1>: May 30 05:30PM -0700 Hello.... I have updated all my project again, i have corrected a bug inside the interface of the Intel TBBMalloc Memory Manager, now it is working correctly , you will find it inside cmem.pas source code, also i have done a benchmark of the scalable Intel TBBMalloc and the new FastMM4 and here is the results: On 32 bit and on a Quadcore with 4 threads, the scalable Intel TBBMalloc was 2.71X times faster than the newer FastMM4. And on 64 bit and on a Quadcore with 4 threads, the scalable Intel TBBMalloc was 2.56X times faster than the newer FastMM4. So the Intel TBBMalloc more scalable than FastMM4. But FastMM4 is not prone to fragmentatoin as is the scalable Intel TBBMalloc. So you can download again all my updated projects from: https://sites.google.com/site/aminer68/ Please note that my projects are at same version, even if i have updated the Intel TBBMalloc interface inside cmem.pas source code. Thank you, Amine Moulay Ramdane. |
| 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.programming.threads+unsubscribe@googlegroups.com. |
Monday, May 30, 2016
Digest for comp.lang.c++@googlegroups.com - 19 updates in 2 topics
- "Why I don't spend time with Modern C++ anymore" by Henrique Bucher - 18 Updates
- C++ Middleware Writer - 1 Update
| Jerry Stuckle <jstucklex@attglobal.net>: May 29 09:16PM -0400 On 5/29/2016 11:23 AM, David Brown wrote: > 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. No, it isn't even a measurement of "big". > 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. Not at all. There are many more important factors which determine compile time than lines of code. But when none of your programs are more then five lines long, I can see why you think that. > numbers conveniently available. However, the disk usage given in my > reference below also includes non-compilable files, such as graphics > resources. It is a measurement used by people who don't know any better. It is not considered very important by experts. > My reference, which I really hope you will view as reliable and > accurate, is: > <https://sources.debian.net/stats/> Yes, but that is not the whole story. Sorry. > 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++. Gee, let's see. It includes a number of different programming languages. But it also contains a number of different platforms-dependent code. You don't compiler ARM modules for an Intel platform, for instance. And there's a fair amount of assembler code in there. This also includes comments, code split across multiple lines, lines with single left or right braces on them, and a bunch of other things. Finally, it's not all one program. No one has everything in the repository loaded on their machine. Your numbers are as bogus as you are. > 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. For someone not being fussy about exact numbers, you sure do quote a lot of them. > 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. Once again you have shown a distinctly limited knowledge of much of anything. No, you have no idea how mainframes work. You don't even understand the principles. This is just another example. > 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. Fine. I really don't give a damn what you're limited knowledge will allow you to believe. After all, "Hello World" is a big program to you. So is LibreOffice. So much for your "experience". But I also know you'll argue until the day you die instead of admitting you are wrong - as you have repeatedly shown here and in c.l.c. >> 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. I care what knowledgeable people think of my reputation. I don't care what an idiot like you thinks. You aren't worth it. >> 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. No, they are productive. No wonder you have so much trouble finding work. > 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? You really are funny. I'd feel sorry for you if you weren't so unwilling to admit when you are wrong. There is a difference between ignorance and stupidity. Ignorance can be cured. But you are beyond stupidity. And no, we still have a good group going. But I like usenet because there are intelligent people on it, and I don't want new programmers to get wrong ideas from the likes of you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Juha Nieminen <nospam@thanks.invalid>: May 30 06:27AM > Another troll post. Ah, the ultimate form of concession. Whenever someone disagrees with you, just accuse them of "trolling". What a great argument. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: May 30 06:31AM >> every single C++ programmer. > Excuse me but given that any C++ programmer must compile his/her code > sometime, it SURELY affects EVERY SINGLE C++ PROGRAMMER. WTF are you talking about? Where exactly did I say that *compiling* the program is the issue? --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: May 30 06:34AM > It's a huge problem for a large number of programmers. Just because it > isn't for YOU does not mean it's not important to OTHERS. YOU ARE NOT > THE WHOLE WORLD. "You haven't worked on very big projects, then. I've seen compiles take overnight on a mainframe." So, tell me, how many C++ programmers develop "very big projects" that "take overnight on a mainframe" to compile? In percents, that is. Again: If you want to change your programming language in your humongous project, be my guest. But don't be telling people that it's a problem for *all* C++ programmers, because it isn't. That's just a big fat lie. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Christian Gollwitzer <auriocus@gmx.de>: May 30 08:35AM +0200 Am 30.05.16 um 08:27 schrieb Juha Nieminen: >> Another troll post. > Ah, the ultimate form of concession. Whenever someone disagrees with you, > just accuse them of "trolling". What a great argument. No, it's self-awareness. What is trolling? Posting controverse opinions, insulting people as "too stooopid to understand their standpoint", ignoring facts etc. See the pattern? He still has to practice. Well-trained trolls have a much higher response-per-troll-post ratio, i.e. they don't need to react that often to keep it going. Christian |
| David Brown <david.brown@hesbynett.no>: May 30 08:52AM +0200 On 30/05/16 03:16, Jerry Stuckle wrote: > And no, we still have a good group going. But I like usenet because > there are intelligent people on it, and I don't want new programmers to > get wrong ideas from the likes of you. I fully agree that there are many intelligent people on Usenet, including many in c.l.c++ and c.l.c. But more important than mere intelligence, there are many here who are helpful, friendly, honest, experienced, and interested in sharing knowledge, learning new things, and engaging in friendly banter. They don't always agree on everything, but are happy to disagree and discuss in an adult manner (except on topics of swearing, religion, and sausages - but no one's perfect). Those are the people who you have, almost without exception, labelled as "stoopid trolls" and "pigs who can't sing". It seems you like Usenet because it gives you an opportunity to insult people. |
| "Öö Tiib" <ootiib@hot.ee>: May 30 01:10AM -0700 On Monday, 30 May 2016 04:16:50 UTC+3, Jerry Stuckle wrote: > > keen to claim that mainframe programs are so much bigger than anything > > else. > No, it isn't even a measurement of "big". A bald assertion of denial? > > more complex than others, and of course there are many other factors. > > You might have noticed that I have already mentioned this. > Not at all. A bald assertion of denial? > There are many more important factors which determine > compile time than lines of code. Some indefinite mysterious "factors"? > But when none of your programs are > more then five lines long, I can see why you think that. Some patronizing ad hominem? > > reference below also includes non-compilable files, such as graphics > > resources. > It is a measurement used by people who don't know any better. Another patronizing insult? > It is not considered very important by experts. A bald, groundless assertion of denial? > > accurate, is: > > <https://sources.debian.net/stats/> > Yes, but that is not the whole story. Sorry. A bald assertion of denial? > platforms-dependent code. You don't compiler ARM modules for an Intel > platform, for instance. And there's a fair amount of assembler code in > there. Finally only place in post that indicates some connection with subject not just mechanical denial or insult. That however is irrelevant red herring without even slightest attempt of quantifying the alleged effect of it. > This also includes comments, code split across multiple lines, lines > with single left or right braces on them, and a bunch of other things. Red herring continues. Are you really wanting to say that stripping comments will anyhow affect order of magnitude of code base size? What code base is that? > Finally, it's not all one program. No one has everything in the > repository loaded on their machine. Fighting with straw man you built yourself? > Your numbers are as bogus as you are. Patronizing insult. > > great many programs. > For someone not being fussy about exact numbers, you sure do quote a lot > of them. Totally unfair tu quoque? No one can compete with indefiniteness, baldness and groundlessness of your postings, Jerry. > > on and off the disk fast enough to keep the processors busy. > Once again you have shown a distinctly limited knowledge of much of > anything. Patronizing, groundless insult? > No, you have no idea how mainframes work. Patronizing, groundless insult? > You don't even understand the principles. Patronizing, groundless insult? > This is just another example. It is unclear even, WTF you are talking about here. > Fine. I really don't give a damn what you're limited knowledge will > allow you to believe. After all, "Hello World" is a big program to you. > So is LibreOffice. Total patronizing bullshit nonsense? Not even wrong, just grotesque? > So much for your "experience". But I also know you'll argue until the > day you die instead of admitting you are wrong - as you have repeatedly > shown here and in c.l.c. Direct, outright lie? > > reputation here in Usenet. > I care what knowledgeable people think of my reputation. I don't care > what an idiot like you thinks. You aren't worth it. You have certainly high skill of posting lot of empty bullshit. Hopefully it entertains you. > >> 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. > No, they are productive. No wonder you have so much trouble finding work. :D You are apparently mirroring your own issues to others. Sad. > And no, we still have a good group going. But I like usenet because > there are intelligent people on it, and I don't want new programmers to > get wrong ideas from the likes of you. I replied to the post because it was so devoid of any sparks indicating consciousness that it somewhat felt like Turing test. Are you bot, Jerry Stuckle? Someone just wrote a program that pretends being total asshole, idiot and troll? |
| Gareth Owen <gwowen@gmail.com>: May 30 11:08AM +0100 >> 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? Reality has an anti-Jerry bias. |
| Gareth Owen <gwowen@gmail.com>: May 30 11:10AM +0100 > overnight on a mainframe." > So, tell me, how many C++ programmers develop "very big projects" that > "take overnight on a mainframe" to compile? In percents, that is. And more importantly, if those "very big projects" were to be written in C, say, would they cease to take a very long time to compile? |
| jacobnavia <jacob@jacob.remcomp.fr>: May 30 02:12PM +0200 Le 30/05/2016 à 08:31, Juha Nieminen a écrit : > WTF are you talking about? Where exactly did I say that *compiling* the > program is the issue? > --- news://freenews.netfront.net/ - complaints: news@netfront.net --- You said: >>> someone complains about C++, the "long compile times" argument is >>> brought up, like it were some kind of crucial core flaw that affects >>> every single C++ programmer. Maybe I forgot my english but for me that is clear. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 10:28AM -0400 On 5/30/2016 2:34 AM, Juha Nieminen wrote: > project, be my guest. But don't be telling people that it's a problem > for *all* C++ programmers, because it isn't. That's just a big fat lie. > --- news://freenews.netfront.net/ - complaints: news@netfront.net --- Just because you don't doesn't mean it's not important. But then most programmers develop programs bigger than "Hello World". And many of us work on a project basis, where every minute spent compiling is lost income. Others work on an hourly basis, where every minute spent compiling is lost productivity. And I never said it was a problem for *all* C++ programmers. But *YOU* said it was not a problem for ANY C++ programmers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 10:29AM -0400 On 5/30/2016 2:27 AM, Juha Nieminen wrote: > Ah, the ultimate form of concession. Whenever someone disagrees with you, > just accuse them of "trolling". What a great argument. > --- news://freenews.netfront.net/ - complaints: news@netfront.net --- Nope, just when they are trolling. Like yours here. But I know I'm trying to teach the pig to sing. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 10:34AM -0400 On 5/30/2016 2:35 AM, Christian Gollwitzer wrote: > response-per-troll-post ratio, i.e. they don't need to react that often > to keep it going. > Christian Wrong, Christian. Trolling is twisting facts and statements to make it seem like someone said something else. It is also rejecting something without even examining it and trying to understand it. And there are several people here do perform both. Some have even admitted they are trolling. Calling someone "too stoopid to understand..." is just that. It's something I have observed repeatedly here. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 10:37AM -0400 On 5/30/2016 2:52 AM, David Brown wrote: > "stoopid trolls" and "pigs who can't sing". > It seems you like Usenet because it gives you an opportunity to insult > people. No, there are others here who try to understand, attempt to carry on intelligent conversations and truly try to be helpful. But then there are those who are so insecure they would rather try to prove someone else wrong than admit they may be wrong. They don't try to understand - they just take the opposite position no matter what. If someone said the sun rises in the east, they would claim it rises in the west. Those are the stoopid trolls and the pigs who can't sing. I'm sorry you have such issues. But they're not *MY* problem. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 10:52AM -0400 On 5/30/2016 4:10 AM, Öö Tiib wrote: >>> else. >> No, it isn't even a measurement of "big". > A bald assertion of denial? The truth - known by *real* experts in the field. But those who *think* they are experts keep quoting it as the final word. >>> You might have noticed that I have already mentioned this. >> Not at all. > A bald assertion of denial? The truth - known by *real* experts in the field. But those who *think* they are experts keep quoting it as the final word. >> There are many more important factors which determine >> compile time than lines of code. > Some indefinite mysterious "factors"? Code complexity is the main one. In languages like C++, template complexity and instantiation is another one. When using other tools like some databases, the need to preprocess the code (ahead of the C++ preprocessor) takes time. A whole bunch of things. >> But when none of your programs are >> more then five lines long, I can see why you think that. > Some patronizing ad hominem? Just the truth, as indicated by previous posts. > Another patronizing insult? >> It is not considered very important by experts. > A bald, groundless assertion of denial? Just the truth. >>> <https://sources.debian.net/stats/> >> Yes, but that is not the whole story. Sorry. > A bald assertion of denial? Just the truth. > not just mechanical denial or insult. That however is irrelevant red > herring without even slightest attempt of quantifying the alleged > effect of it. That's because I'm tired of having to repeat myself to people with the inability to understand simple statements. And every bit of it is 100% relevant as a reply to the post. But you are too stoopid to see even that simple concept. > Red herring continues. Are you really wanting to say that stripping > comments will anyhow affect order of magnitude of code base size? What > code base is that? ROFLAMO! Once again you show your inability to understand a simple concept. Either that or you are arguing just to argue. I'm not sure which, but I suspect the former. >> Finally, it's not all one program. No one has everything in the >> repository loaded on their machine. > Fighting with straw man you built yourself? Just responding to the post. Something you seem incapable of understanding. >> Your numbers are as bogus as you are. > Patronizing insult. Just the truth, as repeatedly proven by his own statements. >> of them. > Totally unfair tu quoque? No one can compete with indefiniteness, baldness > and groundlessness of your postings, Jerry. Sorry, wrong again. First he cites numbers, then claims he's not fussy about them. It doesn't work. >> Once again you have shown a distinctly limited knowledge of much of >> anything. > Patronizing, groundless insult? Just the truth, as repeatedly proven by his own statements. >> No, you have no idea how mainframes work. > Patronizing, groundless insult? Just the truth, as repeatedly proven by his own statements. >> You don't even understand the principles. > Patronizing, groundless insult? Just the truth, as repeatedly proven by his own statements. >> This is just another example. > It is unclear even, WTF you are talking about here. Nope. It would take someone with a modicum of intelligence to understand anything in this discussion. Something you once again prove you do not have. >> allow you to believe. After all, "Hello World" is a big program to you. >> So is LibreOffice. > Total patronizing bullshit nonsense? Not even wrong, just grotesque? Just the truth. >> day you die instead of admitting you are wrong - as you have repeatedly >> shown here and in c.l.c. > Direct, outright lie? Just the truth, as repeatedly proven by his own statements. >> what an idiot like you thinks. You aren't worth it. > You have certainly high skill of posting lot of empty bullshit. Hopefully > it entertains you. You certainly have no skills for understanding simple concepts. But this is the total truth. And just FYI, I hold you in even lower esteem than David. This whole post of yours is nothing but trolling. >>> People who write a few lines of code a week do not work on mainframes. >> No, they are productive. No wonder you have so much trouble finding work. > :D You are apparently mirroring your own issues to others. Sad. Not at all. I have plenty of work. And unlike you, mine is real *programming* work. Not digging ditches or washing dishes. > consciousness that it somewhat felt like Turing test. Are you bot, Jerry > Stuckle? Someone just wrote a program that pretends being total asshole, > idiot and troll? You replied because you are a stoopid troll, as you have repeatedly shown. And it's exactly what I would expect coming from you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: May 30 08:08PM +0100 On 30/05/2016 15:28, Jerry Stuckle wrote: > compiling is lost productivity. > And I never said it was a problem for *all* C++ programmers. But *YOU* > said it was not a problem for ANY C++ programmers. I guess one question is that how many percentage faster other languages compile the same project (done with same structures)? Also , I do not think we should only think on factor (how quickly is compiled). We should take into consideration ALL factors, like how good the langauge is... how long it takes to develop the code, how easy is to maintain the code etc etc. Compiling is only on factor in regards to things taking time. How much faster other languages compile the same project? |
| Jerry Stuckle <jstucklex@attglobal.net>: May 30 06:21PM -0400 On 5/30/2016 3:08 PM, JiiPee wrote: > maintain the code etc etc. Compiling is only on factor in regards to > things taking time. > How much faster other languages compile the same project? It makes no difference what other languages do. They are not being used. And yes, compiling is one factor. But it is an important one because it is wasted programmer time. How good the language is is pretty unimportant, also. What IS important is how good the programmer is. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| JiiPee <no@notvalid.com>: May 30 11:43PM +0100 On 30/05/2016 23:21, Jerry Stuckle wrote: > It makes no difference what other languages do. They are not being > used. And yes, compiling is one factor. But it is an important one > because it is wasted programmer time. I dont think nobody disagrees. But as I said, Microsoft cannot do everything... they have limited budject I think. so they chose what is more important and how many it affects. Thats how the C++ commitea also thinks I know. > How good the language is is pretty unimportant, also. What IS important > is how good the programmer is. in a way true. but on the other hand, if your statement is the only truth, then that would mean that it does not matter if we use 90 s C++ or C++11/14. But I think there is an essential difference as C++11 is much safer etc. So your code becomes less risky with better language, I think. So it does matter, at least somewhat. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 30 11:01PM +0100 On Sun, 29 May 2016 09:56:42 -0700 (PDT) woodbrian77@gmail.com wrote: [snip] > 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. Since you are the one who thinks it is OK to make regular posting to this newsgroup about things which have nothing to do with C++, you are better equipped than me to say what people such as you who "prefer anything goes" want to have added to the standard. However, this seems like another of your weird misdirection postings. I cannot see how any lack of respect for the purposes of this newsgroup that you or others have, has anything to do with whether there should be a variant class added to the standard. |
| 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. |
Subscribe to:
Posts (Atom)