Re: Emacs contributions, C and Lisp

[John Yates]

On Thu, Feb 20, 2014 at 6:53 PM, David Kastrup <address@hidden> wrote:

My guess is that switching off optimization, you'd not be all that bad.

I already assumed that a magic "give me completions" flag would turn off optimization and code generation.  I am concerned about process startup, I/O (even if the required headers are already in the block cache), lexing, parsing and semantic analysis.  Remember, we are talking C++ here, not C.  Trivial programs pull in mega headers (stl, boost, etc) with increasing use of such wonderful language features as "Turing-complete template meta-programming".

"Fails to acknowledge" is not the same as "is not going to accept".

Let me state that more clearly.  Correct me if I am wrong but I believe that RMS has never done any C++ development.  As such he has little appreciation for the value C++ developers may attach to tools with deep knowledge of C++ semantics.

Well, given the right article author.  If we are talking about the

conclusions of Phoronix, see
<URL:http://draketo.de/light/english/free-software/phoronix-distort-results-gcc-llvm-clang-amd-vishera>.

I used the word "competing" to mean "offering similar service or functionality".  I did not intend to bring in any notion of relative performance of generated code.

Splitting parser and code generator into separately
usable components...

That is not the issue.  Given that the gcc backend can be linked with a number of different frontends I assume that stubbing off a few functions would provide a free-standing frontend.  OTOH if gcc wants to "compete" with clang in the tools space it will have to provide interfaces for querying and manipulating its symbol table and intermediate representation.  That is some rather heavy lifting for a codebase not designed from the outset with that goal in mind

 

Even when that has been done, one still has to do an actual
implementation and _then_ have to see whether under the constraints of
the current implementation the hoped-for advantages are actually as
envisioned, and the accepted drawbacks don't turn out larger than
expected.  And there is not much of an option to turn back the clock,
either.

Do I understand you correctly here?  Did you just conceded my original point, namely that while RMS does not want us to dissipate the pent up demand that could drive gcc into the tool space, that transformation most likely will never happen?  IOW emacs-based C++ developers are denied valuable tools that are becoming ever more common in other development environments based on a chimera.

/john