- About C++ style (functions) - 15 Updates
- "Why I don't spend time with Modern C++ anymore" by Henrique Bucher - 10 Updates
| Ian Collins <ian-news@hotmail.com>: Jun 05 12:37PM +1200 On 06/ 5/16 08:52 AM, JiiPee wrote: > thats how also was thinking, although maybe its not too big issue... > But its true that it a bit conflicts with the creation of an object: > ThisIsFoo(); Which leads to the ultimate abomination: class CFoo ! -- Ian |
| JiiPee <no@notvalid.com>: Jun 05 02:09AM +0100 On 05/06/2016 01:37, Ian Collins wrote: >> But its true that it a bit conflicts with the creation of an object: >> ThisIsFoo(); > Which leads to the ultimate abomination: class CFoo ! are you condemning Microsofts nice MFC??? how dare you!! :) but seriouesly, it is respected library, right |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 04 09:23PM -0400 On 6/4/2016 12:57 PM, JiiPee wrote: >>> looks prettier becouse its "even". >> It's all a matter of style. > you mean a matter of personal taste? No, I mean a matter of style. Nothing more, nothing less. <snip> -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| "Öö Tiib" <ootiib@hot.ee>: Jun 05 02:06AM -0700 On Sunday, 5 June 2016 03:38:07 UTC+3, Ian Collins wrote: > > But its true that it a bit conflicts with the creation of an object: > > ThisIsFoo(); > Which leads to the ultimate abomination: class CFoo ! Aren't those "C" prefixes the nuisance from "C-with-objects" times before standard and namespaces? Is the "C" of MFC different from "Q" of Qt or "wx" of wxWidgets? It may be because they also use prefixes "I", "CCom", "CAtl" and suffix "Impl" in some class names. Usage of neither namespaces nor prefixes feels worst and non-professional to me but YMMV. |
| Bo Persson <bop@gmb.dk>: Jun 05 11:50AM +0200 On 2016-06-04 22:52, JiiPee wrote: > thats how also was thinking, although maybe its not too big issue... > But its true that it a bit conflicts with the creation of an object: > ThisIsFoo(); But this can be less of a problem if you follow the pattern of function names containing a verb (what it does) and class names being a noun (what it is). The name Foo() is just an example of how not to name things. Bo Persson |
| David Brown <david.brown@hesbynett.no>: Jun 05 02:36PM +0200 On 05/06/16 03:09, JiiPee wrote: >> Which leads to the ultimate abomination: class CFoo ! > are you condemning Microsofts nice MFC??? how dare you!! :) > but seriouesly, it is respected library, right Wrong. Comparing a library to MFC is usually considered an insult. Somewhere along the line, MS got the idea of "Hungarian notation" totally mixed up - it went from a good idea that was useful for safer programming (such as prefix "ss" for safe strings and "us" for unsafe strings), especially in weak typed languages, into a way to uglify code, prevent proper typing, and hinder maintenance and improvements to code (such as prefix "C" for classes, "pwsz" for pointer to wide strings, etc.). (I don't know details of the history of MFC, but presumably many of the design decisions were due to limitations of the C++ language and the MSVC compiler at the time, plus the chaos of the underlying Win32 API. I am not saying that MS did a bad job here, merely that it is not a library or style to be copied now.) |
| David Brown <david.brown@hesbynett.no>: Jun 05 02:40PM +0200 On 05/06/16 11:06, Öö Tiib wrote: > "wx" of wxWidgets? It may be because they also use prefixes "I", "CCom", > "CAtl" and suffix "Impl" in some class names. Usage of neither namespaces > nor prefixes feels worst and non-professional to me but YMMV. The key difference is that the "wx" of wxWidgets and the "Q" of QT are namespace indicators from the days before the language had namespaces. The MFC "C" prefixes are for "class" - which is entirely redundant if you know what you are doing when you are using the classes. |
| JiiPee <no@notvalid.com>: Jun 05 01:42PM +0100 On 05/06/2016 13:36, David Brown wrote: > MSVC compiler at the time, plus the chaos of the underlying Win32 API. > I am not saying that MS did a bad job here, merely that it is not a > library or style to be copied now.) on the other hand MFC works... it just works! so what is wrong if it works? I still use it and the only GUI i really know. |
| Wouter van Ooijen <wouter@voti.nl>: Jun 05 02:52PM +0200 Op 05-Jun-16 om 2:42 PM schreef JiiPee: >> library or style to be copied now.) > on the other hand MFC works... it just works! so what is wrong if it > works? I still use it and the only GUI i really know. That it works is not a valid argument for its *style*. It would still work if you replaced each identifier in it by xN (for N in 1,2,3,,...). Wouter |
| JiiPee <no@notvalid.com>: Jun 05 01:52PM +0100 On 05/06/2016 13:40, David Brown wrote: > namespace indicators from the days before the language had namespaces. > The MFC "C" prefixes are for "class" - which is entirely redundant if > you know what you are doing when you are using the classes. I agree, thats why I stopped using it some years ago. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 05 03:07PM +0200 On 05.06.2016 14:36, David Brown wrote: > MSVC compiler at the time, plus the chaos of the underlying Win32 API. > I am not saying that MS did a bad job here, merely that it is not a > library or style to be copied now.) As far as I know the Hungarian notation was originally in support of the help system in Microsoft's Programmers' Workbench IDE. I don't know where to find this info now, in particular as there were at least two other Programmers' Workbench. I think I saw it in Petzold's Programming Windows 3rd edition or thereabouts, where he discussed logical fonts or something. Cheers & hth., - Alf |
| David Brown <david.brown@hesbynett.no>: Jun 05 03:21PM +0200 On 05/06/16 15:07, Alf P. Steinbach wrote: > least two other Programmers' Workbench. > I think I saw it in Petzold's Programming Windows 3rd edition or > thereabouts, where he discussed logical fonts or something. I have not done much C or C++ programming on Windows, so I don't know what was implemented or common at different times in MS's tools. But my understanding was that the key point of Hungarian notation was originally to add extra information for the programmer, beyond what could be conveniently or reliably expressed in the language (C in particular). A key example is was that information a program got from the outside should be labelled differently: usName = nameEnteredOnWebPage(); ssName = sanatizeString(usName); runSqlQueryByName(ssName); If you are strict about using "us" for "unsafe string" and "ss" for "safe string", then your chances of coding for an SQL injection attack here are very much smaller. This use of prefixes added something useful to the code. (With modern C++ programming, it could arguably be better done with different types rather than naming prefixes). But at some point, people started using prefixes merely to indicate types - duplicating information rather than adding it. And as more types got used, the prefixes got uglier, and maintenance got harder because any changes meant changing two different ways of saying the same thing. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 05 10:56AM -0400 On 6/5/2016 9:07 AM, Alf P. Steinbach wrote: > thereabouts, where he discussed logical fonts or something. > Cheers & hth., > - Alf Hungarian Notation was around long before MS's IDE (and not restricted to C). At least back in the 70's. Petzold did use it, but he wasn't first by any means. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Paavo Helde <myfirstname@osa.pri.ee>: Jun 05 06:02PM +0300 On 5.06.2016 15:36, David Brown wrote: > MSVC compiler at the time, plus the chaos of the underlying Win32 API. > I am not saying that MS did a bad job here, merely that it is not a > library or style to be copied now.) I have always assumed the MS Hungarian notation conventions were worked out for C where they actually make sense, but then were automatically copied over to C++ where they do not make sense at all. It seems like somebody did not realize these are two very different languages. Cheers Paavo |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 05 05:42PM +0100 On 04/06/2016 12:25, JiiPee wrote: > which style and what is the reason? Is there any strong good reason to > use the other and not the other? For my eyes at the moment ThisIsFoo > looks prettier becouse its "even". The superior naming convention that I use: 1. Naming Conventions Artefact Convention Function name foo_bar_baz Class name foo_bar_baz Object/variable name: fooBarBaz prefixFooBarBaz Prefix Meaning none Local object/variable a Function argument i Class member ("instance") object/variable s Static object/variable k Constant Enumeration name foo_bar_baz_e Enumerator name FooBarBaz Template parameter FooBarBaz Macro FOO_BAR_BAZ Examples #include <iostream> #include <string> #include <vector> enum grade_e { A, B, C, D, E, F }; class student { private: typedef std::vector<grade_e> grades; public: student(const std::string& aName) : iName(aName) {} public: const std::string& name() const { return iName; } void add_grade(grade_e aGrade) { iGrades.push_back(aGrade); } grade_e average_grade() const { if (iGrades.empty()) return F; int total = 0; for (grades::const_iterator i = iGrades.begin(); i != iGrades.end(); ++i) total += *i; return static_cast<grade_e>(total / iGrades.size()); } private: const std::string iName; grades iGrades; }; int main() { student s("Mr Flibble"); s.add_grade(A); s.add_grade(B); s.add_grade(C); s.add_grade(D); s.add_grade(E); std::cout << s.name() << "'s average grade is " << static_cast<char>(s.average_grade() + 'A') << std::endl; } /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Jun 04 09:22PM -0400 On 6/4/2016 10:40 AM, Dan Cross wrote: >> everyone there plonk you, also, so you have no one to troll? > Huh? I'm pretty sure I've never posted to alt.feminism. You must > have me confused with someone else. ROFLMAO! Once posted to the internet, always posted to the internet. > I'm also pretty sure I haven't posted to "dozens of groups" at all > in the last 15 years. Aagain you must have me confused with someone > else. How many "Dan Cross"s are there at your email address? > are just making it up. Or perhaps you are just incompetent. Well, > that is certainly true; these things are clearly not mutually > exclusive. *shrug* Not at all. A quick Google search proves the case. > "set them straight" or "educate" them, what with your "extensive > experience" as a ham radio operator and "45 years of programming." > - Dan C. Sorry, you can't lie your way out of this one, troll. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 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. |
| 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. |
| 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. |
| 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 |
| 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 |
| 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 ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 31 08:24PM -0400 On 5/31/2016 4:37 PM, Ian Collins wrote: > 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. And you didn't answer the question, either. How like a troll. >> 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. Try again. Only controller can access the data bus at a time. 16 SATAs cannot transfer data concurrently at full speed. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| 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. |
| 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 |
| 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