41–50 of 107 posts
Earlier quoted context omitted.
You and I can't possibly have the same definition of DMA. It is essential to low latency data communication both in the embedded and server domain.
"Dynamic memory allocation", not "direct memory access".
Earlier quoted context omitted.
I don't think it is sad. You explained why it is necessary, C++ has been around for a while, is/was great but there are now languages that can compete in terms of performance with fewer drawbacks in terms of security and undefined behavior. If you're starting from scratch, it is important to strongly consider which language and platform best suits your needs. Anecdotally, a lot of companies have found success using n…
> there are now languages that can compete in terms of performance Such as?
Earlier quoted context omitted.
You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ? Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.
I don't think C++ supports variable length arrays? So, if you want to allocate N objects, where N is not known at compile time, (I think) you have to use heap allocation anyway. Normally I just use vector , and call reserve() if I feel like extra performance-y. Sure, it's much slower than C99-style variable length arrays, but 99% of the time it's still fast enough. More importantly, it plays nice with other C++ funct…
VLAs are not part of the standard but GCC supports them. Clang however does not, at least not without a compiler flag I think.
[deleted]
auto start = std::chrono::system_clock::now();[deleted]
Earlier quoted context omitted.
You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ? Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.
I don't think C++ supports variable length arrays? So, if you want to allocate N objects, where N is not known at compile time, (I think) you have to use heap allocation anyway. Normally I just use vector , and call reserve() if I feel like extra performance-y. Sure, it's much slower than C99-style variable length arrays, but 99% of the time it's still fast enough. More importantly, it plays nice with other C++ funct…
Earlier quoted context omitted.
You mean C++ programmers allocate n object on the heap even when its lifetime is the same as the scope of the containing block ? Unless its such a large huge object that stackoverflow is a possibility I cant imagine why would one do that.
I don't think C++ supports variable length arrays? So, if you want to allocate N objects, where N is not known at compile time, (I think) you have to use heap allocation anyway. Normally I just use vector , and call reserve() if I feel like extra performance-y. Sure, it's much slower than C99-style variable length arrays, but 99% of the time it's still fast enough. More importantly, it plays nice with other C++ funct…
And, yeah its disappointing C99 arrays did not make it to C++, one can use alloca to live a little dangerously, better to wrap it so that it allocates on the heap only if more than a certain size has been asked for. Too bad there is no portable way to find out how much stack space does the current process still have. There should have been a system call for that.