Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94083 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-09-26 14:31 +0100 |
| Last post | 2016-10-15 13:46 -0700 |
| Articles | 20 on this page of 154 — 22 participants |
Back to article view | Back to comp.lang.c
Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 14:31 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 15:45 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 16:31 +0200
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:05 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 00:42 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 09:50 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 18:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 12:28 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 04:36 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 14:00 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 07:48 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 10:38 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 19:47 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:25 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:26 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 13:10 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 13:22 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 14:13 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 01:15 +0100
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-10-08 10:42 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 11:36 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 14:25 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 15:05 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:29 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 17:21 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 16:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:58 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:15 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:27 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 20:09 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:16 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 21:28 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:19 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 01:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-08 09:32 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:44 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:07 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 12:12 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:37 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 13:57 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 14:32 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 20:00 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-09 13:14 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 22:54 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 14:40 -0700
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 10:37 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 07:52 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 09:10 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 10:48 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 16:21 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:15 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:12 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:20 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 14:45 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:12 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 15:26 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 08:00 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:49 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 17:30 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 21:12 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:09 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 13:32 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 23:14 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:47 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:13 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 01:18 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:41 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 02:01 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:41 -0700
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-09-27 01:41 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-09-26 18:15 -0700
Re: Why I use gcc Gareth Owen <gwowen@gmail.com> - 2016-09-27 20:59 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 21:50 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 06:26 -0700
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-27 23:23 +0000
Re: Why I use gcc Noob <root@127.0.0.1> - 2016-10-08 00:12 +0200
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:11 -0400
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 10:58 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-08 07:07 -0700
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 21:44 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 09:48 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 13:52 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 14:47 +0200
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 15:18 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:38 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:21 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:17 +0200
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:52 -0700
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-09-30 02:00 -0500
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:18 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:46 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 09:11 -0700
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:33 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:13 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:30 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 08:29 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:11 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 21:43 +0100
Re: Why I use gcc raltbos@xs4all.nl (Richard Bos) - 2016-09-30 17:50 +0000
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:04 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:39 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:49 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 11:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:56 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:15 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-28 08:55 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:11 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:04 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 11:39 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-10 07:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 16:17 +0100
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-10 21:09 -0500
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 04:18 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 10:56 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 13:36 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 06:20 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 14:29 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 09:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 19:38 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-11 12:23 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-11 23:19 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 23:26 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-12 09:01 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 08:55 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-12 10:52 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 12:34 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-12 13:18 -0700
Re: Why I use gcc luser droog <luser.droog@gmail.com> - 2016-10-12 13:24 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-13 13:31 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 03:00 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-16 04:46 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 04:05 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 12:28 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-11 13:24 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 21:28 +0100
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-11 20:43 +0000
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-11 23:40 -0500
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:40 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:19 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 09:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:04 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 10:39 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 11:25 -0700
Re: Why I use gcc Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-10 17:05 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 14:46 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-15 13:39 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-15 13:40 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-15 13:46 -0700
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-11 13:36 +0100 |
| Message-ID | <ntimbs$7br$1@dont-email.me> |
| In reply to | #94704 |
On 11/10/2016 12:08, already5chosen@yahoo.com wrote:
> On Tuesday, October 11, 2016 at 12:57:03 PM UTC+3, Bart wrote:
>> We're talking about a program that translates one input file to an
>> output file. It's the simplest possible kind of application. What
>> 'proper environment' is necessary?
> Are you claiming that MS compiler installation is bloated? That's certainly true.
>
> Are you claiming that getting MS standalone compiler is tricky? That's certainly wrong.
I have to be able to run a compiler from anywhere via a call such as this:
system("c:/tcc32/tcc -c file.c 2>errors.tmp")
(But the string is built at runtime.)
That didn't work outside of the special command window needed by msvc.
> Just for sake of argument I installed Visual C++ Build Tools on my home desktop.
> http://landinghub.visualstudio.com/visual-cpp-build-tools
>
> The process was not quick due to huge download size and my not very fast Internet (several Mbits/s, I don't remember exactly how many), but certainly very straight forward. At the end of the process installer wanted to reboot, I refused and so far I don't see that compilation suffers because of it.
> Also download was not quick, but it was many times quicker than what would be expected according to disk space, occupied by the installation (~2.7 GB). Probably, their stuff compresses very well.
>
> Majority of the disk space (~1.5 GB) is occupied by directory "C:\Program Files (x86)\Windows Kits". Somehow, I think that I can delete it and it will not affect my ability to compile desktop applications targeting Windows 7 or older versions. But I didn't try it yet.
> Among the rest, it seems that most of space is taken by "universal" libraries, that I also don't need. Out of other irrelevant stuff, there are libraries for ARM (260 MB).
>
> So, yes, leaner installation package would be nice, but at least in my scenario, it's not a deal breaker.
Your link shows a smaller installation than I've seen for VS. Still,
when I tried it, it informed me I needed 4GB across all drives; I've
only got 2GB. Plus I don't want abuse my ISP with a 4000MB download all
in one go.
These things are collossal. My current compiler is 400KB plus
dependencies: interpreter 200KB, plus external assembler and linker,
currently 1MB for Nasm and 2MB for gcc's 'ld'. But I can also use a 47KB
linker with some tweaks, and a 130KB assembler with quite a bit of extra
work. Libraries that come with the compiler (as sources) are another 100KB.
I have in mind created a tight, compiled version of that compiler (so no
interpreter needed), that compiles all modules of a project directly to
an executable. About 0.5MB in total, and would probably run at 500Kloc
per second.
That's the kind of thing I would admire: small, tidy, simple, fast.
Downloading it would about 0.1 seconds.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-10-11 06:20 -0700 |
| Message-ID | <25f5e98f-b41d-484b-8597-e2363597d064@googlegroups.com> |
| In reply to | #94712 |
On Tuesday, October 11, 2016 at 3:36:37 PM UTC+3, Bart wrote:
> On 11/10/2016 12:08, already5chosen@yahoo.com wrote:
> > On Tuesday, October 11, 2016 at 12:57:03 PM UTC+3, Bart wrote:
>
> >> We're talking about a program that translates one input file to an
> >> output file. It's the simplest possible kind of application. What
> >> 'proper environment' is necessary?
>
> > Are you claiming that MS compiler installation is bloated? That's certainly true.
> >
> > Are you claiming that getting MS standalone compiler is tricky? That's certainly wrong.
>
>
> I have to be able to run a compiler from anywhere via a call such as this:
>
> system("c:/tcc32/tcc -c file.c 2>errors.tmp")
It is certainly possible and easy with MSVC as long as tcc is batch file that sets environment variables and then invokes cl.exe.
I'd guess that calling spawnle() with correct arguments will be few msecs faster. I don't know if few msecs are important in your case.
>
> (But the string is built at runtime.)
>
> That didn't work outside of the special command window needed by msvc.
>
> > Just for sake of argument I installed Visual C++ Build Tools on my home desktop.
> > http://landinghub.visualstudio.com/visual-cpp-build-tools
> >
> > The process was not quick due to huge download size and my not very fast Internet (several Mbits/s, I don't remember exactly how many), but certainly very straight forward. At the end of the process installer wanted to reboot, I refused and so far I don't see that compilation suffers because of it.
> > Also download was not quick, but it was many times quicker than what would be expected according to disk space, occupied by the installation (~2.7 GB). Probably, their stuff compresses very well.
> >
> > Majority of the disk space (~1.5 GB) is occupied by directory "C:\Program Files (x86)\Windows Kits". Somehow, I think that I can delete it and it will not affect my ability to compile desktop applications targeting Windows 7 or older versions. But I didn't try it yet.
> > Among the rest, it seems that most of space is taken by "universal" libraries, that I also don't need. Out of other irrelevant stuff, there are libraries for ARM (260 MB).
> >
> > So, yes, leaner installation package would be nice, but at least in my scenario, it's not a deal breaker.
>
> Your link shows a smaller installation than I've seen for VS. Still,
> when I tried it, it informed me I needed 4GB across all drives;
4 GB is pessimistic. In reality it occupies less than 3 GB. And, as mentioned above, after installation ~1.5 GB can be deleted.
> I've only got 2GB.
Too bad. That's enough for the final installation, but you will need more throughout the process.
> Plus I don't want abuse my ISP with a 4000MB download all
> in one go.
>
As I said above, judged by time it took and by speed of my Internet (not great :( ) the size of download is many times smaller that required disk space. I'd think, about 300 MB.
Besides. why do you care about problems of your ISP? You paid him to supply you with full-speed link 24/7.
> These things are collossal. My current compiler is 400KB plus
> dependencies: interpreter 200KB, plus external assembler and linker,
> currently 1MB for Nasm and 2MB for gcc's 'ld'. But I can also use a 47KB
> linker with some tweaks, and a 130KB assembler with quite a bit of extra
> work. Libraries that come with the compiler (as sources) are another 100KB.
>
> I have in mind created a tight, compiled version of that compiler (so no
> interpreter needed), that compiles all modules of a project directly to
> an executable. About 0.5MB in total, and would probably run at 500Kloc
> per second.
>
> That's the kind of thing I would admire: small, tidy, simple, fast.
> Downloading it would about 0.1 seconds.
>
> --
> Bartc
I agree that small size is nice, but in 2016 I really can't care if it's 0.5MB or 50MB. I don't download compilers every hour and when I do I can way a minute or two.
But 50MB are certainly better for me than 500MB.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-11 14:29 +0100 |
| Message-ID | <ntiper$iad$1@dont-email.me> |
| In reply to | #94716 |
On 11/10/2016 14:20, already5chosen@yahoo.com wrote: > On Tuesday, October 11, 2016 at 3:36:37 PM UTC+3, Bart wrote: >> That's the kind of thing I would admire: small, tidy, simple, fast. >> Downloading it would [take] about 0.1 seconds. > I agree that small size is nice, but in 2016 I really can't care if it's 0.5MB or 50MB. I don't download compilers every hour and when I do I can way a minute or two. > But 50MB are certainly better for me than 500MB. I wouldn't care so much either but IME big downloads also tend to have big problems! And I would rather find my away around a few dozen files to figure out what's wrong than a few thousand. (I downloaded Haskell the other day. And it had problems in locating its standard libraries. But the installation comprised 25,000 files!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-11 09:31 -0700 |
| Message-ID | <lninsyoniw.fsf@kst-u.example.com> |
| In reply to | #94712 |
BartC <bc@freeuk.com> writes:
[...]
> Your link shows a smaller installation than I've seen for VS. Still,
> when I tried it, it informed me I needed 4GB across all drives; I've
> only got 2GB.
Seriously? I've got more free space than that on my phone.
I could probably free up a bit more if I uninstalled the C and C++
development system. (Not exaggerating.) I don't know why you're
stuck with such a crippled computer, but it's hardly typical.
Multi-terabyte hard drives are available and reasonably priced.
> Plus I don't want abuse my ISP with a 4000MB download all
> in one go.
I know some people are stuck with slow and limited ISPs. On my
system such a download would take just a few minutes -- less once I
set up the new cable modem that's supposed to give me higher speeds.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-11 19:38 +0100 |
| Message-ID | <ntjbjd$ndc$1@dont-email.me> |
| In reply to | #94726 |
On 11/10/2016 17:31, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> Your link shows a smaller installation than I've seen for VS. Still, >> when I tried it, it informed me I needed 4GB across all drives; I've >> only got 2GB. > > Seriously? I've got more free space than that on my phone. > I could probably free up a bit more if I uninstalled the C and C++ > development system. (Not exaggerating.) I don't know why you're > stuck with such a crippled computer, but it's hardly typical. > Multi-terabyte hard drives are available and reasonably priced. If I was downloading a few dozen HD movies then that might be a good idea. But we're talking a compiler. Even with MSVC2008, all the exe and dll files in the bin directory (assuming all were essential) only come to 13MB. I could fit 150 copies in that 2GB! Anyway that's the free space on drive C. There's a drive D too, but I didn't stay with the install process long enough to find out if it was planning to ask me where I wanted it. Maybe it would download everything first (to a temporary folder on drive C!) before asking. >> Plus I don't want abuse my ISP with a 4000MB download all >> in one go. > > I know some people are stuck with slow and limited ISPs. So 50Mb/s is slow and limited these days?! But even working flat out it would take at least 10 minutes, which is a hell of a download. On the same connection, downloading lccwin would take 1 second, while one of mine might be near-instantaneous. (I don't know if that 4GB is the download size or the disk space needed. But it is still massive.) > On my > system such a download would take just a few minutes -- less once I > set up the new cable modem that's supposed to give me higher speeds. That's not the point. A program that translates the language specified in one of the C standards has no need to be anywhere near that size. Isn't part of the 'spirit' of C about being 'lean and mean'? Some people appear to have forgotten that. (Note that MSVC appears to be a C++ compiler.) -- Bart
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-11 12:23 -0700 |
| Message-ID | <59f3f7fa-d9bc-4633-a881-9e3830332e06@googlegroups.com> |
| In reply to | #94738 |
On Tuesday, October 11, 2016 at 1:39:01 PM UTC-5, Bart wrote: > Isn't part of the 'spirit' of C about being 'lean and mean'? Some people > appear to have forgotten that. (Note that MSVC appears to be a C++ > compiler.) C was designed so that a programmer with a simple compiler and an understanding of the target system could produce efficient code for that target system by exploiting features and guarantees which the target system naturally supported, without regard for whether support for those features and guarantees would be mandated on all systems. Unfortunately, modern C has lost sight of that--not only are compilers monstrously huge compared with what they used to be, but many of them no longer try to provide efficient access to features and guarantees which the underlying hardware could naturally support very cheaply.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-10-11 23:19 +0200 |
| Message-ID | <ntjl05$qha$1@dont-email.me> |
| In reply to | #94742 |
Le 11/10/2016 à 21:23, supercat@casperkitty.com a écrit : > C was designed so that a programmer with a simple compiler and an > understanding of the target system could produce efficient code for > that target system by exploiting features and guarantees which the > target system naturally supported, without regard for whether support > for those features and guarantees would be mandated on all systems. > > Unfortunately, modern C has lost sight of that--not only are compilers > monstrously huge compared with what they used to be, but many of them > no longer try to provide efficient access to features and guarantees > which the underlying hardware could naturally support very cheaply. The download of lcc-win is 21.4 MB compressed. That includes the preprocessor, the compiler, the linker, the debugger, all librairies some sample code, all headers (windows headers, standard headers), and the binaries of the IDE, the import librairies, the C library, everything you need to compile in a 32 and 64 bit x86 machine. All machine types are supported: floats, doubles, long doubles (80 bits) extra long doubles (128 bits) and "quad" doubles with 450 bits. 128, 64, 32 and 16 bit integers are provided. You can access the carry flag with intrinsic functions, or change the precision supported by the circuit, graphics are provided by the windows system. You can finely control the peripherals with mouse primitives, etc, you get a complete system. A small and powerful system, in the spirit of C.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-11 23:26 +0100 |
| Message-ID | <ntjotg$6d7$2@dont-email.me> |
| In reply to | #94748 |
On 11/10/2016 22:19, jacobnavia wrote: > Le 11/10/2016 à 21:23, supercat@casperkitty.com a écrit : >> C was designed so that a programmer with a simple compiler and an >> understanding of the target system could produce efficient code for >> that target system by exploiting features and guarantees which the >> target system naturally supported, without regard for whether support >> for those features and guarantees would be mandated on all systems. >> >> Unfortunately, modern C has lost sight of that--not only are compilers >> monstrously huge compared with what they used to be, but many of them >> no longer try to provide efficient access to features and guarantees >> which the underlying hardware could naturally support very cheaply. > > The download of lcc-win is 21.4 MB compressed. That includes the > preprocessor, the compiler, the linker, the debugger, all librairies > some sample code, all headers (windows headers, standard headers), and > the binaries of the IDE, the import librairies, the C library, > everything you need to compile in a 32 and 64 bit x86 machine. That must be lccwin64. lccwin32 is only a 7MB download. The MSVC I mentioned up-thread was also 32-bit. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-10-12 09:01 +0200 |
| Message-ID | <ntkn3t$6eu$2@dont-email.me> |
| In reply to | #94750 |
Le 12/10/2016 à 00:26, BartC a écrit : > That must be lccwin64. lccwin32 is only a 7MB download. Yes, and the download of lccwin64 contains those 7MB for the 32 bit version, and a duplicate set of 32 bit headers for windows 32 bit intefaces. The download for just the 64 bit fversion is then just 17MB
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-12 08:55 -0700 |
| Message-ID | <6f1108b7-efcc-4c0e-87a2-9b86c45dcb31@googlegroups.com> |
| In reply to | #94748 |
On Tuesday, October 11, 2016 at 4:19:27 PM UTC-5, jacobnavia wrote: > > Unfortunately, modern C has lost sight of that--not only are compilers > > monstrously huge compared with what they used to be, but many of them > > no longer try to provide efficient access to features and guarantees > > which the underlying hardware could naturally support very cheaply. > > The download of lcc-win is 21.4 MB compressed. That includes the > preprocessor, the compiler, the linker, the debugger, all librairies > some sample code, all headers (windows headers, standard headers), and > the binaries of the IDE, the import librairies, the C library, > everything you need to compile in a 32 and 64 bit x86 machine. > > A small and powerful system, in the spirit of C. Some checking in godbolt suggests that icc also seems to refrain from some of what I would regard as gcc's more dubious aliasing optimizations, though the documentation is unfortunately rather vague in what it does or does not promise. I should also mention that much as I dislike gcc's aliasing rules, I do appreciate that its in-line optimizer is generally "honest" about making in-line versions of a function work the same as a non-inline version, which makes it easier to see when optimizations go wrong. I wonder why compilers don't do a better job of documenting what they do and do not promise in various situations. It seems a waste to have a compiler include various flags to treat various constructs as defined behavior but not document them well enough to really make them be unambiguously *defined* behavior [the behavior might be "select in arbitrary fashion from among the following 3 actions: ...", leaving ambiguous the question of which exact action would be performed in a given scenario, but the fact that the behavior was defined as performing one of the indicated actions and *not* doing anything else would be unambiguous].
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-10-12 10:52 -0700 |
| Message-ID | <3bdac1ee-97d9-44ff-8c4f-1856a076cb2c@googlegroups.com> |
| In reply to | #94776 |
On Wednesday, October 12, 2016 at 6:57:58 PM UTC+3, supe...@casperkitty.com wrote: > On Tuesday, October 11, 2016 at 4:19:27 PM UTC-5, jacobnavia wrote: > > > Unfortunately, modern C has lost sight of that--not only are compilers > > > monstrously huge compared with what they used to be, but many of them > > > no longer try to provide efficient access to features and guarantees > > > which the underlying hardware could naturally support very cheaply. > > > > The download of lcc-win is 21.4 MB compressed. That includes the > > preprocessor, the compiler, the linker, the debugger, all librairies > > some sample code, all headers (windows headers, standard headers), and > > the binaries of the IDE, the import librairies, the C library, > > everything you need to compile in a 32 and 64 bit x86 machine. > > > > A small and powerful system, in the spirit of C. > > Some checking in godbolt suggests that icc also seems to refrain from some > of what I would regard as gcc's more dubious aliasing optimizations, though > the documentation is unfortunately rather vague in what it does or does not > promise. icc != lcc The least bloated variant of latest version of icc is "Intel System Studio 2017 Composer Edition" It gives you two options A - 1 large download (Download size 1163 MB) B - Fiddly. The second option starts by downloading initial package (21 MB) and than you proceed by downloading the rest. I the second phase, if you select only compiler, without IPP, MKL and other supposedly good stuff, which is irrelevant for other dick measurements context, then you are left with 379 MB. That includes both x86 compiler and x64 compiler. You can select only one of the two, they are approximately equal in size. Unlike in case of Microsoft, Intel download speed is slow, so, if your own Internet is reasonably fast, then there is a good chance that the process of download of icc will take longer than downloading of supposedly more bloated Microsoft build tools. By the way, I installed Microsoft tools on my home computer only for sake of argument. But after that I tried it (C++ rather than C) and so far I am impressed - it compiles faster that gcc 5.3 and generates faster output.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-12 12:34 -0700 |
| Message-ID | <06b94bb7-0215-4a20-a842-c72be588d862@googlegroups.com> |
| In reply to | #94784 |
On Wednesday, October 12, 2016 at 12:52:53 PM UTC-5, already...@yahoo.com wrote: > icc != lcc I love screen fonts which make lowercase l's look like uppercase I's. Grr... In any case, I think that much of the spirit of C is not only that it was designed to be processed with a simple compiler, but also that programmers targeting platforms where certain constructs behave in a documented predictable fashion should be able to use such constructs. How does lcc stack up in that regard?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-12 13:18 -0700 |
| Message-ID | <lnlgxtl3sd.fsf@kst-u.example.com> |
| In reply to | #94791 |
supercat@casperkitty.com writes:
> On Wednesday, October 12, 2016 at 12:52:53 PM UTC-5, already...@yahoo.com wrote:
>> icc != lcc
>
> I love screen fonts which make lowercase l's look like uppercase I's. Grr...
>
> In any case, I think that much of the spirit of C is not only that it was
> designed to be processed with a simple compiler, but also that programmers
> targeting platforms where certain constructs behave in a documented
> predictable fashion should be able to use such constructs. How does lcc
> stack up in that regard?
FYI, there's a comp.compilers.lcc newsgroup. A lot of the traffic is
about lcc-win, but there's discussion about the original lcc as well.
I know jacob participates there.
If you post there, you might want to be more specific about "certain
constructs".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-10-12 13:24 -0700 |
| Message-ID | <cae4d3df-7d45-4ca8-96e9-731520f08b49@googlegroups.com> |
| In reply to | #94791 |
On Wednesday, October 12, 2016 at 2:34:53 PM UTC-5, supe...@casperkitty.com wrote: > On Wednesday, October 12, 2016 at 12:52:53 PM UTC-5, already...@yahoo.com wrote: > > icc != lcc > > I love screen fonts which make lowercase l's look like uppercase I's. Grr... > > In any case, I think that much of the spirit of C is not only that it was > designed to be processed with a simple compiler, but also that programmers > targeting platforms where certain constructs behave in a documented > predictable fashion should be able to use such constructs. How does lcc > stack up in that regard? To a large degree, LCC is the best-documented C compiler in existence. Nearly the entire source code (c. 1990) is available in book form by the authors, as a "literate program" [ref Knuth]. Hansen and Fraser, A Retargetable C Compiler.
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <undisclosedUserid@gmail.com> |
|---|---|
| Date | 2016-10-13 13:31 -0600 |
| Message-ID | <ntonfa$efm$1@dont-email.me> |
| In reply to | #94742 |
On 10/11/2016 01:23 PM, supercat@casperkitty.com wrote: > On Tuesday, October 11, 2016 at 1:39:01 PM UTC-5, Bart wrote: >> Isn't part of the 'spirit' of C about being 'lean and mean'? Some people >> appear to have forgotten that. (Note that MSVC appears to be a C++ >> compiler.) > > C was designed so that a programmer with a simple compiler and an > understanding of the target system could produce efficient code for > that target system by exploiting features and guarantees which the > target system naturally supported, without regard for whether support > for those features and guarantees would be mandated on all systems. > > Unfortunately, modern C has lost sight of that--not only are compilers > monstrously huge compared with what they used to be, but many of them > no longer try to provide efficient access to features and guarantees > which the underlying hardware could naturally support very cheaply. > Too many libraries, the world is mortally infected with DLL-syndrome. Too many dependencies on other libraries, especially graphics support libraries. [Straying a bit, how hard is it to build a standalone statically-linked executable these days? Serious question, haven't built a C program since C++ on Windows in the late '90s, looking to build a module with zero dependencies beyond stdlib and stdio, hopefully xlib if that's what they call it these days.] -- http://totally-portable-software.blogspot.com [Sat Sep 03: "Associative Storage and Everything Everywhere"]
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-16 03:00 -0700 |
| Message-ID | <efe51442-84dd-44c6-84ba-db4d5cedc703@googlegroups.com> |
| In reply to | #94842 |
On Thursday, October 13, 2016 at 8:32:19 PM UTC+1, crankypuss wrote: > On 10/11/2016 01:23 PM, supercat@casperkitty.com wrote: > > [Straying a bit, how hard is it to build a standalone statically-linked > executable these days? Serious question, haven't built a C program > since C++ on Windows in the late '90s, looking to build a module with > zero dependencies beyond stdlib and stdio, hopefully xlib if that's what > they call it these days.] > Baby X was designed to get round that problem. The original idea was that you would drop all the files into one directory and simply type gcc *.c -lx11 and get an executable. But the need to support MS Windows and the fact that audio support for X isn't in yet have forced a bit of a dilution of that for now. I'm also getting it ready for the Apple OS X bindings. But it's still designed to be shipped as source with the application-level code, not compiled as a library and linked.
[toc] | [prev] | [next] | [standalone]
| From | crankypuss <undisclosedUserid@gmail.com> |
|---|---|
| Date | 2016-10-16 04:46 -0600 |
| Message-ID | <ntvlvu$fci$1@dont-email.me> |
| In reply to | #94914 |
On 10/16/2016 04:00 AM, Malcolm McLean wrote: > On Thursday, October 13, 2016 at 8:32:19 PM UTC+1, crankypuss wrote: >> On 10/11/2016 01:23 PM, supercat@casperkitty.com wrote: >> >> [Straying a bit, how hard is it to build a standalone statically-linked >> executable these days? Serious question, haven't built a C program >> since C++ on Windows in the late '90s, looking to build a module with >> zero dependencies beyond stdlib and stdio, hopefully xlib if that's what >> they call it these days.] >> > Baby X was designed to get round that problem. > > The original idea was that you would drop all the files into one directory > and simply type gcc *.c -lx11 and get an executable. But the need to > support MS Windows and the fact that audio support for X isn't in yet > have forced a bit of a dilution of that for now. I'm also getting it ready > for the Apple OS X bindings. > > But it's still designed to be shipped as source with the application-level > code, not compiled as a library and linked. > Well, on linux there's something called the frame-buffer, presumably there is *some* method of getting one's mitts on the pixel device and a mouse and a keyboard, though I don't know the details yet. -- http://totally-portable-software.blogspot.com [Sat Sep 03: "Associative Storage and Everything Everywhere"]
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-16 04:05 -0700 |
| Message-ID | <a82d193d-bc24-4560-b5ed-12fc623a7564@googlegroups.com> |
| In reply to | #94918 |
On Sunday, October 16, 2016 at 11:50:00 AM UTC+1, crankypuss wrote: > On 10/16/2016 04:00 AM, Malcolm McLean wrote: > > On Thursday, October 13, 2016 at 8:32:19 PM UTC+1, crankypuss wrote: > > Well, on linux there's something called the frame-buffer, presumably > there is *some* method of getting one's mitts on the pixel device and a > mouse and a keyboard, though I don't know the details yet. > XCB is the low-level interface to the X window system. Currently Baby X doesn't use it, effectively what Baby X does is provide a similar interface, then support it through Xlib calls, which probably revert back to XCB. So eventually I'll probably strip out all xlib calls. But that's not a current priority.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-11 12:28 -0700 |
| Message-ID | <lnk2den0qz.fsf@kst-u.example.com> |
| In reply to | #94738 |
BartC <bc@freeuk.com> writes:
[...]
> That's not the point. A program that translates the language specified
> in one of the C standards has no need to be anywhere near that size.
>
> Isn't part of the 'spirit' of C about being 'lean and mean'? Some people
> appear to have forgotten that. (Note that MSVC appears to be a C++
> compiler.)
I'm fairly sure it functions both as a C compiler and as a C++ compiler,
depending on how you invoke it. (To prove this, you should be able to
compile a C program containing the declaration `int class;`.)
In any case, your point seems to be that MSVC is bloated. You're
probably right. The shortage of disk space on your personal system
isn't really relevant to that point. (If I had that little free space on
my system, I'd be doing something about it, but your own system is of
course your concern.)
What I fail to understand is what you hope to accomplish by complaining
about the size of MSVC here.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-11 13:24 -0700 |
| Message-ID | <293a9119-9575-412a-ae3d-891f3f86fc41@googlegroups.com> |
| In reply to | #94743 |
On Tuesday, October 11, 2016 at 4:27:38 PM UTC-3, Keith Thompson wrote: > BartC writes: > [...] > > That's not the point. A program that translates the language specified > > in one of the C standards has no need to be anywhere near that size. > > > > Isn't part of the 'spirit' of C about being 'lean and mean'? Some people > > appear to have forgotten that. (Note that MSVC appears to be a C++ > > compiler.) > > I'm fairly sure it functions both as a C compiler and as a C++ compiler, > depending on how you invoke it. (To prove this, you should be able to > compile a C program containing the declaration `int class;`.) > > In any case, your point seems to be that MSVC is bloated. You're > probably right. The shortage of disk space on your personal system > isn't really relevant to that point. (If I had that little free space on > my system, I'd be doing something about it, but your own system is of > course your concern.) > > What I fail to understand is what you hope to accomplish by complaining > about the size of MSVC here. Microsoft has C and C++ compilers. The C compiler is not 100% C99/C11 compatible. You can set at the project which one do want to use. It's easy to switch. With Visual C++ 2015 you can use clang front end and compile C99/C11. You can debug as well.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web