Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140005 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2019-01-20 00:03 +0000 |
| Last post | 2019-01-21 00:13 -0600 |
| Articles | 20 on this page of 160 — 17 participants |
Back to article view | Back to comp.lang.c
Compiler tests Bart <bc@freeuk.com> - 2019-01-20 00:03 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-20 16:52 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-20 10:27 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 12:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 13:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 15:02 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:31 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 21:40 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 22:41 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 00:39 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 00:36 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-21 16:33 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 11:58 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 04:15 -0800
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-22 07:53 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 01:15 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 12:00 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-24 08:13 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 13:30 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 08:22 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:23 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 14:42 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 14:17 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:46 -0800
You guys really, really need to get a room (Was: Compiler tests) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-24 14:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 09:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:49 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:31 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 14:38 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 15:15 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 16:05 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 16:39 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:51 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 00:16 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 08:43 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:31 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 17:49 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-23 11:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 11:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:35 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 15:49 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 17:42 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 03:18 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 11:11 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 12:18 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 13:56 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 10:55 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:07 +0000
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 04:29 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:52 +0000
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-22 05:04 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:18 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:45 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:35 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 15:10 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 17:30 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 23:02 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 23:14 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 15:45 -0800
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:57 -0600
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 16:36 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 01:37 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 18:53 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:42 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:22 +0100
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:52 -0500
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 15:13 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 14:33 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 07:30 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:17 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:29 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 21:50 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 10:45 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 11:55 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 13:58 +0100
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-24 05:07 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:10 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:51 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 17:32 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-24 19:07 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 20:14 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 22:24 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 22:46 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 12:34 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 01:01 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 14:15 +1300
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:05 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:51 +0000
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 09:48 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:56 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 12:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:28 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 13:33 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:38 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 13:53 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:25 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:03 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:08 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:14 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 12:02 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:37 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 13:58 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:26 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 15:01 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:42 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:25 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:37 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 16:33 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:44 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:53 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:33 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:43 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 12:17 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 18:31 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 21:19 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-26 10:24 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 22:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:39 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:46 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:43 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:47 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:17 -0800
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 07:28 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 12:35 +0100
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 21:47 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 22:57 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-24 06:47 -0800
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 20:22 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:12 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 21:54 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 11:41 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-24 23:17 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:11 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 12:04 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:05 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:40 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 22:36 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:15 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:48 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:46 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 17:48 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:23 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 16:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:28 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 20:23 +0000
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:52 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 20:17 +0000
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-21 00:13 -0600
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-01-25 12:17 -0800 |
| Message-ID | <lnh8dwze2x.fsf@kst-u.example.com> |
| In reply to | #140281 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
[...]
>>> will notice that there's no difference in implied implementation
>>> choices. It's only a matter of ecosystem culture if the usual tools
>>> turn out as they are.
>>
>> 5.1.1.2 Translation phases:
>>
>> 8. All external object and function references are
>> resolved. Library components are linked to satisfy external
>> references to functions and objects not defined in the current
>> translation. All such translator output is collected into a
>> program image which contains information needed for execution
>> in its execution environment.
>>
>> That clearly implies a compile-and-link implementation.
I didn't use the word "implies" to indicate a strict requirement.
Substitute "strongly hints at" if you prefer.
The "Translation phases" section of the standard describes a
compile-and-link implementation. An interpreted implementation is
perfectly valid, but only if the behavior matches the description.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 18:31 +0000 |
| Message-ID | <vzI2E.90595$OD1.81016@fx27.am4> |
| In reply to | #140263 |
On 25/01/2019 15:33, Pascal J. Bourguignon wrote:> Bart <bc@freeuk.com> writes: > >> C is meant to be statically compiled, and nearly always is. Python is >> meant to be dynamically interpreted, and usually is. > > Bullshit! You have any statistics to suggest that the opposite is true? > Compilation and interpretation are implementation strategies to evaluate > PROGRAMS. They're totally unrelated to the LANGUAGE in which those > programs are written. > > > Classically, interpreters are used in the bootstrap process of > implementing a new compiler. Again, independently of the language! That's news to me. I've used machine code, assembly, and a previous language. It was 30 years before I used anything interpreted for that purpose. >> What native code would it compile down to in either C or Python? > > Obviously, very different native code, since the semantics of C and > Python are very different. The point is, you don't know the full semantics at compile-time with the Python. That's why interpretation is more suited. >> Or, through a vastly complex JIT process, > > And of course, there's a whole gradation of implementation strategies. > This is one more reason why trying to use the terms "compiled" or > "interpreted" to characterize languages is silly. > > Do you realize that your "native" code running on Intel processors is > actually COMPILED JIT into the real native microcode of the Intel > hardware? The interface to Intel and AMD processors is via its published instruction set. That forms one level of abstraction, which I loosely called 'native code' (since it varies according to processor, or even on the same processor). Programs that can be sensibly written directly in that native code might be 1 to 2 magnitudes faster (executing the same algorithm) than one using a byte-code interpreter with dynamic type-dispatch, itself written in that native code. So it doesn't really matter what 'native code' is. It might be C, then you are comparing a program written in C, to a byte-code version with an interpreter written in C. That C might then itself be compiled, or interpreted. But there will still be 1-2 magnitude interpretation overhead between them. >> It should be clear that C code would naturally be compiled, and Python >> is naturally interpreted. > > Nope, not clear at all. No? If you had to write a program that was performance critical (some algorithm for which no library version existed), which would you choose between C and Python? Python would be slower even /if/ it was compiled to native code, because there would still be type-dispatch overheads. That's why it might as well be interpreted. Is 'bash' compiled to native code? >> That is, if you interested in practicalities. (Your other replies >> suggest not.) I think the answer is Not.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 20:41 +0100 |
| Message-ID | <m2h8dwfrtg.fsf@despina.home> |
| In reply to | #140275 |
Bart <bc@freeuk.com> writes: > On 25/01/2019 15:33, Pascal J. Bourguignon wrote:> Bart > <bc@freeuk.com> writes: >> >>> C is meant to be statically compiled, and nearly always is. Python is >>> meant to be dynamically interpreted, and usually is. >> >> Bullshit! > > You have any statistics to suggest that the opposite is true? My argument is not based on statistics, but on logic. If we used statistics, we'd eat shit because more living beings eat shit than gourmet dishes. >> Compilation and interpretation are implementation strategies to evaluate >> PROGRAMS. They're totally unrelated to the LANGUAGE in which those >> programs are written. >> >> >> Classically, interpreters are used in the bootstrap process of >> implementing a new compiler. Again, independently of the language! > > That's news to me. I've used machine code, assembly, and a previous > language. It was 30 years before I used anything interpreted for that > purpose. The technique is well known since 1960. >>> What native code would it compile down to in either C or Python? >> >> Obviously, very different native code, since the semantics of C and >> Python are very different. > The point is, you don't know the full semantics at compile-time with > the Python. That's why interpretation is more suited. Once the semantics is established, be it at run-time, it can be compiled. Often, it is established very early, because fluctuant semantics are hard to understand anyways. >>> Or, through a vastly complex JIT process, >> >> And of course, there's a whole gradation of implementation strategies. >> This is one more reason why trying to use the terms "compiled" or >> "interpreted" to characterize languages is silly. >> >> Do you realize that your "native" code running on Intel processors is >> actually COMPILED JIT into the real native microcode of the Intel >> hardware? > > The interface to Intel and AMD processors is via its published > instruction set. That forms one level of abstraction, which I loosely > called 'native code' (since it varies according to processor, or even > on the same processor). > > Programs that can be sensibly written directly in that native code > might be 1 to 2 magnitudes faster (executing the same algorithm) than > one using a byte-code interpreter with dynamic type-dispatch, itself > written in that native code. > > So it doesn't really matter what 'native code' is. It might be C, then > you are comparing a program written in C, to a byte-code version with > an interpreter written in C. That C might then itself be compiled, or > interpreted. But there will still be 1-2 magnitude interpretation > overhead between them. Speed is of no consideration here. Notably, if you were to compare compilation and interpretation, you could observe that interpreters can execute programs either faster or slower than compilers can compile and the produced program executed. It depends on the case. This is why both techniques of execution (and more) are still in use. >>> It should be clear that C code would naturally be compiled, and Python >>> is naturally interpreted. >> >> Nope, not clear at all. > > No? If you had to write a program that was performance critical (some > algorithm for which no library version existed), which would you > choose between C and Python? Depends on what "performance" is. For example, if the performance is the total elapsed time between the start of the program development and the end of the production execution, you would probably choose Python over C. If the performance involved getting correct results, you would probably choose Python over C. > Python would be slower even /if/ it was compiled to native code, > because there would still be type-dispatch overheads. That's why it > might as well be interpreted. Is 'bash' compiled to native code? Yes, there are bash to native code compilers. It is fucking not a question of language! >>> That is, if you interested in practicalities. (Your other replies >>> suggest not.) > > I think the answer is Not. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 21:19 +0000 |
| Message-ID | <s1L2E.232208$ZE1.11190@fx24.am4> |
| In reply to | #140280 |
On 25/01/2019 19:41, Pascal J. Bourguignon wrote: > Bart <bc@freeuk.com> writes: >> Python would be slower even /if/ it was compiled to native code, >> because there would still be type-dispatch overheads. That's why it >> might as well be interpreted. Is 'bash' compiled to native code? > > Yes, there are bash to native code compilers. Really? How much faster would a typical bash script be then after compiling? > It is fucking not a > question of language! In theory it shouldn't be. In practice it is. You are arbitrarily given the name of a command to type to invoke a program that you are told is either written in C, or written in Python. Before you run it, you have to bet on whether it's compiled to native code, or interpreted. What would you put your money on for (1) a C program; (2) a Python program? With some languages that are commonly interpreted AND compiled (eg. Basic) it's a trickier bet. But for dynamically typed like Python, I believe interpreted is more common.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-01-26 10:24 +1300 |
| Message-ID | <gb1d42FfhgbU4@mid.individual.net> |
| In reply to | #140283 |
On 26/01/2019 10:19, Bart wrote: > On 25/01/2019 19:41, Pascal J. Bourguignon wrote: >> Bart <bc@freeuk.com> writes: > >>> Python would be slower even /if/ it was compiled to native code, >>> because there would still be type-dispatch overheads. That's why it >>> might as well be interpreted. Is 'bash' compiled to native code? >> >> Yes, there are bash to native code compilers. > > Really? How much faster would a typical bash script be then after compiling? Probably not a lot give a typical bash script is just glue around other utilities and the interpreter is already running! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-25 22:27 +0100 |
| Message-ID | <m28sz8fmx3.fsf@despina.home> |
| In reply to | #140283 |
Bart <bc@freeuk.com> writes: > On 25/01/2019 19:41, Pascal J. Bourguignon wrote: >> Bart <bc@freeuk.com> writes: > >>> Python would be slower even /if/ it was compiled to native code, >>> because there would still be type-dispatch overheads. That's why it >>> might as well be interpreted. Is 'bash' compiled to native code? >> >> Yes, there are bash to native code compilers. > > Really? How much faster would a typical bash script be then after compiling? Very much faster on bash code. As fast on fork/exec stuff. >> It is fucking not a >> question of language! > > In theory it shouldn't be. In practice it is. > > You are arbitrarily given the name of a command to type to invoke a > program that you are told is either written in C, or written in > Python. > > Before you run it, you have to bet on whether it's compiled to native > code, or interpreted. > > What would you put your money on for (1) a C program; (2) a Python program? > > With some languages that are commonly interpreted AND compiled > (eg. Basic) it's a trickier bet. But for dynamically typed like > Python, I believe interpreted is more common. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 22:39 +0000 |
| Message-ID | <%eM2E.136867$IF1.730@fx03.am4> |
| In reply to | #140286 |
On 25/01/2019 21:27, Pascal J. Bourguignon wrote: > Bart <bc@freeuk.com> writes: > >> On 25/01/2019 19:41, Pascal J. Bourguignon wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> Python would be slower even /if/ it was compiled to native code, >>>> because there would still be type-dispatch overheads. That's why it >>>> might as well be interpreted. Is 'bash' compiled to native code? >>> >>> Yes, there are bash to native code compilers. >> >> Really? How much faster would a typical bash script be then after compiling? > > Very much faster on bash code. As fast on fork/exec stuff. What do you mean by bash code? Do you mean a bash script that tries to run some algorithm rather than do its usual job of launching one external command after another? Because my experience tells me that, used in a typical manner and dominated by file operations, it will make no difference whatsoever.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-25 18:46 +0000 |
| Message-ID | <87ef90wp7b.fsf@bsb.me.uk> |
| In reply to | #140263 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes: > Bart <bc@freeuk.com> writes: > >> On 25/01/2019 09:08, Pascal J. Bourguignon wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 24/01/2019 23:46, Bart wrote: <snip> >>>> Python is an interpreted language, C is not. >>> >>> What do you mean? >>> >>> There are python compilers, there are C interpreters. >> >> C is meant to be statically compiled, and nearly always is. Python is >> meant to be dynamically interpreted, and usually is. > > Bullshit! > > Compilation and interpretation are implementation strategies to evaluate > PROGRAMS. They're totally unrelated to the LANGUAGE in which those > programs are written. You are taking an extreme view in order to make sure the disagreement continues! If you know your C history, you should know that the implementation was not totally unrelated to the language semantics. Early C was as it was, for many years, because of implementation limits. Of course even early C /could/ have been interpreted, but it wasn't, and the chosen implementation method fed back into the language. They were very much inter-related. The implementation strategy and the language's semantics are formally independent, but they are very rarely totally unrelated. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 12:43 +0000 |
| Message-ID | <HvD2E.157891$Pa4.107671@fx30.am4> |
| In reply to | #140222 |
On 25/01/2019 09:03, David Brown wrote: > On 24/01/2019 23:46, Bart wrote: >> On 24/01/2019 21:24, David Brown wrote: >>> On 24/01/2019 18:32, Bart wrote: >> >>>> What makes you think my project isn't modular? >>>> >>> >>> Your obsession with single giant files, along with your dismissal of >>> sensible development tools and editors. >> >> You don't seem to understand how a module system works in this kind of >> language. >> >> When you write 'python prog.py' then it will automatically seek out and >> load any dependencies of prog.py, you don't need to list them all in an >> auxiliary file. > > Python is an interpreted language, C is not. That doesn't come into it. I have one compiled language and one interpreted one; they both use the same import/module scheme. (The only difference with Python is that 'import' statements are executable code, so can be conditional, or be inside an exec() string or whatever. So that you can't always extract the module hierarchy from the static code; you need to run the program. And even that will not give you all possible module sets. But that's just that language being a little too dynamic for its own good. Most Python programs I think will have static import graphs.) >> That means it's more sophisticated that your tools. >> > > No, it means it is more limited. My tools are small enough and simple enough to quickly change, that I could actually add a 'strinclude' feature to my version of C within a matter of minutes. (I even added 'bininclude' to the other language at your prompting!) So while you have to go around the houses with your scripts, I can take a direct approach. I can easily modify my compilers; modifying your version of gcc by changing its source code is less practical. Both solutions will only work on our systems. However, you are claiming what I do is limited; I am disputing that. (May reply to other points at a different time.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 14:37 +0100 |
| Message-ID | <q2f3f6$6d9$1@dont-email.me> |
| In reply to | #140241 |
On 25/01/2019 13:43, Bart wrote: > On 25/01/2019 09:03, David Brown wrote: >> On 24/01/2019 23:46, Bart wrote: >>> On 24/01/2019 21:24, David Brown wrote: >>>> On 24/01/2019 18:32, Bart wrote: >>> >>>>> What makes you think my project isn't modular? >>>>> >>>> >>>> Your obsession with single giant files, along with your dismissal of >>>> sensible development tools and editors. >>> >>> You don't seem to understand how a module system works in this kind of >>> language. >>> >>> When you write 'python prog.py' then it will automatically seek out and >>> load any dependencies of prog.py, you don't need to list them all in an >>> auxiliary file. >> >> Python is an interpreted language, C is not. > > That doesn't come into it. I have one compiled language and one > interpreted one; they both use the same import/module scheme. > > (The only difference with Python is that 'import' statements are > executable code, so can be conditional, or be inside an exec() string or > whatever. So that you can't always extract the module hierarchy from the > static code; you need to run the program. And even that will not give > you all possible module sets. > > But that's just that language being a little too dynamic for its own > good. Most Python programs I think will have static import graphs.) > >>> That means it's more sophisticated that your tools. >>> >> >> No, it means it is more limited. > > My tools are small enough and simple enough to quickly change, that I > could actually add a 'strinclude' feature to my version of C within a > matter of minutes. (I even added 'bininclude' to the other language at > your prompting!) > To make sense as a solution, or as a programming language, then you should not be changing it to suit different needs like this. If you /are/ changing it, and if you have to change it for different purposes, then your language and its tools are basically the same as the scripts I use. (This is, of course, fine - but you should call them scripts, or project-specific tools.) If you want to consider your language as a proper programming language, and your compiler/translator as a proper implementation of it and serious development tool, then you have to imagine that your language has serious documentation with reviews by experts, implementations with testing, distribution, version numbers, etc. You have to imagine that a different developer, unknown to you (except perhaps as a paying customer) is using version 1.2 of your tools and finds they want a "bininclude" feature that is missing from your tools. Somewhere else, someone is using version 1.3 and wants a "bininclude" but with different details. Another person is using 1.4, and has a local function with the name "bininclude". Your development tree is half-way through version 1.5 and has some backwards incompatible changes for bug-fixes. Is it still just a few minutes work to add this new feature? Suddenly it is man-months for everyone involved. That is a key difference between project-specific scripts that can be changed without concern, and a serious programming language. You can make your changes in your little local languages precisely because they are little local languages - not really much different in principle from my scripts (though clearly much larger, and with many other features). > So while you have to go around the houses with your scripts, I can take > a direct approach. I can easily modify my compilers; modifying your > version of gcc by changing its source code is less practical. > > Both solutions will only work on our systems. However, you are claiming > what I do is limited; I am disputing that. > Your solution would not work for me. My solution would work fine for you. A quick Python script could generate "mm" sources for an embedded binary just as easily as it can generate C sources. > (May reply to other points at a different time.) >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-25 14:19 +0000 |
| Message-ID | <5WE2E.190555$kE1.61033@fx20.am4> |
| In reply to | #140247 |
On 25/01/2019 13:37, David Brown wrote: > On 25/01/2019 13:43, Bart wrote: >> Both solutions will only work on our systems. However, you are claiming >> what I do is limited; I am disputing that. >> > > Your solution would not work for me. My solution would work fine for > you. A quick Python script ... I bet it wouldn't! Python programs have the problems of needing any required import modules, having the right versions, being the right Python version, having all the default search paths in place etc. And if you switch OS, then you have to ensure all that on the new system. (Anyway for scripting, I've had my own scripting language since 1980s - it's older than Python. It's smaller, simpler and more easily portable.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-25 15:47 +0100 |
| Message-ID | <q2f7ib$v88$1@dont-email.me> |
| In reply to | #140250 |
On 25/01/2019 15:19, Bart wrote: > On 25/01/2019 13:37, David Brown wrote: >> On 25/01/2019 13:43, Bart wrote: > >>> Both solutions will only work on our systems. However, you are claiming >>> what I do is limited; I am disputing that. >>> >> >> Your solution would not work for me. My solution would work fine for >> you. A quick Python script ... > > I bet it wouldn't! > > Python programs have the problems of needing any required import > modules, having the right versions, being the right Python version, > having all the default search paths in place etc. And if you switch OS, > then you have to ensure all that on the new system. That is true for any code in any language, if the program is big enough and requires external libraries. Reading a file in binary and writing the values in a C source initialised array doesn't take anything outside the standard library. I think the only import would be "sys", to get the command line arguments for the names of the files. (OK, you can easily write code that is not compatible with both Python 2 and Python 3. But you can write it in a way that is compatible with both, without too much effort.) > > (Anyway for scripting, I've had my own scripting language since 1980s - > it's older than Python. It's smaller, simpler and more easily portable.) Except that every *nix system already has Python, as do a fair proportion of Windows PC's used by programmers - and it is a quick and simple installation for those that don't have it. Your own scripting language is your own, and exists only on your systems.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-01-25 07:17 -0800 |
| Message-ID | <212e6a1d-5273-408e-bbbb-212c2470f95f@googlegroups.com> |
| In reply to | #140256 |
On Friday, 25 January 2019 14:47:47 UTC, David Brown wrote: > > Except that every *nix system already has Python, as do a fair > proportion of Windows PC's used by programmers - and it is a quick and > simple installation for those that don't have it. Your own scripting > language is your own, and exists only on your systems. > That's true of any start-up language. It needs to attract a critical mass of users until most people will use it for any non-experimental purposes, which means that it's hard to attract that critical mass.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-02-03 07:28 +0000 |
| Message-ID | <slrnq5d60v.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #140203 |
On Thu, 2019-01-24, David Brown wrote: > On 24/01/2019 18:32, Bart wrote: >> On 24/01/2019 14:44, David Brown wrote: >>> On 24/01/2019 15:10, Bart wrote: >> >>>> I build my C compiler (which includes 40 embedded files) with one >>>> command: mm cc. 'mm' is a compiler. >>> >>> And I build my projects using one command "make". >> >> So, taking a fiddly build sequence of dozens of steps, involving running >> utilities, scripts in multiple languages and having extra dependencies, >> wrapping it all up in a makefile script then invoking the lot using >> 'make' is just the same as one genuinely simple step using nothing extra? >> > > I am a /programmer/. Writing lots of fiddly lines that non-initiates > can't understand, but where the result can be used simply and reliably, > is what programmers do! > > The makefiles I use are complex. Just for the record, the makefiles I use are simple. Generating code in steps (four at the most; noone uses a dozen) is easy; make /was designed to/ make that painless and readable. You draw the graph of is-generated-from dependencies between the files, and then you specify the commands to do the generation. That's all make does. I suspect cross-compilation is what adds the complexity to DB's makefiles. Perhaps in combination with unit tests (so the makefile has to contain two similar but distinct dependency graphs). And indeed: ... > Having made the investment, building is done with "make". I have > projects where that builds half a dozen different programs or variants > for different systems, builds binaries into flash programming files, > automatically downloads to test cards, etc. All from "make". [snip] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-03 12:35 +0100 |
| Message-ID | <q36jmd$9r9$1@dont-email.me> |
| In reply to | #140492 |
On 03/02/2019 08:28, Jorgen Grahn wrote: > On Thu, 2019-01-24, David Brown wrote: >> On 24/01/2019 18:32, Bart wrote: >>> On 24/01/2019 14:44, David Brown wrote: >>>> On 24/01/2019 15:10, Bart wrote: >>> >>>>> I build my C compiler (which includes 40 embedded files) with one >>>>> command: mm cc. 'mm' is a compiler. >>>> >>>> And I build my projects using one command "make". >>> >>> So, taking a fiddly build sequence of dozens of steps, involving running >>> utilities, scripts in multiple languages and having extra dependencies, >>> wrapping it all up in a makefile script then invoking the lot using >>> 'make' is just the same as one genuinely simple step using nothing extra? >>> >> >> I am a /programmer/. Writing lots of fiddly lines that non-initiates >> can't understand, but where the result can be used simply and reliably, >> is what programmers do! >> >> The makefiles I use are complex. > > Just for the record, the makefiles I use are simple. Generating code > in steps (four at the most; noone uses a dozen) is easy; make /was > designed to/ make that painless and readable. > To be clear here, I don't mean to suggest that makefiles /need/ to be complex - I gave an example of quite a powerful generic makefile that is short and simple. I mean that if a complex makefile is helpful, then we as programmers should not be scared of it. But if a simple one will do, then use a simple one. > You draw the graph of is-generated-from dependencies between the > files, and then you specify the commands to do the generation. That's > all make does. > > I suspect cross-compilation is what adds the complexity to DB's > makefiles. Perhaps in combination with unit tests (so the makefile > has to contain two similar but distinct dependency graphs). > Cross-compilation can often be part of the reason - I might have different kinds of binaries to build, or include downloads and other tasks in the makefile. But it is also a matter of having several dozen source files and a number of directories, along with a large number of compiler options which are not always consistent amongst the sources (third-party source files might need different warnings or compile options than my own code). And sometimes I have extra pre-processing or post-processing involved, code generators, etc. > And indeed: > > ... >> Having made the investment, building is done with "make". I have >> projects where that builds half a dozen different programs or variants >> for different systems, builds binaries into flash programming files, >> automatically downloads to test cards, etc. All from "make". > > [snip] > > /Jorgen >
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-02-03 21:47 +0000 |
| Message-ID | <slrnq5eoat.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #140493 |
On Sun, 2019-02-03, David Brown wrote: > On 03/02/2019 08:28, Jorgen Grahn wrote: >> On Thu, 2019-01-24, David Brown wrote: >>> On 24/01/2019 18:32, Bart wrote: >>>> On 24/01/2019 14:44, David Brown wrote: >>>>> On 24/01/2019 15:10, Bart wrote: >>>> >>>>>> I build my C compiler (which includes 40 embedded files) with one >>>>>> command: mm cc. 'mm' is a compiler. >>>>> >>>>> And I build my projects using one command "make". >>>> >>>> So, taking a fiddly build sequence of dozens of steps, involving running >>>> utilities, scripts in multiple languages and having extra dependencies, >>>> wrapping it all up in a makefile script then invoking the lot using >>>> 'make' is just the same as one genuinely simple step using nothing extra? >>>> >>> >>> I am a /programmer/. Writing lots of fiddly lines that non-initiates >>> can't understand, but where the result can be used simply and reliably, >>> is what programmers do! >>> >>> The makefiles I use are complex. >> >> Just for the record, the makefiles I use are simple. Generating code >> in steps (four at the most; noone uses a dozen) is easy; make /was >> designed to/ make that painless and readable. > > To be clear here, I don't mean to suggest that makefiles /need/ to be > complex - I gave an example of quite a powerful generic makefile that is > short and simple. I mean that if a complex makefile is helpful, then we > as programmers should not be scared of it. But if a simple one will do, > then use a simple one. Yes, that was what I was trying to clarify. (I knew you didn't intend to mystify.) >> You draw the graph of is-generated-from dependencies between the >> files, and then you specify the commands to do the generation. That's >> all make does. >> >> I suspect cross-compilation is what adds the complexity to DB's >> makefiles. Perhaps in combination with unit tests (so the makefile >> has to contain two similar but distinct dependency graphs). > > Cross-compilation can often be part of the reason - I might have > different kinds of binaries to build, or include downloads and other > tasks in the makefile. I'm reluctant to do downloads from a Makefile, or anything that isn't about generating N local files from M other local files, if there have been updates. But I allow things like 'make clean', 'make install' and 'make check'. The rest isn't major sources of complexity IME. Assuming Gnu Make: > But it is also a matter of having several dozen source files and a > number of directories, libfoo.a: foo/file1.o > along with a large number of compiler options CFLAGS=... CPPFLAGS=... > which are not always consistent amongst the sources (third-party > source files might need different warnings or compile options than > my own code). thirdparty1/%.o: CFLAGS+=... > And sometimes I have extra pre-processing or post-processing > involved, code generators, etc. Also one or two more lines -- except I've been bitten in the past by auto-generated header files: the header dependencies aren't known until that file has been generated. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-03 22:57 +0100 |
| Message-ID | <q37o48$v8t$1@dont-email.me> |
| In reply to | #140502 |
On 03/02/2019 22:47, Jorgen Grahn wrote: > On Sun, 2019-02-03, David Brown wrote: >> On 03/02/2019 08:28, Jorgen Grahn wrote: >>> On Thu, 2019-01-24, David Brown wrote: >>>> On 24/01/2019 18:32, Bart wrote: >>>>> On 24/01/2019 14:44, David Brown wrote: >>>>>> On 24/01/2019 15:10, Bart wrote: >>>>> >>>>>>> I build my C compiler (which includes 40 embedded files) with one >>>>>>> command: mm cc. 'mm' is a compiler. >>>>>> >>>>>> And I build my projects using one command "make". >>>>> >>>>> So, taking a fiddly build sequence of dozens of steps, involving running >>>>> utilities, scripts in multiple languages and having extra dependencies, >>>>> wrapping it all up in a makefile script then invoking the lot using >>>>> 'make' is just the same as one genuinely simple step using nothing extra? >>>>> >>>> >>>> I am a /programmer/. Writing lots of fiddly lines that non-initiates >>>> can't understand, but where the result can be used simply and reliably, >>>> is what programmers do! >>>> >>>> The makefiles I use are complex. >>> >>> Just for the record, the makefiles I use are simple. Generating code >>> in steps (four at the most; noone uses a dozen) is easy; make /was >>> designed to/ make that painless and readable. >> >> To be clear here, I don't mean to suggest that makefiles /need/ to be >> complex - I gave an example of quite a powerful generic makefile that is >> short and simple. I mean that if a complex makefile is helpful, then we >> as programmers should not be scared of it. But if a simple one will do, >> then use a simple one. > > Yes, that was what I was trying to clarify. (I knew you didn't intend to > mystify.) > >>> You draw the graph of is-generated-from dependencies between the >>> files, and then you specify the commands to do the generation. That's >>> all make does. >>> >>> I suspect cross-compilation is what adds the complexity to DB's >>> makefiles. Perhaps in combination with unit tests (so the makefile >>> has to contain two similar but distinct dependency graphs). >> >> Cross-compilation can often be part of the reason - I might have >> different kinds of binaries to build, or include downloads and other >> tasks in the makefile. > > I'm reluctant to do downloads from a Makefile, or anything that isn't > about generating N local files from M other local files, if there have > been updates. But I allow things like 'make clean', 'make install' > and 'make check'. > Yes, typically the "burn to the microcontroller flash" command would be its own target, "make burn", and would depend on the main compilation and build (which would be the default target). This kind of target is just a convenience - it is not part of building the exe file, but it saves making extra bash/batch files or remembering the details of other command lines if they are neatly in a makefile. > The rest isn't major sources of complexity IME. Assuming Gnu Make: > >> But it is also a matter of having several dozen source files and a >> number of directories, > > libfoo.a: foo/file1.o > I don't want to manually list the several dozen files. I like make to figure out itself which files are needed (hint - if they are in the project directory, they are needed). I like dependency files to be generated automatically, and updated automatically, by make and gcc "magic". >> along with a large number of compiler options > > CFLAGS=... > CPPFLAGS=... For some people, a quick CFLAGS line is sufficient. For me, it is not. Keep your makefiles short and simple when that is good enough, and make them more advanced when that is useful. > >> which are not always consistent amongst the sources (third-party >> source files might need different warnings or compile options than >> my own code). > > thirdparty1/%.o: CFLAGS+=... > I know. >> And sometimes I have extra pre-processing or post-processing >> involved, code generators, etc. > > Also one or two more lines -- except I've been bitten in the past by > auto-generated header files: the header dependencies aren't known > until that file has been generated. > This is all solvable, with care.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-01-24 06:47 -0800 |
| Message-ID | <2b33ae52-ecb8-47de-b183-ad5600b0e375@googlegroups.com> |
| In reply to | #140163 |
On Thursday, 24 January 2019 14:10:56 UTC, Bart wrote: > On 24/01/2019 12:58, David Brown wrote: > > > > > If it is rare, it is because few others think it is a useful feature - > > or they think it is not worth the effort. > > It is likely rare because it is next to impossible to add a feature like > this into a language. It would take years, then a further couple of > decades until support is widespread enough to rely on it. > > And there would be opposite from people like you who have already > invested in their own workarounds. > My workaround, if that's the right word, is the Baby X resource compiler. It does more than just include binary data, it also resizes images and translates them into 24 bit rgba format. Whilst there's a command to include a text file, I've never used it. The idea is that you often have a chain from raw assets to binary data that ships with the product. The resource compiler means that you can keep all your raw images in one directory then automatically build source from that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-01-23 20:22 +0000 |
| Message-ID | <87o987xgxl.fsf@bsb.me.uk> |
| In reply to | #140122 |
David Brown <david.brown@hesbynett.no> writes: > On 23/01/2019 17:05, Bart wrote: <snip> >> There is a problem with finding a general way of translating named >> constants in one language to the equivalent in C, where it is necessary >> to choose between #define, or enums or just showing the literal directly. > > There is only a problem because you make it a problem - and you only do > that so that you can claim that C has a problem with constants. Bart has a point here. C /does/ have a problem with "named constants" -- what would be thought of in other languages as names denoting values. In C, most names denotes objects. enum members can name integer values, but that's about it. But Bart has also made a problem for himself because he's translating into C, not compiling to C. I think he's often trying to find matching constructs rather than simply generating code that has the required semantics. > Floating constants will only be used as floating point numbers. You can > translate them to "static const double pie = 1.234;" without trouble. Not when the value is the result of what C views as a non-constant expression. OK, so in that case you can just drop the static, but it's not as simple as you suggest in general. > (I don't know how you declare data to be exported or local to a module > in your language - use "static" when possible.) > > Strings will be either "const char * s = "Hello";", or "const char s[] = > "Hello";" - like James, I don't know which you would prefer. > > That leaves integers. ... and structures and unions and arrays. And pointers to these and functions returning these... These are just the C types that could, conceptually, have named values but don't. The source language might have even more. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-23 22:12 +0100 |
| Message-ID | <q2alb9$sg7$1@dont-email.me> |
| In reply to | #140130 |
On 23/01/2019 21:22, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 23/01/2019 17:05, Bart wrote: > <snip> >>> There is a problem with finding a general way of translating named >>> constants in one language to the equivalent in C, where it is necessary >>> to choose between #define, or enums or just showing the literal directly. >> >> There is only a problem because you make it a problem - and you only do >> that so that you can claim that C has a problem with constants. > > Bart has a point here. C /does/ have a problem with "named > constants" -- what would be thought of in other languages as names > denoting values. In C, most names denotes objects. enum members can > name integer values, but that's about it. C certainly could be improved regarding constants (C++ has done so). That is different from saying it has a problem. There are few uses of named constants that you can't make work in C reasonably easily (as long as you are not allergic to #define). C++ style const and constexpr give you more. > > But Bart has also made a problem for himself because he's translating > into C, not compiling to C. I think he's often trying to find matching > constructs rather than simply generating code that has the required > semantics. Agreed. That is a good summary. > >> Floating constants will only be used as floating point numbers. You can >> translate them to "static const double pie = 1.234;" without trouble. > > Not when the value is the result of what C views as a non-constant > expression. OK, so in that case you can just drop the static, but it's > not as simple as you suggest in general. But he is generating the C code. Surely such expressions should be calculated by his translator, using the source language's semantics (which could involve different precisions, rounding, etc.) and then write the literal value directly to the C code. Maybe that is the translator/compiler issue you mentioned. Perhaps he would be better translating to C++. I think more of his concepts would work there. > >> (I don't know how you declare data to be exported or local to a module >> in your language - use "static" when possible.) >> >> Strings will be either "const char * s = "Hello";", or "const char s[] = >> "Hello";" - like James, I don't know which you would prefer. >> >> That leaves integers. > > ... and structures and unions and arrays. And pointers to these and > functions returning these... These are just the C types that could, > conceptually, have named values but don't. The source language might > have even more. > > <snip> >
[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