Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Eternal Hope Newsgroups: comp.lang.java.programmer Subject: Re: is the java compiler written in c Date: Sat, 22 Aug 2015 10:31:22 +0100 Organization: A noiseless patient Spider Lines: 113 Message-ID: References: <893a1a37-881c-4e59-a069-38386dd1b0fd@googlegroups.com> <7b5d28de-2f30-4db7-aec7-03bd9ce81d00@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 22 Aug 2015 09:29:32 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="2ab430ef8c6b5deb5816c858366218e1"; logging-data="3537"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Jt8JWkuUOCZjKuZJuC+d8HLDM3URM8JU=" User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: Cancel-Lock: sha1:WSZ5q0exaJQjcyqKKnRsa6ZmfZg= Xref: csiph.com comp.lang.java.programmer:32401 On 21/08/2015 22:51, BGB wrote: > On 8/21/2015 2:15 AM, Eternal Hope wrote: >> On 20/08/2015 00:12, gdotone@gmail.com wrote: >>> On Wednesday, August 19, 2015 at 4:06:41 PM UTC-4, Eric Sosman wrote: >>> >>>> Finally, I have a counter-question: Why do you care? >>> >>> c has many unspecified and undefines, all for the flexibility of the >>> language, so that it can be used to solve many different problems. >> >> comp.lang.c is a fascinating read. >> >> start: >> >> On the one hand, any suggestion that the official C specification is >> 'tightened up' so that the almost endless 'undefined behaviors' are more >> rigidly defined is met with howls of protest because of the >> >> 'C is so powerful because you can do anything you want with it and >> that's the way we like it' >> >> brigade. >> > > you can tighten it up in a way which works on most targets, say, making > 'int' always be 32 bits, ... > > but, this hinders use on some targets (MSP430 or AVR8) which work > primarily on 8 and 16 bit units. > > granted, you probably wont use the same code on an MSP430 as you would > on a PC, but code *could* be moved between, say, an MSP430 and a > Cortex-M or similar. > > the MSP or AVR are enough unlike a PC though, to where one is generally > better off emulating the chip (and any attached peripheral hardware), > rather than try to rig things up to fake it on a PC via wrappers (this > is a more common strategy for code targeting ARM based controllers). > > >> On the other hand there is endless droning on about making everything >> you do as 'portable' as possible which requires an in depth >> understanding of undefined behavior, despite the fact that the >> definition of undefined actually equates to 'is unknowable in a >> particular implementation' etc etc'. >> > > or, narrowing it down to a range of platforms for which it will work, > say, 32 and 64 bit Windows and Linux. > > >> If one has the temerity to post c code that does something that is >> platform specific, or, even worse implementation specific as I have done >> in the past you are instantly jumped on and reprimanded for a poor >> understanding of a specification that by its very nature can never be >> fully understood due to the almost endless undefined things. >> > > more of a c.l.c thing, not so much C in general. > most real-world code needs a pile of #ifdef's and platform specific > sequences for anything in may run on. > > >> If you then suggest that it might be time to make certain undefined >> behavious better defined then ... >> >> goto start >> >> You might consider this situation a dichotomy where set membership is >> mutually exclusive. Not so, Some seem to have a foot firmly rooted in >> both camps possibly due to some rule that determines set membership >> imported from in a parallel universe. >> >> Like I say, it's fascinating read. >> > > every language has tradeoffs. Absolutely > like if one admits to knowing or ever using Java, then people > automatically assume that they are doing enterprise/business computing > stuff. I'd have to agree with this, in fact most of my commercial experience is enterprise focussed. I mainly do assembler and C for pleasure (among other things naturally :-) > but, in the past, I was mostly doing games stuff, as well as a lot of > compiler/VM stuff; > now more recently, it has moved more into a mix of embedded programming. > generally real-time motor-controls type stuff. and some stuff on > hardware with amazingly bad hardware stats (several MHz and a few kB of > ROM, and *bytes* of RAM). > > one could be like, "how does one do anything with only a few kB of > ROM?", but it partly is a matter of perspective. if you expect to use a > big complex program, it wont work. if can do everything in maybe a few > hundred lines of C (sans comments), then, say, a 2kB ROM space and 256B > of RAM is sufficient. Horses for courses, completely agree. I remember running a profiller on WebLogic running a not particularly heavyweight application that made use of the org.w3c.dom library implementation in a reference implementation of the language to manipulate xml and discovering that upwards of a MILLION String Objects were being held in memory at any one time. Not exactly embedded territory is it :-) -- Laughing Spam Fritter