51–60 of 77 posts
Having clang/gcc, or any other parser, implement that is of course impossible, they are too conservative and would rather die than to implement modern helpful tools.
Earlier quoted context omitted.
Not for C++ code generated by whole program optimizing compilers. Your "human entered" is doing the heavy lifting. Now that AI is writing code your assertion might be on shaky ground.
> Not for C++ code generated by whole program optimizing compilers. I'd be quite surprised if an optimizing compiler generated C++ code somewhere in its pipeline!
Earlier quoted context omitted.
> Not for C++ code generated by whole program optimizing compilers. I'd be quite surprised if an optimizing compiler generated C++ code somewhere in its pipeline!
C++26 reflection?
Earlier quoted context omitted.
Not for C++ code generated by whole program optimizing compilers. Your "human entered" is doing the heavy lifting. Now that AI is writing code your assertion might be on shaky ground.
> Not for C++ code generated by whole program optimizing compilers. I'd be quite surprised if an optimizing compiler generated C++ code somewhere in its pipeline!
https://felix-lang.github.io/felix/
Ignore the 'scripting' language claim.
Earlier quoted context omitted.
> Not for C++ code generated by whole program optimizing compilers. I'd be quite surprised if an optimizing compiler generated C++ code somewhere in its pipeline!
Take a look at Felix. https://felix-lang.github.io/felix/ Ignore the 'scripting' language claim.
I do have to wonder though - do you know what proportion of the C++ compiler time is spent parsing your generated C++ code vs. optimizing it?
> if (!line.accept('[').isEmpty() ) // [section] header. Is this really ergonomic?
> StringView has no operator bool, so a successful match reads as !scanner.accept('=').isEmpty(). Noisier than returning a bool, but the matched text comes back with the answer instead of requiring a second call to go get it.
Clearly there is a second call, it's the call to isEmpty. Plus, the actual text is lost in this particual example (though we know what it was).
An actual ergonomic way of using this would set things up so that the INI parser's inner code could be written something like this:
bool success =
(name = trim(acceptUntil('='))) &&
accept('=') &&
accept(Space) &&
(property = acceptAll());Earlier quoted context omitted.
I think the second-hardest thing is to accept that CS spent decades optimizing parsing algorithms and grammars, and this is still a significant part of CS curricula in many places. But the practical reality is that parsing is almost never a bottleneck. If what you're parsing is within the capacity of humans to interact with (so in the range of tens of kilobytes), a grammar that requires an O(N^2) parser is totally fi…
I don't think it is difficult to accept that fundamentals should be taught. We spend years learning basic arithmetic like the addition of integers. You could very well argue that there is no need for that either because everyone has a calculator app on their phone. This is how dark ages begin.
A parser/compiler could obviously be improved with an LLM (AI!) to suggest improvements to invalid input. That is actually a super good use case of LLM/AI. Having clang/gcc, or any other parser, implement that is of course impossible, they are too conservative and would rather die than to implement modern helpful tools.
FORTH parsers are ultra simple - get the next space-separated token, if it is a number, push it on the stack, otherwise it's a word - look it up in the dictionary and (if it exists there) execute it.