3 ms·
There is a fallacy in taking enterprises that might be done "eventually" as being already completed and ultimately proven. What you quote is not disagreeing wi
by jstimpfle 7y ago
There is a fallacy in taking enterprises that might be done "eventually" as being already completed and ultimately proven.
What you quote is not disagreeing with what I was saying at all.
Quick look at the GCC link you posted:
Project Status (last updated 06/2009)
Phase 1 of gcc-in-cxx now complete (06/2009)
gcc-in-cxx completes bootstrap as of 03/2009
Seriously.
> "Provide C symbols as specified by the standards, but take advantage and use C++ language facilities for the core implementation."
Sure, now let's look at the code
https://github.com/llvm/llvm-project/blob/master/libc/src/ https://github.com/llvm/llvm-project/blob/master/libc/src/
Oh, it's not even a completed project. Here is stdio
https://github.com/llvm/llvm-project/blob/master/libc/src/stdio https://github.com/llvm/llvm-project/blob/master/libc/src/st...
stdio/ for example has just 3, mostly empty files: file.h, fwrite.cpp, fwrite.h. Last commit was 8 days ago. It's not a project to be taken as serious evidence for any argument.
You need to stop selling things that might never exist, or have long been dead in the water.
Apart from that, I've looked at 10 files and the only use of C++ I've seen was some namespacing (that just makes the code more verbose IMO; YMMV).
It's essentially C, the thing you're leading a religious war against.
In this day and age where it's common knowledge that we're all living in opinion reinforcement filter bubbles, it should be possible to expect from people to at least quickly skim the citations they provide.
- pjmlp 7y agoAh so we are back into the comp.lang.c days. Reply will come in due time.
- jstimpfle 7y agoJust back in times where we try at least not to back up claims with citations that can't withstand a 1-minute check.
- deleted 7y ago[deleted]
- jstimpfle 7y agoGoing over that LLVM-libc website again, this is absolutely hilarious. It reads like a bucket list of grandiose features, done by a Junior developer with lots of motivation, but with no idea that these add costs and complications, and no idea what's really important. The Git repo matches that impression. There are neatly arranged directories containing CMakeLists and fuzzing stuff and READMEs and what not. Is there a good reason why strcpy() needs to be fuzzed? Some directories contain a lot of header files with 20 lines of comment junk and namespace junk, surrounding a single line that contains a function signature. And looking at the code, it seems not even 1% of the actual functionality is implemented. I will be extremely surprised if this project gets ever completed.
- pjmlp 7y agoSometimes I do make the failure of doing a hasty reply, should know better. Trying to reduce the amount of C code in the world since 1992, sometimes I win, sometimes I loose, in what concerns me, the outcome looks pretty much positive to me outside embedded development and FOSS UNIX clones. As for the whole C compilers written in C++ thread, a proper reply will follow up rest assured, even if takes a couple of weeks like last time.
- deleted 7y ago[deleted]