On Thu, 09 Oct 2008 10:31:26 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.com> wrote:>Jasen Betts wrote: >> On 2008-10-06, Martin Brown <|||newspam|||@nezumi.demon.co.uk> wrote: >> >>> The most obvious way is not always the most efficient algorithm. Certain >>> C constructs are hell for optimising compilers. And without using lint >>> (or a similar tool) there are far too many gotchas from typos possible. >>> A well known classic one being (and variants thereof): >>> >>> if (x=OK) { >>> do something >>> } >> >> Any decent compiler will complain about that. >> >>> It is virtually certain that the author meant (x==OK) but provided that >>> the value of OK is non-zero the condition is always satisfied. >> >> it is not certain, I used a similar construct yesterday. >> and when I did I wrote it like this. >> >> if( (x=somefunc()) ) >> >> so that the next person to inspect the code, and the compiler, would >> know that I really meant it. >> > >There's no reason to use an assignment in the condition of an if statement. >Loop conditions are another matter, but in C and C++ you can use the comma >operator, i.e. > >while(x = somefunc(), x) >{} > >That'll bring the maintenance programmer up short if he doesn't know C well.Eeuuuuuwww... Yeah, but it's UGLY :-p My preference for the if-embedded assignment is to if ((x = somefunc()) != 0) which should compile to identical code to the simple assignment while making the intent clear to the maintainer. -- Rich Webb Norfolk, VA
Re: Microchip & OnSemi want to buy Atmel?
Started by ●October 9, 2008
Reply by ●October 9, 20082008-10-09
Rich Webb <bbew.ar@mapson.nozirev.ten> writes:> if ((x = somefunc()) != 0)GCC allows you to do this: if ((x = somefunc())) The extra set of parens tells gcc that you intentionally tested the result of an assignment as a value.
Reply by ●October 18, 20082008-10-18
On Fri, 17 Oct 2008 17:53:15 -0700, Eric Smith <eric@brouhaha.com> wrote:>Jim Granville <no.spam@designtools.maps.co.nz> writes: >> So, to sumarise : A pascal you cannot actually buy, is not suitable for >> low level programming, but almost any commercial compiler is. > >Provided that you don't want your code to be portable. Presumably if you >wanted your code to be portable, you would write it in Pascal, and then >you couldn't do the low-level stuff.How much portability do you really expect in some embedded environment, especially if the hardware architecture is somewhat awkward. In practice you would still have to separate the platform dependent functions, which can always be written in assembler, provided that the HLL supports separate compilation. Things get nasty of course, if every other line in the HLL code is a call to an assembler function. A bizarre example: I once had to write a program In Cobol (due to customer demand) that manipulated a lot of 64 bit bit masks related to the OS security system. Fortunately the OS run time system bit mapping functions were directly callable from all supported languages, but even writing the calling sequence for any other language convention would not be an issue. Paul
Reply by ●October 27, 20082008-10-27
Paul Keinanen <keinanen@sci.fi> writes:> How much portability do you really expect in some embedded > environment, especially if the hardware architecture is somewhat > awkward.I expect a lot of it to be portable, because on numerous occasions I've changed compilers in mid-project or when doing maintenance at a later date. Sometimes that's my decision, and sometimes it's the client's decision.> In practice you would still have to separate the platform > dependent functions, which can always be written in assembler, > provided that the HLL supports separate compilation.Sure. But that doesn't obviate the need to use the right tools for the job. If you need to write low-level code, and you want it to be portable, Pascal is the wrong answer, since you'll have to use non-standard language extensions. I'm not a big fan of C, but it's certainly suitable for low-level programming. My criticisms of C are at the other end of the spectrum. I write a lot of C code because that's what my clients want, and in the case of Free Software, that's what people are likely to be able to run. I prefer strongly-typed languages. I actually do like Pascal, and over the years I've written a lot of code for clients in UCSD Pascal, Turbo Pascal, etc., but I wouldn't recommend it to clientis now, especially for low-level work. I like Ada better; functionally it is almost a superset of Pascal, but it is significantly better in many regards including support for low-level programming. However, my clients generally don't want Ada, partly because it is supported on fewer target platforms, and partly because they'd have a harder time finding other engineers to maintain it.
Reply by ●October 27, 20082008-10-27
Eric Smith wrote:>... snip ...> > I'm not a big fan of C, but it's certainly suitable for low-level > programming. My criticisms of C are at the other end of the > spectrum. I write a lot of C code because that's what my clients > want, and in the case of Free Software, that's what people are > likely to be able to run. > > I prefer strongly-typed languages. I actually do like Pascal, > and over the years I've written a lot of code for clients in UCSD > Pascal, Turbo Pascal, etc., but I wouldn't recommend it to > clientis now, especially for low-level work. I like Ada better; > functionally it is almost a superset of Pascal, but it is > significantly better in many regards including support for > low-level programming. However, my clients generally don't want > Ada, partly because it is supported on fewer target platforms, > and partly because they'd have a harder time finding other > engineers to maintain it.Now that Ada is available as part of the gcc package, it is available almost anywhere that C is available. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
