- C passes Java and becomes number 1 programming language - 7 Updates
- Custom allocator not working with gcc - 3 Updates
- invalid initialization of non-const reference of type - 2 Updates
- Recursive spinlock - 7 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 07:08PM +0200 Am 10.05.2020 um 18:58 schrieb jacobnavia: > https://jaxenter.com/c-programming-may-2020-171598.html > C increased by 2.82% to 17.07% > C++ going down 1,97% to 6,13% I think this is not because C is used so often in practice, but because C is a good language for learning for system -oriented programming. In practice, C is usually too uneconomical compared to other languages. This means that you need more time to do the same task and you make more mistakes. |
| Siri Cruise <chine.bleu@yahoo.com>: May 11 12:33AM -0700 In article <r99br2$j6e$1@dont-email.me>, > https://jaxenter.com/c-programming-may-2020-171598.html > C increased by 2.82% to 17.07% > C++ going down 1,97% to 6,13% This due to the good lord. Lord Jim, the god of dubious acheivements. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 10 06:51PM On Sun, 2020-05-10, Daniel P wrote: > results? Maybe everyone has finally figured out the nuances of > SFINAE and don't need to look that up anymore. > But note that the index is volatile - very volatile. All attempts to use the TIOBE index end up as a debate about the validity of the TIOBE index. The graph at https://www.tiobe.com/tiobe-index/ says more than the diff against April. And raises more questions. If one looks at the graph, from 2002 onwards, do the changes match /any/ known actual changes? I cannot easily see any. I cannot e.g. see any raised "interest" in C++ when the plans for C++11 became known. And I can't see why C was "unpopular" in 2016--2017. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bo Persson <bo@bo-persson.se>: May 10 08:09PM +0200 On 2020-05-10 at 19:25, jacobnavia wrote: > It would be interesting to reflect why C++ has gone down so much. Of > course I have my ideas (just too difficult to learn) but it would be > nice if we could make a common diagnostic. Being difficult to learn could also result in *more* search engine activity. :-) Bo Persson |
| Ian Collins <ian-news@hotmail.com>: May 11 08:39AM +1200 On 11/05/2020 06:09, Bo Persson wrote: >> nice if we could make a common diagnostic. > Being difficult to learn could also result in *more* search engine > activity. :-) C++ programmers don't need to look stuff up on the Internet! -- Ian. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 07:57AM +0200 > C++ programmers don't need to look stuff up on the Internet! Especially they need to do it because C++ is a complex language. |
| jacobnavia <jacob@jacob.remcomp.fr>: May 10 07:25PM +0200 Le 10/05/2020 à 19:08, Bonita Montero a écrit : > In practice, C is usually too uneconomical compared to other > languages. This means that you need more time to do the same > task and you make more mistakes. It would be interesting to reflect why C++ has gone down so much. Of course I have my ideas (just too difficult to learn) but it would be nice if we could make a common diagnostic. Without falling into personal wars of course. |
| boltar@nowhere.co.uk: May 11 08:45AM On Sun, 10 May 2020 02:45:27 -0700 >>>Be less rude. >> I'll pose that question again. >Bye. I didn't think you'd be able to answer. |
| Juha Nieminen <nospam@thanks.invalid>: May 10 05:54AM > code even if its test code, otherwise I'd have to throw process control, > networking and half a dozen other subsystems which "pure" c++ doesn't support > out the window. When you post code here, make sure it actually compiles. Your code did not compile for me because of that "u_long". |
| Bo Persson <bo@bo-persson.se>: May 10 12:51PM +0200 >> the information. > Ok, I didn't know that. It just proves to me yet again what a joke > that operating system and its tools are. You mean unlike other systems where long and long long are the exact same size? Bo Persson |
| Bo Persson <bo@bo-persson.se>: May 10 12:40PM +0200 On 2020-05-10 at 09:19, Jorgen Grahn wrote: >> void printVector( const Vector3 &vec) > And that's what you want anyway, since you surely don't intend to let > printVector() modify the vector it prints. And additionally - the origin of this rule (no non-const reference to temporaries) comes from the fact that any modifications will be lost anyway when the temporary immediately goes away. Apparently Bjarne and his colleagues had some initial problem with this, before he invented that rule. Bo Persson |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 10 07:19AM On Sun, 2020-05-10, Ian Collins wrote: > temporary object. You need to update printVector to take a const > reference parameter: > void printVector( const Vector3 &vec) And that's what you want anyway, since you surely don't intend to let printVector() modify the vector it prints. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 01:32PM -0700 On 5/10/2020 5:07 AM, Bonita Montero wrote: > Mutexes with spinning are just a stupid idea and are not thought > to the end in the sense i told. An adaptive mutex is a good idea. Any kernel calls that can be avoided is great! Btw, you should tell the Linux guys that they made a big mistake. ;^) |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 10:24AM +0200 >> that spinning isn't necessary. > Its almost as if you do not understand why they were created in the > first place? To avoid the slow-path! But as I said the slow path is very unlikely to happen if you're in the situation where locks are only held a very short time. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 07:45AM +0200 > Which is what my recursive spinlock does; Bonita should try looking at > the fucking code before commenting. Then don't talk about a spinlock. Spinlocks aren't composite-locks that incorporate kernel-waiting but just spinning. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 10 02:55PM +0200 > No research ... benchmarks ... theoretical calculations ... links > to such ... just *stupid* and *period*. And that for cascade of posts. > Yawn. I told you why. Try to argue against that. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 11 02:40PM -0700 > Why should I argue when there is only groundless nonsense? > Nonsense without ground should be dismissed on the ground > of its groundlessness ... nothing to argue there. No, you shouldn't argue. But I suggest that a better way not to argue is simply not to reply. Please stop feeding the troll. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 07:56AM +0200 > An adaptive mutex is a good idea. Any kernel calls that can be avoided > is great! Btw, you should tell the Linux guys that they made a big > mistake. ;^) Yes, they made a mistake. Try to argue against that: if a lock is held a so small time that spinning might succeed there's such a low likehood of a collision that spinning isn't necessary. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 11:48PM -0700 On 5/10/2020 10:56 PM, Bonita Montero wrote: > Try to argue against that: if a lock is held a so small time that > spinning might succeed there's such a low likehood of a collision > that spinning isn't necessary. Its almost as if you do not understand why they were created in the first place? To avoid the slow-path! |
| 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