C/C++ is very difficult to port and test: programs written in these languages need to be tested on specific platforms. One solution would be to develop a virtual platform model and develop a separate VM engine for it (this is what is used to support a Linux-like system in 100% pure _javascript_; not only this is not inefficient, but it is in fact very fast and removes lot of necessary tests: it's easier to develop and test the VM itself than tons of candidate programs using it; on such modelized virtual platform, there is no logner any complex portability problem: programs are specifically tuned for that single virtual platform, which is then emulated and recompiled ion a true local machine using all sorts of possibile optimizations that zillions of initial programs don't have to manage themselses; this is the same reason of the success of Java: one code running everywhere with the best performances for each target machine; the JIT compiler becomes an integrant part of the VM supporting the same virtual machine model with very precisely defined goals and rules; the same could apply to Lua and applies already to _javascript_, but C/C++ lays far behind). C/C++ should have been abandonned since long for application development, but only for implementing VMs (and in that case you don't even need all the complexity of C++, a "stronger C" is enough for most part of the code, plsu a some native assembly code for the specific platform for which the VM is built).
I'm not defending C++, it's not my favorite language to begin with, and it's gotten too freaking complicated, template programming is quite bizarre, and it takes years to get proficient in C++, but for some low level (embedded) programming there are no good alternatives (yet). Java won't run on a $1.00 processor that has to run for years on a battery, but C++ can if you know which things to avoid. Java is useless for low level/driver development, and it's a resource hog. There is no one size fits all programming language.
Gé
Philippe:
On Sat, May 16, 2020 at 1:48 AM Philippe Verdy <verdyp@gmail.com> wrote:
> THat's the trick they used to avoid bugs: overaligning when it is not needed.
No, they did not. malloc(3) states "The malloc() and calloc()
functions return a pointer to the allocated memory, which is suitably
aligned for any built-in type.". They MUST overalign. C malloc is not
a pink unicorn whose mission is to somehow predict what you are using
the memory for, its mission is to obey the rules.
> But using a static alignment to some fixed multiple (e.g. 8), which porove to be insufficient (e.g. for requesting pagesize alignment).
Again, nothing says malloc must be able to return page aligned more.
AAMOF, nothing in the C standard requires the processor to have
"pages", I've worked with machines without pages, and I'm nearly
convinced you have too. Do you ever read the language definitions?
Francisco Olarte.
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org
