Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BartC <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Preprocessor Overheads
Date: Tue, 7 Feb 2017 11:26:55 +0000
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <o7caqm$tle$1@dont-email.me>
References: <kfnmve5d7im.fsf@x-alumni2.alumni.caltech.edu> <efhfqfFhgsiU4@mid.individual.net> <o705ji$j97$1@dont-email.me> <lnshnw5mmc.fsf@kst-u.example.com> <o709ht$5be$1@dont-email.me> <87o9ykjfhr.fsf@bsb.me.uk> <o70l4l$llq$1@dont-email.me> <87a8a3jpeo.fsf@bsb.me.uk> <o727l2$p2s$1@dont-email.me> <87r33fhxy6.fsf@bsb.me.uk> <o72p26$sr3$1@dont-email.me> <540a9cpdgag09bas7fll08ianoja8sipcs@4ax.com> <o73143$p69$1@dont-email.me> <efkldcFh1v7U3@mid.individual.net> <o739fr$kja$1@dont-email.me> <o74too$4rk$1@dont-email.me> <o755v1$2ii$1@dont-email.me> <o78091$iuj$1@dont-email.me> <o789fe$lgn$1@dont-email.me> <efpt8iF1d9uU2@mid.individual.net> <o78hij$hnr$1@dont-email.me> <o79c7j$cb9$1@dont-email.me> <o79pnp$ra8$1@dont-email.me> <791b2540-1353-4ffa-95d5-98e3eaf66b65@googlegroups.com> <o79s53$3p8$1@dont-email.me> <d215e0d6-44de-4885-b68d-220446ddb644@googlegroups.com> <o7a1ti$ocg$1@dont-email.me> <cdb001aa-91d7-49c1-9c25-7c340aa3eb90@googlegroups.com> <o7c21j$13f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 7 Feb 2017 11:25:10 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="80dff8dbed11b5e5226231c8dfc6b880"; logging-data="30382"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+58mX5ZQgv2FgVFvtrVibF"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
In-Reply-To: <o7c21j$13f$1@dont-email.me>
Cancel-Lock: sha1:s6oJucIyuD6DTGRx8NAEGAXXyQw=
Xref: csiph.com comp.lang.c:103349

On 07/02/2017 08:57, David Brown wrote:
> On 06/02/17 17:10, supercat@casperkitty.com wrote:

> If you were writing a new compiler, it would be worth considering
> writing it "the Windows way" to be efficient at running on Windows - and
> it could also be efficient at running on Linux.  But it takes a lot more
> development work - that's why people prefer making such systems "the
> Unix way" and accepting that they will be less efficient on Windows.
> When the llvm project was started, the developers concentrated on the
> new part - the middle of the toolchain.  They used an existing C and C++
> front-end (from gcc), and they used an existing assembler and linker
> (from binutils).  This was much easier, safer, more modular, more
> scalable and more flexible than trying to write a Windows-style "do
> everything" tool.

Go:

"We considered using LLVM for gc but we felt it was too large and slow 
to meet our performance goals." [https://golang.org/doc/faq]

No mention of OS. (I looked at llvm myself years ago, and even then, 
there were 44 different /sets/ of documentation to peruse if you wanted 
to try and understand it. And I believe it required you to use C++. An 
unattractive option overall.)

-- 
Bartc