- C++ may sometimes be *too* simple (to use) - 2 Updates
- Text editor project in C - 4 Updates
- Support for a device (with DLL's) which is controlled by winforms(c++) - 2 Updates
| Juha Nieminen <nospam@thanks.invalid>: Apr 29 04:45AM > I don't see any problem either way as both seemed as error prone and used > same magic number 5 ... I only thought wtf is that 5. Are you always this nitpicky about examples (that have been simplified from the real-life counterparts that they are based on)? > Have you ever used profiler on some large product? If you have slight unnecessary inefficiencies at a thousand places in a huge program, the profiler isn't going to tell you where and which. The only thing it's going to tell you is that "this action is taking 1 second" but it won't be able to pinpoint the exact bottleneck... because the bottleneck will be about evenly distributed among a thousand instances of "this doesn't need to be efficient". It's, arguably, the worst possible bottleneck that could exist, because you can't pinpoint it. And fixing it is extraordinarily laborious, it will probably never be done, and the program will be doomed to being inefficient because nobody will fix it. All because of thousands of instances of the "this doesn't need to be efficient" attitude. > Nonsense, I don't wonder, I have decades of evidence that the attitude > is correct, and considering optimal when focus should be to robustness > and correctness is worthless and counterproductive. Yeah, because string::substr() is so much more robust and correct than string::compare(). I think that *deliberately* writing inefficient code is highly counterproductive. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 29 03:16PM -0700 On Thursday, 29 April 2021 at 07:45:17 UTC+3, Juha Nieminen wrote: > > same magic number 5 ... I only thought wtf is that 5. > Are you always this nitpicky about examples (that have been simplified from > the real-life counterparts that they are based on)? Sorry, but those removed parts can actually show why it was done like that. > 1 second" but it won't be able to pinpoint the exact bottleneck... > because the bottleneck will be about evenly distributed among a > thousand instances of "this doesn't need to be efficient". No, you haven't used profiler? It always shows that only tiny subpart of whole program code is ran over 90% of time. Rest of code is ran more rarely and rarely. Half of most C++ code can be rewritten in Python and overall perceived performance of product does not change at all. > doomed to being inefficient because nobody will fix it. All because > of thousands of instances of the "this doesn't need to be efficient" > attitude. Because that bottleneck does not exist. All that time wasted and 1% of performance gained. Meanwhile possible opportunities to improve performance several times lost. > > and correctness is worthless and counterproductive. > Yeah, because string::substr() is so much more robust and correct than > string::compare(). For example the size() of all containers wasn't O(1) in C++98 but programmers used it to check if container was empty. It had to be made O(1) as it was somehow easier for programmers to reason. Same can be about your code that whatever you simplified out made that substr() easier to reason than compare(). > I think that *deliberately* writing inefficient code is highly > counterproductive. I don't think someone deliberately wrote c.size()==0 when it was less efficient than c.empty() ... or it++ when ++it was more efficient. Their focus was simply on things that mattered. |
| Juha Nieminen <nospam@thanks.invalid>: Apr 29 04:47AM > Agreed that the TIOBE index should be taken with a grain of salt Isn't it mainly based on how much people ask questions in forums about the language in question? If that's so, then maybe the index shouldn't be interpreted as how popular the language is, but how many questions it raises when people try to use it. |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 29 11:42AM +0300 29.04.2021 07:47 Juha Nieminen kirjutas: > If that's so, then maybe the index shouldn't be interpreted as how > popular the language is, but how many questions it raises when people > try to use it. Some of my recent programming related google searches: man recv man send man setsockopt man wcsncmp man fileno man ftello64 man fabs man scanf std::deque c++ inline variable So I can easily see how someone might mistakenly consider me a C programmer. One of my frequent questions about C functions is what the correct include header is, these are sometimes quite chaotic, but one must get them correct when e.g. moving around some existing code. |
| wij <wyniijj@gmail.com>: Apr 29 10:56AM -0700 On Thursday, 29 April 2021 at 00:57:11 UTC+8, Öö Tiib wrote: > themselves (and their kids) being vegetarians. It is because everybody want > talk about themselves and to find and to cooperate with others who share > their attitude. Many 'larger' companies in my place are production companies. If C++ is listed in the job requirement, often associated with are database, web,HMI,AI,motor,vehicle,...,for hardware verification/simulation/analysis. Rare companies like these would intentionally announce changes of their tools, internal affairs. E.g. Garmin (because the job requirement is in English, and is typical form) wants C/C++ people. 1. Good understanding in C/C++ programming. 2. Fitness GPS product design – Running Wearables, cycling products and wellness products. 3. Good English communication ability to communicate with foreign engineers. Will be a plus if have experience about: 1. Computer architecture and ARM Compiler. 2. Have experience about embedded system or RTOS. 3. Knowledge about how to use logic analyzer and Jtag ICE. 4. Other OS related knowledge. ---------------------------- In this case, normal C++ applicant would headache with ARM compiler, RTOS, ICE, and hardware things. And, "C/C++" is a general term. I can not think of any reason, any company like this would say anything too specific about their production tools. |
| Christian Gollwitzer <auriocus@gmx.de>: Apr 29 11:04PM +0200 Am 29.04.21 um 10:42 schrieb Paavo Helde: > c++ inline variable > So I can easily see how someone might mistakenly consider me a C > programmer. This is not how TIOBE works. They run searches on Google and other search engines with the name of the programming language and count the hits: https://www.tiobe.com/tiobe-index/programming-languages-definition/ If you run a google search yourself for scanf, that doesn't influence TIOBE at all, not even if you post a question about scanf to stackoverflow, unless you (or someone else) also mentions "C" or "C++" on the same page. So yes, it is true, the more questions a language raises, the more you'll find pages referencing it, but also the more people use it, the more will be questions.... it is definitely not a tool to run a competition between the second and third place - that is rather arbitrary. But you can be sure that a language on the 25th place (Prolog) is used less than one from the 3rd place (Python) - though in this realm, you'll find languages like Bash at the 42nd place. Bash is definitely a language without which the world would be a different place, yet people dont write that much LOC in it and therefore pose fewer questions - hence, TIOBE place doesn't equal importance. Concerning C and C++, the situation is especially bad, because many search engines cannot really distinguish between those two, let alone the users always post the correct term - some refer to C++ simply as C (as opposed to Python, e.g.). Therefore, TIOBE tells practically nothing if C or C++ is more commonly used. A similar ranking with maybe more sound methodology is this: https://madnight.github.io/githut/#/pull_requests/2021/1 It's counting the number of pull requests on Github. I'm inclinded to believe this more than TIOBE overall. But that is only my gut feeling. Christian |
| Ralf Goertz <me@myprovider.invalid>: Apr 29 09:50AM +0200 Am Wed, 28 Apr 2021 23:10:03 +0100 > > from the newsgroup name. > If you post directly on to C++ link, does it work? > <https://groups.google.com/g/comp.lang.c++> Written as such it is no surprise that you land in the C group and not the C++ one. My newsreader (maybe erroneously) also drops the two pluses when clicking on it to open the link in a browser since they are not percent encoded. With <https://groups.google.com/g/comp.lang.c%2B%2B> you should be on the safe side. I must admit though that "+" being a reserved character should in some circumstances also be usable "as is" if I understand <https://en.wikipedia.org/wiki/Percent-encoding> correctly: "Reserved characters that have no reserved purpose in a particular context may also be percent-encoded but are not semantically different from those that are not." But I am not inclined to figure out when that is the case. > I would have thought that if people can find this link on google > portal then it should work. Google Groups are a mess and you can't > find direct links to the posting site any more. I haven't tried to post using that link, though. |
| Richard Harnden <richard.nospam@gmail.com>: Apr 29 01:58PM +0100 On 29/04/2021 08:50, Ralf Goertz wrote: >> portal then it should work. Google Groups are a mess and you can't >> find direct links to the posting site any more. > I haven't tried to post using that link, though. "New conversation" on both the ++ and %2b%2b versions open a "New conversation in comp.lang.c" window. So GG is useless. Everybody knows this. |
| 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