Pavel
I've also been on some meetup last week, where a guy was showcasing a C and C++ compiler for embedded (which they developed probably from before I was born), I would guess that one wouldn't even support any of these things by default
B
I have unironically seen people suggesting others to go learn Haskell to better understand C++ templates.
B
Well, if you do embedded, don't use any templates from STL. Most likely this would be the C++ you want to use https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
Don't use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity. ...academic masturbation. That's Haskell .
Rose
Another one bites the dust...! Banned Anupama. Reason: telegram.me link
Abbasi
Yeah templates help with readability 🤣 . All those things you mentioned also generally increase binary sizes by inlining more code. A thesis is not a "kind of a book". None of the points you mention also point to C++ having "higher performance", whatever that is, compared to C. So yeah please give me a more detailed explanation.
When you perform tasks at compile-time then there will typically be no need to do them also at run-time => higher performance Appropriate use of modern C++ and less code pave the way for the compiler to have better optimizations => smaller binary size These plus classes, generic programming, inheritance, and more, make the code more readable, less error prone and easily maintainable. inlining exists in both C and C++. Who said you need to make all functions inline? (PS: There's, however, a flag to disable implicit inlining - used typically for measuring purposes) You can read the thesis (138 pages): Modern C++ in Embedded Systems by Marcell Ferenc Juhász.
Gito
hello guys
Gito
im into cpp
klimi
very informative 👍
Mk
Hello guys i need to allocate a memory i have tired in various way but i am not able to allocate a memory can anyone help in this
Mk
C++
Gito
Anyone into game dev?
Modex
Anyone into game dev?
Yeah I am, how about you?
......(▼ヘ▼#) انور
Is there anyone in ML?
Pavel
Is there anyone in ML?
That's a meta-question. Why do you ask?
......(▼ヘ▼#) انور
That's a meta-question. Why do you ask?
I'm working on something related and wanted to know if there’s someone I can talk to.
Ludovic 'Archivist'
I'm working on something related and wanted to know if there’s someone I can talk to.
Then, unless it is specifically also related to C++ please refrain, otherwise please refrain from asking and just talk
Rounak
Is there anyone in ML?
Your project name?
Never Spam Bot
انور (▼へ▼メ) is now approved by the group admin and can send messages without any restrictions Yes, it involves C++. I’m working on integrating a C++ backend for a Machine Learning model. I’m trying to either run inference using a C++ implementation or call a pre-trained Python model from C++. Has anyone here done something similar or have tips on the best approach? See spam? Quote the spam message in the group and reply with /spam
Tirupati
Hey guys does anyone is having C programming deep course please provide
Tirupati
Yes
Anonymous
me too lol
Ludovic 'Archivist'
Hey guys does anyone is having C programming deep course please provide
Please before learning with K&R learn with another book Like Jens Gustedt Modern C
Ludovic 'Archivist'
Please provide the books
Jens Gustedt's is freely available from his page on the INRIA's gitlab
Ludovic 'Archivist'
why?
K&R is great to practice implementing things in C, but it doesn't quite match the current expectations of code quality, being from a time when a 15k LoC project was considered a massive project
Ludovic 'Archivist'
It was from a time when making a variable name more than 8 character was an actual problem due to memory constraints
Ilírio
And what about C: A Modern Approach, is it a good book?
Vlad
To not use abstractions for the sake of abstractions
Vlad
Contrary to a popular belief, wrong abstractions make your code harder to read and follow what's happening. Not easier
Vlad
tl;dr: do not use them just because you have read about them yesterday and you think "they are so cool"
Vlad
You are still limited to not use stl, exceptions, etc though
Ludovic 'Archivist'
To not use abstractions for the sake of abstractions
The good approach is always to write it first, then make it work, then make it clean, then make it fast
Vlad
We are talking about different things. STL algos are good, excessive template masturbation is not
Ludovic 'Archivist'
Yes, always use standard algorithms, they are not more expensive than writing your own, and you can always use them through a container of void* to mimick the qsort drawbacks and advantages
Vlad
The good approach is always to write it first, then make it work, then make it clean, then make it fast
Latter might require proper architectural decisions from the very beginning
Vlad
Depending on your target hardware
Ludovic 'Archivist'
Latter might require proper architectural decisions from the very beginning
You would not have known those implications if you didn't run into the limitations. if you need a module rewrite, you probably would not have known
Ludovic 'Archivist'
Performance optimization only exists if you can measure it
Vlad
If you didn't bother to make an analysis in the beginning of course you would not
I'm gonna vibe code this bich and then see if it's enough
Ludovic 'Archivist'
If you didn't bother to make an analysis in the beginning of course you would not
In many cases, the analysis may not reveal the real sources of performance costs
Vlad
In many cases, the analysis may not reveal the real sources of performance costs
You have to know what's slow on your hardware from the start
Vlad
To not do it
Vlad
Or if you see something is slow amidst development you should measure it and alter the course of development
Vlad
Or if you see something is slow amidst development you should measure it and alter the course of development
Otherwise you have very high chances with having a slow mess you don't know what to do with
Vlad
And then you're fucked and do a complete rewrite
Vlad
Or ship what's there
Ludovic 'Archivist'
I know, which is why I measured and tested, and have code that is O(n) yet much faster than what it would have been being O(log log n)
Ludovic 'Archivist'
I do not trust human intuition of what is slow on the computer, I test things, measure and size. Guessing the architecture for speed before performance testing is just as harmful as assuming performance from preliminary considerations
Ludovic 'Archivist'
I am fine with implementing the same thing 3 times if that is what I need to have the performance I need
Rose
User Share².​ has 1/2 warnings; be careful! Reason: offtopic .
Vlad
Cosntexpr is not that special .
You can precalculate a lot of stuff, instead of using wonky code generators or wasting runtime and memory calculating it on startup
VEG
We use constexpr a lot in our C-style code
VEG
Also, a defer macro is a must have in C-like code https://veg.by/en/blog/2024/08/03/defer-macro/
Vlad
😢
Vlad
Is it up?
VEG
Yep, just checked
Vlad
Hmm. We’re having trouble finding that site. We can’t connect to the server at veg.by. If you entered the right address, you can: Try again later Check your network connection Check that Firefox has permission to access the web (you might be connected but behind a firewall)
B
Is it up?
I use DoH and it loaded just fine .
Vlad
My ukranian hohol firewall might have blocked it
VEG
Hmmm... https://web.archive.org/web/20250126133613/https://veg.by/en/blog/2024/08/03/defer-macro/ then
VEG
A bit of C++ in C-like code won't hurt =)
VEG
I'm also looking into using C++20 header units in C-like code, looks like a nice way to avoid traditional include hell and speed up build times without using something like precompiled headers.
B
You can precalculate a lot of stuff, instead of using wonky code generators or wasting runtime and memory calculating it on startup
It is up to your taste if you find a template heavy constxpr C++ code more preferable to preproc heavy pregenerated values C code, My point is that prebaking stuff is not something that is not doable in C . Hell duffs device is 2 years older than C++ itself . The blanket statements that he made claiming C++ as being more "maintainable", "readable", "performant", and having a "smaller binary size", are funny . Many find OOP ridden, 6 levels of inherence polymorphic C++ code harder to read and maintain than simple procedural C code . Yes C++ code is able to not to have inherence, polymorphism and etc, but in my personal experience people generally code C++ in this style since it is thought to them that abstraction to oblivion is the way . Problem with C++ is that it gives you a lot of syntactic sugar that has ability to make a mess of your code, the only thing that C has with a similar potential of code mess up is the preproc and that exists in C++ too though not used as much as in C . With binary size there is always a trade-off and to just say that C++ has smaller binary sizes is just wrong . It is even said in the paper he cited that, when you prebake, inline, (whatever you what to call it) stuff in comptime you are sacrificing storage for performance; binary size is a balance and where to balance it entirely depends entirely on the circumstances and the environment . Again prebaking stuff is not a impossibility in C programmers have been doing it since the 70s . And last is performance, reading the paper has proved to me again anyone "claiming X is faster than C" is comparing a piece of optimized code in their language to a non-optimized piece of C code . The paper even has a section comparing his implementation to a "fully optimized C code" and the results basically end up 1-1 . C++ can't get faster than C, best it can do is to get 1-1 to it . One thing it can claim is that more "readable" code can get better optimized in some cases compared to C, while that maybe true readability is not a objective universal measure .
Vlad
It is up to your taste if you find a template heavy constxpr C++ code more preferable to preproc heavy pregenerated values C code, My point is that prebaking stuff is not something that is not doable in C . Hell duffs device is 2 years older than C++ itself . The blanket statements that he made claiming C++ as being more "maintainable", "readable", "performant", and having a "smaller binary size", are funny . Many find OOP ridden, 6 levels of inherence polymorphic C++ code harder to read and maintain than simple procedural C code . Yes C++ code is able to not to have inherence, polymorphism and etc, but in my personal experience people generally code C++ in this style since it is thought to them that abstraction to oblivion is the way . Problem with C++ is that it gives you a lot of syntactic sugar that has ability to make a mess of your code, the only thing that C has with a similar potential of code mess up is the preproc and that exists in C++ too though not used as much as in C . With binary size there is always a trade-off and to just say that C++ has smaller binary sizes is just wrong . It is even said in the paper he cited that, when you prebake, inline, (whatever you what to call it) stuff in comptime you are sacrificing storage for performance; binary size is a balance and where to balance it entirely depends entirely on the circumstances and the environment . Again prebaking stuff is not a impossibility in C programmers have been doing it since the 70s . And last is performance, reading the paper has proved to me again anyone "claiming X is faster than C" is comparing a piece of optimized code in their language to a non-optimized piece of C code . The paper even has a section comparing his implementation to a "fully optimized C code" and the results basically end up 1-1 . C++ can't get faster than C, best it can do is to get 1-1 to it . One thing it can claim is that more "readable" code can get better optimized in some cases compared to C, while that maybe true readability is not a objective universal measure .
C++ can get faster than C in code that requires some degree of polymorphism
Vlad
Which in C is usually implemented through indirection and void*'s
Vlad
C++ has static polymorphism that is value based
B
C++ has static polymorphism that is value based
In C you use polymorphism i.e function pointer switch cases in times where you actually need to chose between functions in runtime static polymorphism doesn't work here . In other cases you just use normal functions based on the types you have . Did I misunderstand this ?
Vlad
For either structs that differ just by the type of a single field, container implementations, etc