5 ms·
> Within C++ is a smaller, simpler, safer language struggling to get out.” - Bjarne Stroustrup Ah, yes. I think they called it "C".
by seanhandley 8y ago
> Within C++ is a smaller, simpler, safer language struggling to get out.” - Bjarne Stroustrup
Ah, yes. I think they called it "C".
- frutiger 8y agoI'm having some difficulty imagining that C is safer than C++.
- kgabis 8y agoWell, it is. Every f*up you can have in C, you can also have in C++.
- mhh__ 8y agoOnly if you write unidiomatic (Read crap) C++. In modern C++ it is very much possible to write fast and safe code, but the tradeoff is now put into the amount of stuff the developer needs to know to be productive (Which in my experience isn't as bad as people like to go on about on here/reddit, even if it still pretty shoddy)
- smallstepforman 8y ago> Only if you write unidiomatic (Read crap) C++. Thats a bit unfair. A recent headache for my C++ project was mixing audio buffers. The buffers are cached to avoid repeated reads, the channel count differs, the sample rate can differ, the output rate can differ, and mixing has gain limiters applied etc. Lots of buffers, lots of copying, lots of boundary cases (eg. sample #1 doesnt start until t=100ms, sample #2 ends before sample #1, etc). I struggled for days getting all the buffer copying right (raw pointers to many interrim buffers). You may think that my problems were due to using "crap c++ in unidiomatic way". However, I challenge you to find a better, and as efficient method to accomplish the same goal. The end MixAudio() function looks like plain old C code from the early 80's, but how else can you tackle this problem in a modern way?
- zvrba 8y ago> I struggled for days getting all the buffer copying right (raw pointers to many interrim buffers). It seems like you struggled with math (indexing logic) rather than C++. > how else can you tackle this problem in a modern way? You could try to write an iterator that takes into account sample rate, channel count, etc. That way the logic for handling buffer formats and iteration over samples is encapsulated into a single reusable component.
- mhh__ 8y agoI'm not entirely sure - only just learning audio programming atm, but the way to approach would be to encapsulate then use encapsulation and ranges/iterators. Efficiency should be roughly the same, especially given that you can optimise loops (and other code) with just as much access.
- Koshkin 8y agoSure, but with C++ there's fewer reasons to do so.
- anderspitman 8y agoStroustrup likes to say it's harder to shoot yourself in the foot with C++, but when you do it tends to blow off the whole leg.
- wues 8y agoC compatibility was the very reason for which C++ is bigger, more complicated and less safe than a similar language not compatible with C could be.
- wbl 8y agoReally? C++ accidentally has a Turing complete templating layer. I suppose one could point to Common Lisp but if you think that is simple....
- Const-me 8y agoObjective C and D both have excellent C compatibility. C# has very good one. I think all 3 languages are easier to use.
- wues 8y agoThey all may have excellent C compatibility, but this is not the point. The point is that without C compatibility C++ could be smaller and simpler, and yet still meeting the same goals and covering the same use cases. Objective C has Smalltalkish object system glued to C base. Fundamental C++ techniques like RAII not possible there. D has GC. C# runs in a VM. I would not call a language with any of those features very similar to C++. OTOH if not for C compatibility we would not have this discussion, since we would most likely never heard of C++.
- deleted 8y ago[deleted]
- pornel 8y agoJokes aside, I think D is it. And with the `-betterC` switch it even has replicated that C subset, but without actual legacy baggage.