* bitwise comparators @ 2000-01-15 0:00 Alexander Van Hecke 2000-01-15 0:00 ` David C. Hoos, Sr. ` (4 more replies) 0 siblings, 5 replies; 55+ messages in thread From: Alexander Van Hecke @ 2000-01-15 0:00 UTC (permalink / raw) hello, I want to do the following : OK_to_proceed : BOOLEAN := FALSE; data : Unsigned_8; while (not OK_to_proceed) loop -- do stuff OK_to_proceed := (data BITWISE AND 2#1#); end loop; so I want to exit the loop if bit one of data is set, but I don't know what the bitwise and is! alex ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-15 0:00 bitwise comparators Alexander Van Hecke @ 2000-01-15 0:00 ` David C. Hoos, Sr. 2000-01-16 0:00 ` Matthew Heaney ` (3 subsequent siblings) 4 siblings, 0 replies; 55+ messages in thread From: David C. Hoos, Sr. @ 2000-01-15 0:00 UTC (permalink / raw) Alexander Van Hecke <alexke@hotmail.com> wrote in message news:3880D375.7E363123@hotmail.com... > hello, > > I want to do the following : > OK_to_proceed : BOOLEAN := FALSE; > data : Unsigned_8; > > while (not OK_to_proceed) loop > -- do stuff > OK_to_proceed := (data BITWISE AND 2#1#); > end loop; > > so I want to exit the loop if bit one of data is set, but I don't know > what the bitwise and is! Do you have a copy of the Ada Language Reference Manual? If so, a search for bit-wise reveals that bit-wise logical operators are defined for modular types. If not, the Reference Manual is distributed in Windows Help file format with GNAT for winnt, or is available at ftp://ftp.cs.nyu.edu/pub/gnat/rm9x-v5.95/ in two formats, and browsable HTML form at http://www.adapower.com/rm95/index.html It's amazing how many questions can be answered by perusing the readily-available resources. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-15 0:00 bitwise comparators Alexander Van Hecke 2000-01-15 0:00 ` David C. Hoos, Sr. @ 2000-01-16 0:00 ` Matthew Heaney 2000-01-16 0:00 ` DuckE ` (2 subsequent siblings) 4 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2000-01-16 0:00 UTC (permalink / raw) In article <3880D375.7E363123@hotmail.com> , Alexander Van Hecke <alexke@hotmail.com> wrote: > I want to do the following : > OK_to_proceed : BOOLEAN := FALSE; > data : Unsigned_8; > > while (not OK_to_proceed) loop > -- do stuff > OK_to_proceed := (data BITWISE AND 2#1#); > end loop; > > so I want to exit the loop if bit one of data is set, but I don't know > what the bitwise and is! The bitwise and for modular types is "and". Don't use the while form of loop; your version requires mental gymnastics to figure out. If you want to "exit the loop if bit one of data is set," then say that directly: loop -- do stuff exit when (data and 2#1#) > 0; end loop; You also have to be careful what you mean by "bit one". Are you referring to the bit that corresponds to the value of 2**0, or 2**1? Your original example uses 2#1#, which I would probably describe as the "bit zero." -- Time and again the nation's courts have ruled that creationism, as a religious dogma, cannot be taught in science classes. Now, creationists are advancing a new tactic: eliminating the teaching of evolution and other sciences that complement evolution, such as geology, paleontology, and biological anthropology. By doing so, they are not only endangering church-state separation but also seriously jeopardizing the science education of future generations. http://www.campusfreethought.org/sos/ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-15 0:00 bitwise comparators Alexander Van Hecke 2000-01-15 0:00 ` David C. Hoos, Sr. 2000-01-16 0:00 ` Matthew Heaney @ 2000-01-16 0:00 ` DuckE 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-16 0:00 ` Jeff Carter 2000-01-16 0:00 ` Bryce Bardin 4 siblings, 1 reply; 55+ messages in thread From: DuckE @ 2000-01-16 0:00 UTC (permalink / raw) Alexander Van Hecke <alexke@hotmail.com> wrote in message news:3880D375.7E363123@hotmail.com... > hello, > > I want to do the following : > OK_to_proceed : BOOLEAN := FALSE; > data : Unsigned_8; > > while (not OK_to_proceed) loop > -- do stuff > OK_to_proceed := (data BITWISE AND 2#1#); > end loop; > > so I want to exit the loop if bit one of data is set, but I don't know > what the bitwise and is! Caution: You've caught me in a "chatty" mood. As others have responded, if Unsigned_8 is a modular type, you can use the "AND" operator and just change your code to read: while (not OK_to_proceed) loop -- do stuff OK_to_proceed := (data and 2#1#) /= 0; end loop; Note: in Ada booleans and integer or modular types are two different critters so you cannot assign an integer to a boolean. I'd also like to point out that the "while" construct you are using is common for 'C' or Pascal, but in Ada you could use a "loop" construct with "exit when" loop -- do stuff exit when (data and 2#1#) /= 0; end loop; And eliminate the need for an OK_to_proceed variable. Of course this is a matter of style preference. The other thing I'd like to point out is with Ada you can explicity map bits within memory using representation clauses, for example: type status_register is record data_ready : boolean; end record; for status_register use record data_ready at 0 range 0..0; end record; for status_register'size use 8; register : status_register; for register'address use -- fill in the address of the register here And then the loop becomes: loop -- do stuff exit when register.data_ready end loop; Which eliminates explicit bit masking altogether. Of course you may have to use a volatile pragma to make sure the value gets loaded for each test. SteveD > > alex > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-16 0:00 ` DuckE @ 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David C. Hoos, Sr. ` (7 more replies) 0 siblings, 8 replies; 55+ messages in thread From: Alexander Van Hecke @ 2000-01-17 0:00 UTC (permalink / raw) > I'd also like to point out that the "while" construct you are using is > common for 'C' or Pascal, but in Ada you could use a "loop" construct with > "exit when" > thank you all for your response! As many of you have pointed out, I could have used exit when ... But as you probably noticed, I have a C background and I'm not that familiar with Ada. I think it's a nice feature of Ada that you can write 'readable' code, but IMHO Ada takes a lot longer to learn, there are more constructs, keywords, etc... In a word, the language is more complicated, yet not necessarily more powerfull (hope I don't get flamed for this :-)). In C you'd have one while loop, and you'd put your condition in the while expression and that's it. Nothing more to learn about it! What's your opinion on this? alex ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-17 0:00 ` David C. Hoos, Sr. 2000-01-17 0:00 ` tmoran ` (6 subsequent siblings) 7 siblings, 0 replies; 55+ messages in thread From: David C. Hoos, Sr. @ 2000-01-17 0:00 UTC (permalink / raw) Alexander Van Hecke <alexke@hotmail.com> wrote in message news:3882FC1C.2BA8C959@hotmail.com... > > I'd also like to point out that the "while" construct you are using is > > common for 'C' or Pascal, but in Ada you could use a "loop" construct with > > "exit when" > > > > thank you all for your response! > As many of you have pointed out, I could have used exit when ... > But as you probably noticed, I have a C background and I'm not that familiar > with Ada. I think it's a nice feature of Ada that you can write 'readable' > code, but IMHO Ada takes a lot longer to learn, there are more constructs, > keywords, etc... In a word, the language is more complicated, yet not > necessarily more powerfull (hope I don't get flamed for this :-)). In C you'd > have one while loop, and you'd put your condition in the while expression and > that's it. Nothing more to learn about it! > What's your opinion on this? > Ada makes it cleaner to exit from the middle of a loop, IMO. Try doing multi-tasking in Ada and in C if you want a real contrast where the Ada solution code is much simpler than the C. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David C. Hoos, Sr. @ 2000-01-17 0:00 ` tmoran 2000-01-17 0:00 ` Mike Silva ` (5 subsequent siblings) 7 siblings, 0 replies; 55+ messages in thread From: tmoran @ 2000-01-17 0:00 UTC (permalink / raw) >code, but IMHO Ada takes a lot longer to learn, there are more constructs, >keywords, etc... In a word, the language is more complicated, The "Pascal"ish subset is certainly pretty simple. You only need to learn the fancy stuff as you need it. As for keywords, surely the use of "{}" in if(x > 0)x=0; if(y > 0){x=0;y=0}: requires more of the beginner than if x > 0 then x := 0;end if; if y > 0 then x := 0;y := 0;end if; >In a word, the language is more complicated, >yet not necessarily more powerfull... ID2 := ID1; vs memcpy(&ID1, &ID2, sizeof ID1); where a and b can, in Ada, be characters, floats, arrays, structures, bit fields, or anything else. In Ada you can change the type of ID's from integer to string to structure to bit field without changing all the assignment statements in your program. You also only need to remember ":=", not "=" and also "memcpy". And, for those whose brilliant programming is only constrained by their typing speed, the former takes fewer, and more easily accessible, keystrokes. >> I'd also like to point out that the "while" construct you are using is >> common for 'C' or Pascal, but in Ada you could use a "loop" construct with >> "exit when" Your original "while" was perfectly legal Ada. Things like using exit statements in loops are niceties. It is true that Ada programmers tend to worry more about questions like whether while (not OK_to_proceed) loop vs loop exit when OK_to_proceed; is more likely to result in mistakes by a later maintenance programmer. That's just another aspect of "power", should you choose to use it. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David C. Hoos, Sr. 2000-01-17 0:00 ` tmoran @ 2000-01-17 0:00 ` Mike Silva 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` Brian Rogoff 2000-01-17 0:00 ` Gautier ` (4 subsequent siblings) 7 siblings, 2 replies; 55+ messages in thread From: Mike Silva @ 2000-01-17 0:00 UTC (permalink / raw) Alexander Van Hecke wrote in message <3882FC1C.2BA8C959@hotmail.com>... >...IMHO Ada takes a lot longer to learn, there are more constructs, >keywords, etc... In a word, the language is more complicated, yet not >necessarily more powerfull (hope I don't get flamed for this :-)). In C you'd >have one while loop, and you'd put your condition in the while expression and >that's it. Nothing more to learn about it! >What's your opinion on this? Since by your tone I think this is a genuine question and not a stinkbomb, here's an off-the-cuff list of Ada features I find "more powerful" than C (my primary language): Strong typing Multitasking Generics Tagged Types Packages Exceptions Discriminants Arrays indexed over arbitrary ranges, including enumerations Much greater control over variable range and representation Runtime error checking C may be one of the harder languages from which to learn Ada, since C is so forgiving (encouraging?) of "write now, think later" coding. With Ada if you try this (and what C programmer hasn't, in the beginning?) you'll just find yourself entangled in web of compiler errors. It's frustrating, but it soon becomes clear that those errors are really questions that the language is asking you -- most of which you must answer anyway (whatever your language) to solve your problem, while other Ada-specific questions (such as typing issues) are there to help keep you from making the careless mistakes that often makes programming in C an asymptotic exercise. Ada, being a language that likes to have all its ducks in a row, just asks you to answer all these questions sooner. HTH (from somebody who was where you are very recently) Mike ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Mike Silva @ 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` Gautier ` (2 more replies) 2000-01-17 0:00 ` Brian Rogoff 1 sibling, 3 replies; 55+ messages in thread From: Alexander Van Hecke @ 2000-01-17 0:00 UTC (permalink / raw) Mike Silva wrote: > Since by your tone I think this is a genuine question and not a stinkbomb, it was a genuine question :-) > > here's an off-the-cuff list of Ada features I find "more powerful" than C > (my primary language): > > Strong typing > Multitasking > Generics > Tagged Types > Packages > Exceptions > Discriminants > Arrays indexed over arbitrary ranges, including enumerations > Much greater control over variable range and representation > Runtime error checking I'm not sure why you think these features are more _powerful_ than in C. I'd label these features as more _advanced_. C is an old language (allthough I'm not sure at all about Ada), but nearly all those things you sum up are _possible_ in C, maybe they're not as easy as in Ada and require the programmer to explicitly program them (which may take a lot of code), but they're possible. Don't get me wrong, I'm not trying to make Ada look bad here, but I think my previous statement stands : suppose you have no previous programming experience whatsoever, I think that C is a lot easier to learn than Ada is. I'd say that Ada is a more advanced language (i.e. has more advanced features), as there are many languages that are more advanced than C. Again, I'm not trying to start a heavy discussion here about C versus Ada. I was just wondering what you all thought about it. I want to emphasize here that my experience with Ada is _very_ limited (and probably will stay that way, I'm using it now for an exercise I have to make - I'm a final year student computer science). I must admit, I was curious about the possibilities of Ada :-) greetings, alex ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-17 0:00 ` Gautier 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Mike Silva 2 siblings, 0 replies; 55+ messages in thread From: Gautier @ 2000-01-17 0:00 UTC (permalink / raw) << 1 Strong typing 2 Multitasking 3 Generics 4 Tagged Types 5 Packages 6 Exceptions 7 Discriminants 8 Arrays indexed over arbitrary ranges, including enumerations 9 Much greater control over variable range and representation 10 Runtime error checking >> Alexander Van Hecke: > I'm not sure why you think these features are more _powerful_ than in C. * Take the example of exceptions (but the tasking, that I don't practice, is a better one). With the years, compiler makers tend to implement them the most efficiently (zero-cost when no exception occurs, at least). If you want to program it in C, you have to invent them; for years your home-made exception model will be slow, will crash a lot etc. And it won't work on another machine, compiler or even memory model. Other C resources won't be able to use them; if they use them, exception codes will interfer. * So you will avoid exceptions, but you'll have to carry error codes everywhere in the process -> slower. (I think to Unzip - see http://members.xoom.com/gdemont/unzipada.htm ) * This is an example where features are a the same time advanced _and_ powerful. Among the list, 1,2,6,9 (at least) are effectively used by optimizers in GNAT Ada 95 and DEC Ada (83) - the compilers I know. A real Ada bonus. 1-9 save a huge portability effort, 10 (that uses 1-9) save incredible time of run-time debugging. I'll add that 1,8,9 catches most errors at compile-time: it means that the 1/100 sec of slower Ada compilation replace 1 hour of debugging in Fortran/C... > I'd label these features as more _advanced_. C is an old language (allthough I'm > not sure at all about Ada), Ada (83) is about 20 years younger... > but nearly all those things you sum up are > _possible_ in C, maybe they're not as easy as in Ada and require the programmer > to explicitly program them (which may take a lot of code), but they're > possible. Of course. You can even program it in assembler ;-). It depend ho many lifes you have to do it! Seriously: to implement basic features of Ada, say * packages (getting rid of makefiles with a working auto-make, check .h against .c) * exceptions (*working* exceptions - read c++ ngs to see that it is not trivial) * generics (same remark about c++ templates...) * strong type, with possibility of checking bounds as your home-made C preprocessor and you'll be very old! > Don't get me wrong, I'm not trying to make Ada look bad here, but I think my > previous statement stands : suppose you have no previous programming experience > whatsoever, I think that C is a lot easier to learn than Ada is. I'd say that > Ada is a more advanced language (i.e. has more advanced features), as there are > many languages that are more advanced than C. My idea about easy or not: all psychological, a question of image. * C has a better image (the funny 1960 experimental macro-assembler, the hippie era) * Ada has an horrific one (government, army, commitee, heavy, expensive). This image has improved much over the past 4 years thanks to GNAT, the Ada95 norm and fast computers that reach decent compilation times. More is to be done... A problem with Ada (IMHO): some Ada advocates are a bit arrogant, prefer to boast that one can do such and such thing in Ada instead of showing simple examples, providing resources on the Internet. Many people just didn't see Ada sources! > Again, I'm not trying to start a heavy discussion here about C versus Ada. It seems well started I fear! No problem if this is argumented and not (too) religious... -- Gautier _____\\________________\_______\ http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` Gautier @ 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Mike Silva 2 siblings, 0 replies; 55+ messages in thread From: David Starner @ 2000-01-17 0:00 UTC (permalink / raw) On Mon, 17 Jan 2000 18:19:18 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote: >Mike Silva wrote: >> here's an off-the-cuff list of Ada features I find "more powerful" than C >> (my primary language): >> >> Strong typing >> Multitasking >> Generics >> Tagged Types >> Packages >> Exceptions >> Discriminants >> Arrays indexed over arbitrary ranges, including enumerations >> Much greater control over variable range and representation >> Runtime error checking > >I'm not sure why you think these features are more _powerful_ than in C. I'd >label these features as more _advanced_. Is this more than a difference in terminology? >C is an old language (allthough I'm >not sure at all about Ada), but nearly all those things you sum up are >_possible_ in C, maybe they're not as easy as in Ada and require the programmer >to explicitly program them (which may take a lot of code), but they're >possible. Anything possible in one language is possible in another language, from a theoritical perspective. Multitasking is impossible (from a practical perspective) in C without add on libraries. Setjmp/longjmp exceptions should be much more inefficent in C then in Ada. In pure C89, there is no way to gain control over variable range, short of using outside tools like Autoconf. -- David Starner - dstarner98@aasaa.ofe.org If you wish to strive for peace of soul then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` Gautier 2000-01-17 0:00 ` David Starner @ 2000-01-17 0:00 ` Mike Silva 2000-01-18 0:00 ` Charles Hixson 2 siblings, 1 reply; 55+ messages in thread From: Mike Silva @ 2000-01-17 0:00 UTC (permalink / raw) Alexander Van Hecke wrote in message <38834F16.FE5DE77F@hotmail.com>... >> >> here's an off-the-cuff list of Ada features I find "more powerful" than C >> (my primary language): >> >> Strong typing >> Multitasking >> Generics >> Tagged Types >> Packages >> Exceptions >> Discriminants >> Arrays indexed over arbitrary ranges, including enumerations >> Much greater control over variable range and representation >> Runtime error checking > >I'm not sure why you think these features are more _powerful_ than in C. I'd >label these features as more _advanced_. C is an old language (allthough I'm >not sure at all about Ada), but nearly all those things you sum up are >_possible_ in C, maybe they're not as easy as in Ada and require the programmer >to explicitly program them (which may take a lot of code), but they're >possible. I interpreted "powerful" to mean faster and/or easier. It's true that anything you can do in Ada you can do in C, given enough manually-coded conditional statements (each of which, of course, is capable of being miscoded). Much of Ada's "power" comes from the availability of constructs that more closely or naturally map to the problem universe, while more of Ada's power comes from all the extra grunt work the compiler (and runtime) do to ensure the integrity of the problem universe; code which would have to be written manually to do the same job (but not as well) in C, assuming it got written at all. > >Don't get me wrong, I'm not trying to make Ada look bad here, but I think my >previous statement stands : suppose you have no previous programming experience >whatsoever, I think that C is a lot easier to learn than Ada is... Sometimes I wonder what language I'll teach my kids when they get old enough. It may very well be Ada, but it won't be C -- too low-level and unstructured. It's quite feasible to learn and use subsets of Ada and add on as desired. If you want Ada to be C you'll always be fighting it -- you need to make a concious decision to "write Ada" in Ada. Mike ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Mike Silva @ 2000-01-18 0:00 ` Charles Hixson 0 siblings, 0 replies; 55+ messages in thread From: Charles Hixson @ 2000-01-18 0:00 UTC (permalink / raw) I think that it was Douglas Hofstadter to invented FLOOP, the minimal language in one can write a program to do anything that can be programmed in any other computer language (of course Turing got there first, but FLOOP is more accessible). It's a really simple language. And it takes a lot of work to do anything. But by some measures of power, one can't be any more powerful. OTOH, subroutine libraries, structured programming, type checking, etc. make the actual creation of the program much easier. On this measure Ada95 does well, though most versions lack such features as built-in garbage collection, color-codeing IDE's that also help one with screen painting, and other advanced features. The core of Ada95 is designed to help one catch errors at compile time, and this is a great good, and, in itself, a "powerful" feature. It lacks other powerful features that would make it a workable RAD environment. Much of this can be fixed by further development, but there may be some limitations to a statically bound language. However, just because a dynamically bound language had different limitations doesn't mean that they are better limitations. It depends on what you need. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Mike Silva 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-17 0:00 ` Brian Rogoff 2000-02-05 0:00 ` Ashley Deas Eachus 1 sibling, 1 reply; 55+ messages in thread From: Brian Rogoff @ 2000-01-17 0:00 UTC (permalink / raw) On Mon, 17 Jan 2000, Mike Silva wrote: > Alexander Van Hecke wrote in message <3882FC1C.2BA8C959@hotmail.com>... > >...IMHO Ada takes a lot longer to learn, there are more constructs, > >keywords, etc... In a word, the language is more complicated, yet not > >necessarily more powerfull (hope I don't get flamed for this :-)). In C > you'd > >have one while loop, and you'd put your condition in the while expression > and > >that's it. Nothing more to learn about it! > >What's your opinion on this? > > > Since by your tone I think this is a genuine question and not a stinkbomb, > here's an off-the-cuff list of Ada features I find "more powerful" than C > (my primary language): > > Strong typing > Multitasking > Generics > Tagged Types > Packages > Exceptions > Discriminants > Arrays indexed over arbitrary ranges, including enumerations > Much greater control over variable range and representation > Runtime error checking C is also my primary language, and at the risk of annoying Robert Eachus :-), let me add "nested subprograms" to your list. And the ability to have local arrays whose dimension depends on a local or parameter. And ... I agree with Alexander that Ada is a larger language and to learn all of its features is much harder than to learn all of the features of C, but I've found it a much more rewarding language as well. If you're comfortable with C, just start with the C level subset of Ada and add knowledge as you need it. With Ada 95, you really do have all of the features of C worth having. The only downside is that Ada is so nice that its minor flaws look awful (e.g. lack of in/out function params) whereas in C and kin there are so many flaws that even the big ones don't bother me much ;-). -- Brian > C may be one of the harder languages from which to learn Ada, since C is so > forgiving (encouraging?) of "write now, think later" coding. With Ada if > you try this (and what C programmer hasn't, in the beginning?) you'll just > find yourself entangled in web of compiler errors. It's frustrating, but it > soon becomes clear that those errors are really questions that the language > is asking you -- most of which you must answer anyway (whatever your > language) to solve your problem, while other Ada-specific questions (such as > typing issues) are there to help keep you from making the careless mistakes > that often makes programming in C an asymptotic exercise. Ada, being a > language that likes to have all its ducks in a row, just asks you to answer > all these questions sooner. > > HTH (from somebody who was where you are very recently) > > Mike > > > > ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Brian Rogoff @ 2000-02-05 0:00 ` Ashley Deas Eachus 2000-02-05 0:00 ` Jeff Carter ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Ashley Deas Eachus @ 2000-02-05 0:00 UTC (permalink / raw) Brian Rogoff wrote: > C is also my primary language, and at the risk of annoying Robert Eachus :-), > let me add "nested subprograms" to your list. And the ability to have local > arrays whose dimension depends on a local or parameter. And ... No annoyance, or maybe a little in the terminology. ;-) I specifically distinguished between nested procedures and nested functions. But the fact that most nested procedures in Ada indicate design flaws does not mean that nested procedures are not a very powerful feature in Ada. Quite the opposite. My complaint, if you can call it that, it that nested procedures in Ada are a great design abstraction. However, when the design is realized, almost all such procedures should be transformed into more appropriate constructs. Don't use a sledgehammer to swat flies. Of course, many of the abstractons that the nested procedure can be specialized to are also powerful. In fact, nested generic procedures are more like an M1A1 tank. Unlike nested procedures however, they are not overused... > I agree with Alexander that Ada is a larger language and to learn all of > its features is much harder than to learn all of the features of C, but > I've found it a much more rewarding language as well. If you're > comfortable with C, just start with the C level subset of Ada and add > knowledge as you need it. With Ada 95, you really do have all of the > features of C worth having. Ada was designed to favor readers over writers, and a lot of the "duplicate" features are for just that purpose--to allow the author to better communicate his intent to the reader of the program. Part of the pressure on authors to favor the reader is that code that sends the wrong message looks ugly to good Ada programmers, so you will see lots of discussion here of the "best" way to implement some abstraction, even though all of the proposed language will probably generate identical machine code. So take discussions here about while loops vs. exit statements--and my comments about nested procedures--with a large grain of salt. Back to the original topic, I would probably use an array of Booleans as the best representation of the original problem: type Register is array(1..32) of Boolean; for Register'size use 32; Some_Register: Register; for Some_Register'Address use ...; pragma Volitile(Some_Register); constant Low_Order_Bit := ...; .... loop -- setup code exit when Some_Register(Low_Order_Bit); -- functional code end loop; or if you prefer: -- setup code while not Some_Register(Low_Order_Bit) loop -- functional code -- setup code end loop; As you can see, the exit when version is better when there is significant setup to be done for the test--the traditional loop and a half, and the while loop is cleaner if there is no setup required. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-02-05 0:00 ` Ashley Deas Eachus @ 2000-02-05 0:00 ` Jeff Carter 2000-02-06 0:00 ` Andy 2000-02-07 0:00 ` Brian Rogoff 2 siblings, 0 replies; 55+ messages in thread From: Jeff Carter @ 2000-02-05 0:00 UTC (permalink / raw) Ashley Deas Eachus wrote: > Back to the original topic, I would probably use an array of Booleans as > the best representation of the original problem: > > type Register is array(1..32) of Boolean; > for Register'size use 32; > Some_Register: Register; > for Some_Register'Address use ...; > pragma Volitile(Some_Register); > constant Low_Order_Bit := ...; It's scary when Robert Eachus writes something like this. Can I assume you meant Low_Order_Bit : constant Positive := ...; ? Here we have my problem with using an array of Booleans: This code is not portable. On some machines Some_Register (1) is the LSB, on others, Some_Register (32). When you move it, you have to remember to make sure that this index is correct; it's very easy to forget that check, and the code will still compile and run. The resulting error may be intermittent, and finding it may be difficult. > .... > loop > -- setup code > exit when Some_Register(Low_Order_Bit); > -- functional code > end loop; > > or if you prefer: > > -- setup code > while not Some_Register(Low_Order_Bit) > loop > -- functional code > -- setup code > end loop; > > As you can see, the exit when version is better when there is significant > setup to be done for the test--the traditional loop and a half, and the while loop > is cleaner if there is no setup required. The "exit when" version is cleaner in both cases, because it uses positive logic, which has been demonstrated to be easier to understand (at least by us mere mortals :). -- Jeff Carter "Hello! Smelly English K...niggets." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-02-05 0:00 ` Ashley Deas Eachus 2000-02-05 0:00 ` Jeff Carter @ 2000-02-06 0:00 ` Andy 2000-02-07 0:00 ` Brian Rogoff 2 siblings, 0 replies; 55+ messages in thread From: Andy @ 2000-02-06 0:00 UTC (permalink / raw) Ashley Deas Eachus wrote: > .... > loop > -- setup code > exit when Some_Register(Low_Order_Bit); > -- functional code > end loop; > > or if you prefer: > > -- setup code > while not Some_Register(Low_Order_Bit) > loop > -- functional code > -- setup code > end loop; > > As you can see, the exit when version is better when there is significant > setup to be done for the test--the traditional loop and a half, and the while loop > is cleaner if there is no setup required. Of course, when the setup is significant, you could always use a local procedure :-) ___________________________________________ Andy Starritt ___________________________________________ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-02-05 0:00 ` Ashley Deas Eachus 2000-02-05 0:00 ` Jeff Carter 2000-02-06 0:00 ` Andy @ 2000-02-07 0:00 ` Brian Rogoff 2000-02-09 0:00 ` Robert Iredell Eachus 2 siblings, 1 reply; 55+ messages in thread From: Brian Rogoff @ 2000-02-07 0:00 UTC (permalink / raw) On Sat, 5 Feb 2000, Ashley Deas Eachus wrote: > Brian Rogoff wrote: > > > C is also my primary language, and at the risk of annoying Robert Eachus :-), > > let me add "nested subprograms" to your list. And the ability to have local > > arrays whose dimension depends on a local or parameter. And ... > > No annoyance, or maybe a little in the terminology. ;-) I specifically > distinguished between nested procedures and nested functions. But the fact that > most nested procedures in Ada indicate design flaws does not mean that nested > procedures are not a very powerful feature in Ada. Quite the opposite. Hmmm, I'll have to go back and look, or simply ask you to expand on this, since from what follows I must have misunderstood your position. The time I *really* rely on nested procedures is when I'm instantiating a nested procedure as a parameter of some generic subprogram, and simulating downward funargs. Its rare that I feel I need them, and probably worse for me than for some others since it can be argued that I'm programming FP style in Ada. > My complaint, if you can call it that, it that nested procedures in Ada are a > great design abstraction. However, when the design is realized, almost all such > procedures should be transformed into more appropriate constructs. Don't use a > sledgehammer to swat flies. Of course, many of the abstractons that the nested > procedure can be specialized to are also powerful. In fact, nested generic > procedures are more like an M1A1 tank. Unlike nested procedures however, they are > not overused... I think if Ada had a better way to do downward funargs (like Bob Duff's limited access to subprogram) I would have much use for nested generic procedures any more. > > I agree with Alexander that Ada is a larger language and to learn all of > > its features is much harder than to learn all of the features of C, but > > I've found it a much more rewarding language as well. If you're > > comfortable with C, just start with the C level subset of Ada and add > > knowledge as you need it. With Ada 95, you really do have all of the > > features of C worth having. > > Ada was designed to favor readers over writers, and a lot of the > "duplicate" features are for just that purpose--to allow the author to better > communicate his intent to the reader of the program. Part of the pressure on > authors to favor the reader is that code that sends the wrong message looks ugly > to good Ada programmers, so you will see lots of discussion here of the "best" > way to implement some abstraction, even though all of the proposed language will > probably generate identical machine code. So take discussions here about while > loops vs. exit statements--and my comments about nested procedures--with a large > grain of salt. OK, but I'm still interested in why people prefer one style to another, and even if I'll often disagree (suffixes on types, use clauses, etc.) I find it important to understand the reasons for certain preferences. -- Brian ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-02-07 0:00 ` Brian Rogoff @ 2000-02-09 0:00 ` Robert Iredell Eachus 0 siblings, 0 replies; 55+ messages in thread From: Robert Iredell Eachus @ 2000-02-09 0:00 UTC (permalink / raw) Brian Rogoff wrote: > Hmmm, I'll have to go back and look, or simply ask you to expand on this, > since from what follows I must have misunderstood your position. The time > I *really* rely on nested procedures is when I'm instantiating a nested > procedure as a parameter of some generic subprogram, and simulating > downward funargs. Its rare that I feel I need them, and probably worse for > me than for some others since it can be argued that I'm programming FP > style in Ada. Exactly. There is nothing "wrong" with ordinary nested procedures. It is just that when you need context or locall declared types, the "right" abstraction is so often a generic instantiation or task entry that a nested procedure has become a red flag to me. Try this. Take some random package body that contains nested procedures, and move all the nested procedures out into the package body. Does the package compile and run just fine? Incidently, if you look through the gnat source, I will probably appear to be the most egregious violators of this rule. (My sins appear in the run-time packages for the IS Annex, in processing Picture strings. However, recursive descent parsers are a very special case... ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke ` (2 preceding siblings ...) 2000-01-17 0:00 ` Mike Silva @ 2000-01-17 0:00 ` Gautier 2000-01-18 0:00 ` Keith Thompson 2000-01-17 0:00 ` Matthew Heaney ` (3 subsequent siblings) 7 siblings, 1 reply; 55+ messages in thread From: Gautier @ 2000-01-17 0:00 UTC (permalink / raw) > In C you'd > have one while loop, and you'd put your condition in the while expression and > that's it. Nothing more to learn about it! > What's your opinion on this? The situation seems the same to me: both have for and while loops. Ada has a conditionless loop in addition. Isn't there an exit statement in C ? (I'm in the reverse situation...) -- Gautier _____\\________________\_______\ http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Gautier @ 2000-01-18 0:00 ` Keith Thompson 2000-01-19 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 55+ messages in thread From: Keith Thompson @ 2000-01-18 0:00 UTC (permalink / raw) Gautier <gautier.demontmollin@maths.unine.ch> writes: > The situation seems the same to me: both have for and while loops. Ada has > a conditionless loop in addition. Isn't there an exit statement in C ? Yes, C's break statement is similar to Ada's exit statement. A major difference is that a C break statement terminates the innermost enclosing loop or switch statement; it doesn't let you terminate an outer loop. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Keith Thompson @ 2000-01-19 0:00 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 55+ messages in thread From: Ole-Hjalmar Kristensen @ 2000-01-19 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > Gautier <gautier.demontmollin@maths.unine.ch> writes: > > The situation seems the same to me: both have for and while loops. Ada has > > a conditionless loop in addition. Isn't there an exit statement in C ? > > Yes, C's break statement is similar to Ada's exit statement. A major > difference is that a C break statement terminates the innermost > enclosing loop or switch statement; it doesn't let you terminate an > outer loop. > > -- > Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> > San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> > Welcome to the last year of the 20th century. C also has the continue statement. which is not so widely used, but which is handy sometimes. Btw., I really like the Ada loop constructs, especially the exit <named loop> construct which you mentioned. The C for statement is very general, but I have a nagging feeling that in many instances a construct like Ada's loop ... exit when ... ... end loop; is a more maintainable alternative than trying to cram too much into the for(...) part of a C for loop. -- E pluribus Unix ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke ` (3 preceding siblings ...) 2000-01-17 0:00 ` Gautier @ 2000-01-17 0:00 ` Matthew Heaney 2000-01-17 0:00 ` Jeff Carter ` (2 subsequent siblings) 7 siblings, 0 replies; 55+ messages in thread From: Matthew Heaney @ 2000-01-17 0:00 UTC (permalink / raw) In article <3882FC1C.2BA8C959@hotmail.com> , Alexander Van Hecke <alexke@hotmail.com> wrote: > But as you probably noticed, I have a C background and I'm not that familiar > with Ada. I think it's a nice feature of Ada that you can write 'readable' > code, but IMHO Ada takes a lot longer to learn, there are more constructs, > keywords, etc... In a word, the language is more complicated, yet not > necessarily more powerfull (hope I don't get flamed for this :-)). In C you'd > have one while loop, and you'd put your condition in the while expression and > that's it. Nothing more to learn about it! > What's your opinion on this? But you could have written your loop without using while: for (;;) { -- do something if (data & 1) break; } In Ada, instead of using a null for loop to do the job, we just use a loop. As far as keywords go, I consider that a specious comparison. In C, you have to know which operator symbol to use, and then try to remember the difference between "&" and "&&". Ouch! In Ada, if you want to do a bitwise and expression, you just say "and", which is more natural. In this case, it is *easier* to learn Ada than C. -- If we let the Creationists have their way, we may as well go whole hog. Let us reintroduce the flat-earth theory, the chemistry of the four elements, and mediaeval astrology. For these outworn doctrines have just as much claim to rival current scientific views as Creationism does to challenge evolutionary biology. Abusing Science: The Case Against Creationism Philip Kitcher ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke ` (4 preceding siblings ...) 2000-01-17 0:00 ` Matthew Heaney @ 2000-01-17 0:00 ` Jeff Carter 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-18 0:00 ` bitwise comparators Ted Dennison 2000-01-18 0:00 ` DuckE 7 siblings, 1 reply; 55+ messages in thread From: Jeff Carter @ 2000-01-17 0:00 UTC (permalink / raw) In article <3882FC1C.2BA8C959@hotmail.com>, Alexander Van Hecke <alexke@hotmail.com> wrote: > But as you probably noticed, I have a C background and I'm not that familiar > with Ada. I think it's a nice feature of Ada that you can write 'readable' > code, but IMHO Ada takes a lot longer to learn, there are more constructs, > keywords, etc... In a word, the language is more complicated, yet not > necessarily more powerfull (hope I don't get flamed for this :-)). In C you'd > have one while loop, and you'd put your condition in the while expression and > that's it. Nothing more to learn about it! > What's your opinion on this? Of course Ada takes longer to learn than C. Ada is a high-level language (averaging 41 statements to implement a function point) and C is a low-level language (128 statements/function point). Ada has packages, private types, exceptions, generics, tasks, protected objects, block statements, fixed-point types, user-defined numeric types, true enumeration types, true arrays, and record types with discriminants, none of which are found in C. C just has integers, floating-point numbers, pointers, and functions, so of course Ada takes longer to learn. As for being "more powerfull", there are different forms of power. The terseness of C that you refer to is one of its weaknesses, while Ada's readability is one of the most powerful qualities a language can have. Ada makes creating and using abstractions easier than C (packages for encapsulation and information hiding; private types for information hiding). Ada makes code reuse easier than C (packages for namespace control; generics for tailoring). Ada makes handling exceptional situations easier and more readable (exceptions and exception handlers; block statements for localizing scope). Ada makes concurrent code much easier and more readable (tasks, protected objects, time types). -- Jeff Carter "Now go away or I shall taunt you a second time." -- Monty Python and the Holy Grail Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Jeff Carter @ 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner ` (4 more replies) 0 siblings, 5 replies; 55+ messages in thread From: Alexander Van Hecke @ 2000-01-17 0:00 UTC (permalink / raw) This seems like an attack on C/C++! I'm sorry, but I have to react on this > Ada has > packages, C was ment to be used modular and for reuse : put your code in separate .c and .h files. > private types, C has that! > exceptions, you can program exceptions in C. I never said that C has all these things, but you can program them, and there are masses of libraries available that have just what you need. > generics, use structs and callback functions and you have perfect generic types! > tasks, threads true enumeration types, true arrays, enumeration types in Ada are no different than they are in C. Just because you have some fancy attributes (SUCC, PRED) doesn't mean that they are different or more powerful! You can write functions that do exactly the same, even more, these functions have already been written numerous times and are available. With true arrays, do you mean out of bound checking, etc? This can be done with _proper_ programming in C! none of which are found in C. ^^^^^^^^^^^^^^^^^^^^^^^ ahum. > C just has integers, floating-point numbers, pointers, and functions, so > of course Ada takes > longer to learn. > > Ada makes creating and using abstractions easier than C (packages for > encapsulation and information hiding; private types for information > hiding). Would you agree that C++ is just as good in that as Ada. Don't forget that ANY C++ code can be easily translated into C? For that matter, everything else you mentioned (namespace control, (easy) generics, exceptions and exception handlers, typing) is easily achieved in C++ (and thus C). As I have said already a few times, and as I said in my original post : I THINK IT'S A NICE FEATURE OF ADA THAT YOU CAN WRITE READABLE CODE, BUT THAT DOES NOT NECESSARILY MEAN THAT THE LANGUAGE IS MORE POWERFUL! It might be easier to use once you've mastered it, but it also is harder to learn. excuse me for being so impolite, but I had to get this off my chest. alex ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-18 0:00 ` Ted Dennison 2000-01-17 0:00 ` Gautier ` (3 subsequent siblings) 4 siblings, 2 replies; 55+ messages in thread From: David Starner @ 2000-01-17 0:00 UTC (permalink / raw) On Mon, 17 Jan 2000 20:26:42 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote: >This seems like an attack on C/C++! I'm sorry, but I have to react on this > >> Ada has >> packages, > >C was ment to be used modular and for reuse : put your code in separate .c >and .h files. int mktemp() can conflict with something in another file. No use of header files can fix that. David.library.mktemp never will. > >> private types, > >C has that! C has access control? Where? >> exceptions, > >you can program exceptions in C. But it doesn't have them, and good exception handling needs to be handled by the compiler. >> generics, > >use structs and callback functions and you have perfect generic types! No type safety, large runtime overhead, and poor readibility is perfect? >> tasks, > >threads Which aren't a part of C, and most thread libraries aren't portable among systems (Unix -> Windows -> Mac -> bare hardware). >With true arrays, do you mean out of bound checking, etc? This can be done >with _proper_ programming in C! So in other words, with enough work, you can add real arrays to C? The point is you have to add them, they don't come with the language. >none of which are found in C. >^^^^^^^^^^^^^^^^^^^^^^^ >ahum. It's correct. Because you can add them, doesn't mean they're found in the language. >> C just has integers, floating-point numbers, pointers, and functions, so >> of course Ada takes >> longer to learn. >> >> Ada makes creating and using abstractions easier than C (packages for >> encapsulation and information hiding; private types for information >> hiding). > >Would you agree that C++ is just as good in that as Ada. No. >Don't forget that >ANY C++ code can be easily translated into C? No. With sufficent work, C++ code can be translated into C, but you're going to rewrite several core systems in process. You're going to have to munge names, write vtables and all sorts of grungy stuff. >For that matter, everything else you mentioned (namespace control, (easy) >generics, exceptions and exception handlers, typing) is easily achieved in >C++ (and thus C). Not and thus C. It's not that simple. And frequently, your implementations are going to be low quality without some very low level and implemenation specific work. -- David Starner - dstarner98@aasaa.ofe.org If you wish to strive for peace of soul then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` David Starner @ 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner ` (2 more replies) 2000-01-18 0:00 ` Ted Dennison 1 sibling, 3 replies; 55+ messages in thread From: Alexander Van Hecke @ 2000-01-17 0:00 UTC (permalink / raw) > > C has access control? Where? the items you put in a struct are default public. private is a C keyword though. It is perfectly possible to hide some data items. > > > >> exceptions, > > > >you can program exceptions in C. > But it doesn't have them, and good exception handling needs to > be handled by the compiler. > > >> generics, > > > >use structs and callback functions and you have perfect generic types! > No type safety, large runtime overhead, and poor readibility is perfect? > > >> tasks, > > > >threads > Which aren't a part of C, and most thread libraries aren't portable among > systems (Unix -> Windows -> Mac -> bare hardware). > I understand what you're saying, and you're right too! As I already said, Ada is a programming language of a later generation, and thus has more features ( = things you could do with previous generation languages, but were perhaps difficult / erroneous to program) that the compiler does for you. Never forget that this almost always has a direct impact on the speed of your programs (cfr. Java which resembles C++ (not in every point of course) but is WAY slower because of all kinds of automatic checking / copying / testing ...)! However, this does not mean that you can do 'more' with this language. I think I should have explained more carefully what I mean by 'powerful' : it has nothing to do with how complicated your compiler is (and I will be fair, it's very good if your compiler checks for errors (like typing errors) that are otherwise hard to find), but I'd say it's the ability of a language to be _able_ to program everything you want to, _even if the language was not designed to solve the problem you're trying to solve_! In this way Prolog is a very powerful language for AI programs, but it's really poor when it comes to, let's say, string manipulation. I think that is a good point for C : easy to learn, possibilities are enormous, used everywhere (OSses, programs, ...), and very extendible. I can't think of anything that can not be written in C. I must say, I had never heard of Ada except for the context of embedded systems. > > >With true arrays, do you mean out of bound checking, etc? This can be done > >with _proper_ programming in C! > So in other words, with enough work, you can add real arrays to C? The point > is you have to add them, they don't come with the language. Indeed you're right. > >Don't forget that > >ANY C++ code can be easily translated into C? > No. With sufficent work, C++ code can be translated into C, but you're > going to rewrite several core systems in process. You're going to have > to munge names, write vtables and all sorts of grungy stuff. I know with certainty that the first couple of versions of the GNU C++ compiler, which is by the way a very respected and widespread compiler, did just that : converting C++ to C and then compiling this code with the usual gcc compiler. I rephrase : 'any C++ code can be translated to C code'. I do not want to start a war here between C/C++ and Ada! Both of the languages have their pro and cons. greetings, alex ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-17 0:00 ` David Starner 2000-01-18 0:00 ` Preben Randhol 2000-01-18 0:00 ` Fraser 2 siblings, 0 replies; 55+ messages in thread From: David Starner @ 2000-01-17 0:00 UTC (permalink / raw) [It would be easier if you kept lines below 75-80 characters. Thanks.] On Mon, 17 Jan 2000 22:23:18 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote: >> >> C has access control? Where? > >the items you put in a struct are default public. >private is a C keyword though. It >is perfectly possible to hide some data items. No, private is not a ISO C89 keyword. My books don't mention it, and gcc (an ISO C compiler) gives a parse error for struct bob {private: int a;}; it gives no error for struct bob {int private;};, which it should if private is a reserved word. I think you've been confused by a bad C/C++ compiler. >but I'd say it's the ability of a language to be _able_ to program >everything you want to, _even if the language was not designed to solve >the problem you're trying to solve_! In this way Prolog is a very >powerful language for AI programs, but it's really poor when it comes to, >let's say, string manipulation. That's a bad definition. Computing theory says the problems you can solve with Bourne shell scripts is exactly equal to the problems you can solve in C or Prolog or Intercal or an assembly language with one instruction (decrement and jump if zero.) >I know with certainty that the first couple of versions of the GNU C++ >compiler, which is by the way a very respected and widespread compiler, >did just that : converting C++ to C and then compiling this code with >the usual gcc compiler. No. cfront (an early C++ compiler by Stroustroup) did that, but the GNU C++ compiler has always been a native compiler. >I rephrase : 'any C++ code can be translated >to C code'. Any C++ code can be translated to Lisp or Ada, too. But you said it could be done easily, which is the contestable point. -- David Starner - dstarner98@aasaa.ofe.org If you wish to strive for peace of soul then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner @ 2000-01-18 0:00 ` Preben Randhol 2000-01-18 0:00 ` Fraser 2 siblings, 0 replies; 55+ messages in thread From: Preben Randhol @ 2000-01-18 0:00 UTC (permalink / raw) Alexander Van Hecke <alexke@hotmail.com> writes: | > | > C has access control? Where? | | the items you put in a struct are default public. private is a C keyword though. It | is perfectly possible to hide some data items. No it isn't. I think you are talking of C++ here not C. -- Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/] "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner 2000-01-18 0:00 ` Preben Randhol @ 2000-01-18 0:00 ` Fraser 2000-01-18 0:00 ` Bertrand Augereau 2 siblings, 1 reply; 55+ messages in thread From: Fraser @ 2000-01-18 0:00 UTC (permalink / raw) paene lacrimavi postquam Alexander Van Hecke <alexke@hotmail.com> scripsit: > I understand what you're saying, and you're right too! > As I already said, Ada is a programming language of a > later generation, and thus has more features ( = things > you could do with previous generation languages, but > were perhaps difficult / erroneous to >program) that > the compiler does for you. Never forget that this almost > always has a direct impact on the speed of your programs > (cfr. Java which resembles C++ (not in every point of > course) but is WAY slower because of all kinds of automatic > checking / copying / testing ...)! Java is slower because of the VM, which most compilers target. This has little to do with the checking that Java has to do, which is not much. The performance impact of run time checks is not as heavy as you might think, because the Ada compiler has access to an awful lot of type information that can be used to remove a bunch of them. Sure, you can use a class to implement a checked array type in C++, but how on earth do you safely optimise these checks away? Safe Ada can be much faster than safe C++. I say "can be" rather than "is" because I'm too scared issue general pronouncements like that, but in my experience the word "is" is appropriate. > However, this does not mean that you can do 'more' with this > language. In principle, no, but in practice a language that allows you to get where you need to be faster and with less errors is a language that allows you to do more. Instead of tracking down array bounds violations, and fiddly pointer references, I can write more code. > I think I should have explained more carefully what I mean by 'powerful' : [ ... ] > I'd say it's the ability of a language to be _able_ to program > everything you want to, _even if the language was not designed > to solve the problem you're trying to solve_! This is not a useful definition, because it includes just about everything! I am "able" to program any particular task with a large number of languages. Where's the distinction? > In this way Prolog is a very powerful language for AI > programs, but it's really poor when it comes to, let's > say, string manipulation. Prolog has great string manipulation. A string is just a list of characters, and handling lists is something Prolog is very good at. > I think that is a good point for C : easy to learn, possibilities > are enormous, used everywhere (OSses, programs, ...), and very extendible. C is not easy to learn. Students have to deal with pointers at a very early stage, and this is unfortunate. IMHO. What do you mean by extensible? > I can't think of anything that can not be written in C. Write me a C program that determines whether another program terminates :) > I must say, I had never heard of Ada except for the context of > embedded systems. Personally, I've used Ada for compilers, natural language understanding, an interactive fiction engine, a medieval computer war game, an editor, an editor extension language, a parser generator, a database system, a large multiplayer game, a chip emulator, and a bunch of other stuff which I can't remember just now. The closest I've come to embedded systems is targeting an Ada compiler to the Commodore 64. cheers, Fraser. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Fraser @ 2000-01-18 0:00 ` Bertrand Augereau 2000-01-19 0:00 ` Ted Dennison 0 siblings, 1 reply; 55+ messages in thread From: Bertrand Augereau @ 2000-01-18 0:00 UTC (permalink / raw) By the way, does somebody know any commercial game that was (even partly) written using Ada? ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Bertrand Augereau @ 2000-01-19 0:00 ` Ted Dennison 2000-01-19 0:00 ` Marin D. Condic 0 siblings, 1 reply; 55+ messages in thread From: Ted Dennison @ 2000-01-19 0:00 UTC (permalink / raw) In article <862pgc$ae6$1@netserv.univ-lille1.fr>, "Bertrand Augereau" <Augereau.Bertrand@ec-lille.fr> wrote: > By the way, does somebody know any commercial game that was (even > partly) written using Ada? I know of quite a few flight simulators that were written in Ada. They'd all cost more that the average Joe is willing to shell out. (Motion bases and domed projection systems aren't cheap.) But some of them are sold commercially. If you've got the dough, the appropriate companies would be more than happy to sell you one. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-19 0:00 ` Ted Dennison @ 2000-01-19 0:00 ` Marin D. Condic 2000-01-19 0:00 ` Ted Dennison 0 siblings, 1 reply; 55+ messages in thread From: Marin D. Condic @ 2000-01-19 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <862pgc$ae6$1@netserv.univ-lille1.fr>, > "Bertrand Augereau" <Augereau.Bertrand@ec-lille.fr> wrote: > > By the way, does somebody know any commercial game that was (even > > partly) written using Ada? > > I know of quite a few flight simulators that were written in Ada. They'd > all cost more that the average Joe is willing to shell out. (Motion > bases and domed projection systems aren't cheap.) But some of them > are sold commercially. If you've got the dough, the appropriate > companies would be more than happy to sell you one. > Isn't that the wonderful part of our industry? They let us play with the world's most expensive and sophisticated video games all day long and then, once a week, whether we need it or not, they give us a paycheck! :-) MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Capitalism without failure is like religion without sin." -- Allan Meltzer, Economist ============================================================= ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-19 0:00 ` Marin D. Condic @ 2000-01-19 0:00 ` Ted Dennison 0 siblings, 0 replies; 55+ messages in thread From: Ted Dennison @ 2000-01-19 0:00 UTC (permalink / raw) In article <3885F3D8.CB073BFF@quadruscorp.com>, "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote: > Isn't that the wonderful part of our industry? They let us play with > the world's most expensive and sophisticated video games all day long > and then, once a week, whether we need it or not, they give us a > paycheck! :-) I might have some empathy with that viewpoint. But as its remotely possible that my boss might one day see this message, I'd rather take this oppertunity to express how incredibly hard the work is, and the best college we'll be able to afford for our kids may be Burger U. :-) -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-18 0:00 ` Ted Dennison 1 sibling, 0 replies; 55+ messages in thread From: Ted Dennison @ 2000-01-18 0:00 UTC (permalink / raw) In article <85vr1s$9qe1@news.cis.okstate.edu>, dstarner98@aasaa.ofe.org wrote: > On Mon, 17 Jan 2000 20:26:42 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote: > >This seems like an attack on C/C++! I'm sorry, but I have to react on this > > > >> Ada has > >> packages, > > > >C was ment to be used modular and for reuse : put your code in > >separate .c and .h files. > Its tough to keep a straight face while reading this. You must not have used the packging features of languages like Ada and Modula much to make this statement. There simply is no comparison in the amount of modularity and reusability between them. > int mktemp() can conflict with something in another file. No use of > header files can fix that. A real-world example: We are using vxWorks here at work. xvWorks has no processes, every task in the system is effectively a lightweight thread. You can kind of think of the entire system, kernel and all, as one big program. We had some C code to handle reading of radio database files developed for previous projects that we decided to reuse in our system, rather than rewrite it in Ada (a quite sensible decision). When we took this system out to the hardware, we had a devil of a time getting networking to do anything. We eventually discovered that we couldn't even ping the loopback address succesfully. That made no sense whatsoever. After a couple of days, one of the engineers found the problem. This completely unrelated reused C code of ours had a routine named "checksum". Apparently, the TCP/IP stack *also* has a checksum routine, and they are not the same. Now a longtime C programmer would probably be indignant that neither author used the standard idiom (aka: hack) of tacking on some kind of namespace designator to the front of the routine's name to prevent this kind of disasterous clash. But the engineer in you should realize that it is silly to yell at someone for screwing up when they have been presented with an error-prone system in the first place. Someone was *bound* to screw up eventually. In Ada this won't happen, because in Ada everything automaticly has its package's namespace, and the default is *not* to export the symbol to the system. If there is a namespace clash, the code won't compile in the first place. So we *never* have any such trouble with our Ada routines. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner @ 2000-01-17 0:00 ` Gautier 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-18 0:00 ` Ted Dennison 2000-01-18 0:00 ` Jeff Carter ` (2 subsequent siblings) 4 siblings, 2 replies; 55+ messages in thread From: Gautier @ 2000-01-17 0:00 UTC (permalink / raw) Alexander Van Hecke wrote: > This seems like an attack on C/C++! I'm sorry, but I have to react on this > > Ada has packages, > C was ment to be used modular and for reuse : put your code in separate .c > and .h files. I feel you miss something. The .h files are just included texts; the `defines' in one can influence another so the inclusion order is delicate; there is no link (apart a moral one) between the .h and the .c and - correct me if I'm wrong - a standard C compiler won't check the integrity between .h and .c ... In addition, the most resources on the Net break your .h <-> .c rule... > > exceptions, > you can program exceptions in C. I never said that C has all these things, > but you can program them, and there are masses of libraries available that > have just what you need. Aaah but are they compatible between each other ? Maybe there are masses of incompatible libraries ? And masses of software component that use these incompatible libraries (I hope no)? Your argument is valid if you're toying with _your_ exceptions, on _your_ PC... So C hasn't this feature; it can be simulated, with some effort. Ada has it. So, where is the problem ? You could invent a language without subprograms and say: <<it's easy, I just have to paste the code where it is needed>>... Without loops: <<just if's and goto's>>. Without types at all - detected at run-time. Such regressive trends exist, but (1) does it help the programmer and (2) does it lead to efficient code (optimized subtypes, generics, exceptions, inlining) ? > > generics, > use structs and callback functions and you have perfect generic types! You imagine a rather inefficient way to implement generics. Try the _real_ genericity and see how an Ada compiler instanciates it at compile-time, optimized... Wouldn't a C macro better fit (question) ? Too much energy for holy war tonight - I prefer programming. My advice: Take some time to learn the <<Pascal subset>>, take a week to toy with Ada (the programming language, I mean), make _your_ idea if you can! -- Gautier _____\\________________\_______\ http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Gautier @ 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner 2000-01-18 0:00 ` Gautier 2000-01-18 0:00 ` Ted Dennison 1 sibling, 2 replies; 55+ messages in thread From: Alexander Van Hecke @ 2000-01-17 0:00 UTC (permalink / raw) > > > > use structs and callback functions and you have perfect generic types! > > You imagine a rather inefficient way to implement generics. As a matter of fact, this way is more efficient than using templates! Templates have to be copied and filled in -> lots of overhead. If you use callback functions in structs, all you have to do is link the correct pointers to the adresses of the functions and that's it. greetings, alex ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-17 0:00 ` David Starner 2000-01-18 0:00 ` Gautier 1 sibling, 0 replies; 55+ messages in thread From: David Starner @ 2000-01-17 0:00 UTC (permalink / raw) On Mon, 17 Jan 2000 22:28:41 +0100, Alexander Van Hecke <alexke@hotmail.com> wrote: >> > use structs and callback functions and you have perfect generic types! >> >> You imagine a rather inefficient way to implement generics. > >As a matter of fact, this way is more efficient than using >templates! Templates have to be copied and filled in -> >lots of overhead. If you use callback functions in structs, >all you have to do is link the correct pointers to the >adresses of the functions and that's it. It sounds like you're complaining about compile time work, which is irrelevant in most cases. Templates are not copied and filled in at runtime. Templates are efficent at runtime, unlike your method, especially for numeric work (you're substituting a call to a function for every addition in the code. That kills performance.) -- David Starner - dstarner98@aasaa.ofe.org If you wish to strive for peace of soul then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner @ 2000-01-18 0:00 ` Gautier 1 sibling, 0 replies; 55+ messages in thread From: Gautier @ 2000-01-18 0:00 UTC (permalink / raw) Alexander Van Hecke wrote: > > > use structs and callback functions and you have perfect generic types! > > You imagine a rather inefficient way to implement generics. > As a matter of fact, this way is more efficient than using templates! Templates have to > be copied and filled in -> lots of overhead. If you use callback functions in structs, > all you have to do is link the correct pointers to the adresses of the functions and > that's it. I see - indeed for some "percent bar" feedback purposes I do so if callback doen't need to be inlined+optimized. It saves space. But genericity embrace more than functions but all sorts of parameters. One usage is to produce lots of overhead, but for each instance an optimized code for it. A trivial example of it is the PKZip `explode' method that appears in 2 versions, almost the same, apart of 2 parameters. As variables they would slow down the code, so it is preferable to instanciate twice the code with these numbers built-in and let the optimizer squeeze the shifts etc. But, only one copy of source is needed generic needed: integer; mask: unsigned_32; procedure explode_lit ( tb, tl, td : p_Table_list; bb, bl, bd : integer ); (etc.) Then, the instanciations: -- **************** exploding, method: 8k slide, 3 trees ***************** procedure explode_lit8 is new explode_lit( 7, 16#7F# ); -- **************** exploding, method: 4k slide, 3 trees ***************** procedure explode_lit4 is new explode_lit( 6, 16#3F# ); See http://members.xoom.com/_XMCM/gdemont/uza_html/unz_expl__adb.htm#60_11 For that a C macro would fit a best, wouldn't it ? But you can do more abstracted things like... generic -- to provide: type ring_elt is private; -- ring element type zero, one: ring_elt; -- 0 and 1 elements with function "-" (a:ring_elt) return ring_elt; -- unary oper. with function "+" (a,b:ring_elt) return ring_elt; -- binary oper. with function "*" (a,b:ring_elt) return ring_elt; package Frac is type frac_elt is record a,b:ring_elt; end record; -- define fraction frac_0: constant frac_elt:= (zero,one); frac_1: constant frac_elt:= (one,one); (...) and use it for creating rational numbers: package Rationals is new Frac_Euclid(Integer, 0,1, "-","+","-","*","/"); then rational polynomials: package Rationals.Polynomials is new Polynomials( frac_elt, frac_0, frac_1, "-","+","-","*","/","=" ); then using Frac again to create rational functions! (end of generic trip - the subject is so wide... ) -- Gautier _____\\________________\_______\ http://members.xoom.com/gdemont/ ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Gautier 2000-01-17 0:00 ` Alexander Van Hecke @ 2000-01-18 0:00 ` Ted Dennison 1 sibling, 0 replies; 55+ messages in thread From: Ted Dennison @ 2000-01-18 0:00 UTC (permalink / raw) In article <388394E0.55D1E913@maths.unine.ch>, Gautier <gautier.demontmollin@maths.unine.ch> wrote: > Alexander Van Hecke wrote: > > > C was ment to be used modular and for reuse : put your code in > > separate .c and .h files. > > I feel you miss something. The .h files are just included texts; the > `defines' in one can influence another so the inclusion order is > delicate; there is no link (apart a moral one) between the .h and the > .c and - correct me if I'm wrong - a standard C compiler won't check > the integrity between .h and .c ... In addition, the most resources on > the Net break your .h <-> .c rule... That's just about the biggest problem in my book. Using ".h" files that way is just a convention that many C developers follow. There's no teeth to it, and there are many other ways the include feature can be (ab)used. For instance, I've seen several C systems where included files have no extention (".h") on them. There are even several places in the vxWorks kernel source code where ".c" files are #include'd. I can be indignant that the developers would do such a thing to poor unsuspecting readers like myself, but its perfectly legal (and running) C. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Gautier @ 2000-01-18 0:00 ` Jeff Carter 2000-01-18 0:00 ` Keith Thompson 2000-01-18 0:00 ` Pascal Obry 2000-01-21 0:00 ` Ada vs. C/C++ (was re: bitwise something-or-other) Mark Lundquist 4 siblings, 1 reply; 55+ messages in thread From: Jeff Carter @ 2000-01-18 0:00 UTC (permalink / raw) Alexander Van Hecke wrote: > > This seems like an attack on C/C++! I'm sorry, but I have to react on this It wasn't meant as an attack, merely an enumeration of why Ada takes longer to learn than C. > > > Ada has > > packages, > > C was ment to be used modular and for reuse : put your code in separate .c > and .h files. These do not provide the many benefits of packages. > > > private types, > > C has that! I've never seen them. > > > exceptions, > > you can program exceptions in C. I never said that C has all these things, > but you can program them, and there are masses of libraries available that > have just what you need. This is an unhelpful definition of "powerful". Since all C is translated into machine code, and there are frequently things you can do in machine code that you can't do in C, machine code is more powerful than C by this definition. Is this an argument for using machine code rather than C? The power of a language comes from its readability, expressiveness, and the amount of work it takes off your hands. > > > generics, > > use structs and callback functions and you have perfect generic types! In my experience, you have perfectly unreadable code. > > > tasks, > > threads Not part of C. > > true enumeration types, true arrays, > enumeration types in Ada are no different than they are in C. Just because > you have some fancy attributes (SUCC, PRED) doesn't mean that they are > different or more powerful! You can write functions that do exactly the > same, even more, these functions have already been written numerous times > and are available. A C enumeration merely defines some named integers. An Ada enumeration is a different animal altogether. > With true arrays, do you mean out of bound checking, etc? This can be done > with _proper_ programming in C! C does not have arrays; it only has different notations for address arithmetic. > > none of which are found in C. > ^^^^^^^^^^^^^^^^^^^^^^^ > ahum. > > > C just has integers, floating-point numbers, pointers, and functions, so > > of course Ada takes > > longer to learn. > > > > Ada makes creating and using abstractions easier than C (packages for > > encapsulation and information hiding; private types for information > > hiding). > > Would you agree that C++ is just as good in that as Ada. Don't forget that > ANY C++ code can be easily translated into C? So can any Ada code; Averstar sells an Ada compiler that generates C. This has nothing to do with features of Ada that C lacks. This is not an indictment of C; C and Ada have a different philosophies. It does explain why Ada takes longer to learn than C. > For that matter, everything else you mentioned (namespace control, (easy) > generics, exceptions and exception handlers, typing) is easily achieved in > C++ (and thus C). > > As I have said already a few times, and as I said in my original post : I > THINK IT'S A NICE FEATURE OF ADA THAT YOU CAN WRITE READABLE CODE, BUT THAT > DOES NOT NECESSARILY MEAN THAT THE LANGUAGE IS MORE POWERFUL! It might be > easier to use once you've mastered it, but it also is harder to learn. > > excuse me for being so impolite, but I had to get this off my chest. > > alex If the only definition of "powerful" is "able to implement anything" than all languages are equally powerful, and there is no basis for choosing one over the other. I think we all agree that there are important differences between languages that lead people to choose one over another; in many cases the most important difference is "I learned X first" :) This seems like a useless definition of the power of a language to me. -- Jeff Carter "Hello! Smelly English K...niggets." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Jeff Carter @ 2000-01-18 0:00 ` Keith Thompson 2000-01-19 0:00 ` Jeff Carter ` (2 more replies) 0 siblings, 3 replies; 55+ messages in thread From: Keith Thompson @ 2000-01-18 0:00 UTC (permalink / raw) Jeff Carter <jrcarter010@earthlink.net> writes: [...] > > With true arrays, do you mean out of bound checking, etc? This can be done > > with _proper_ programming in C! > > C does not have arrays; it only has different notations for address > arithmetic. That's a slight exaggeration. C does have array types and array objects. For example this: int a[10]; declares a as an array of 10 ints, very much like Ada's A: array(0 .. 9) of Integer; It does not, contrary to popular misconception, declare a as a pointer. What often causes confusion is that, in most expression contexts, a reference to the name of an array object "decays" to a pointer to the array's first element. C arrays are not first-class types, but they do exist. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Keith Thompson @ 2000-01-19 0:00 ` Jeff Carter 2000-01-19 0:00 ` Keith Thompson 2000-01-19 0:00 ` David Starner 2000-01-19 0:00 ` Ole-Hjalmar Kristensen 2000-01-19 0:00 ` Gisle S�lensminde 2 siblings, 2 replies; 55+ messages in thread From: Jeff Carter @ 2000-01-19 0:00 UTC (permalink / raw) Keith Thompson wrote: > > Jeff Carter <jrcarter010@earthlink.net> writes: > [...] > > C does not have arrays; it only has different notations for address > > arithmetic. > > That's a slight exaggeration. C does have array types and array > objects. For example this: > int a[10]; > declares a as an array of 10 ints, very much like Ada's > A: array(0 .. 9) of Integer; > It does not, contrary to popular misconception, declare a as a > pointer. That would explain why a[0] and *a are different notations for the same thing, and a[2], *(a+2), and 2[a] are also different notations for the same thing. a[2] is defined as a shortcut for *(a+2), which is why 2[a] works. The "array" notation in C is a different notation for address arithmetic. I stand by my statement. Meanwhile, in Ada, A (0) and A (2) are legal, but A.all, 2 (A), and (A + 2).all give compiler errors. > Welcome to the last year of the 20th century. You've got that right. -- Jeff Carter "I fart in your general direction." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-19 0:00 ` Jeff Carter @ 2000-01-19 0:00 ` Keith Thompson 2000-01-19 0:00 ` David Starner 1 sibling, 0 replies; 55+ messages in thread From: Keith Thompson @ 2000-01-19 0:00 UTC (permalink / raw) Jeff Carter <jrcarter010@earthlink.net> writes: > Keith Thompson wrote: > > Jeff Carter <jrcarter010@earthlink.net> writes: > > [...] > > > C does not have arrays; it only has different notations for address > > > arithmetic. > > > > That's a slight exaggeration. C does have array types and array > > objects. For example this: > > int a[10]; > > declares a as an array of 10 ints, very much like Ada's > > A: array(0 .. 9) of Integer; > > It does not, contrary to popular misconception, declare a as a > > pointer. > > That would explain why a[0] and *a are different notations for the same > thing, and a[2], *(a+2), and 2[a] are also different notations for the > same thing. a[2] is defined as a shortcut for *(a+2), which is why 2[a] > works. The "array" notation in C is a different notation for address > arithmetic. I stand by my statement. C does have arrays; it just defines some of the operations on arrays in terms of lower-level operations, exposing some of the nuts and bolts that Ada (wisely, IMHO) hides. For example, "&a" yields the address of a, and is of type "pointer of array of 10 ints", not "pointer to int". Similarly, "sizeof a" yields the size of the array, not the size of a pointer. If a structure member is an array, the full space for the array is allocated in each object of the structure type, and the structure can be assigned and passed by copy. C arrays are *partly* built on the lower-level concept of pointers, but not entirely. Section 6 of the C FAQ, at <http://www.eskimo.com/~scs/C-faq/top.html>, explains this better than I can. > Meanwhile, in Ada, A (0) and A (2) are legal, but A.all, 2 (A), and (A + > 2).all give compiler errors. Which means that Ada arrays are closer to being first-class types than C arrays are. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-19 0:00 ` Jeff Carter 2000-01-19 0:00 ` Keith Thompson @ 2000-01-19 0:00 ` David Starner 1 sibling, 0 replies; 55+ messages in thread From: David Starner @ 2000-01-19 0:00 UTC (permalink / raw) On Wed, 19 Jan 2000 18:48:11 GMT, Jeff Carter <jrcarter010@earthlink.net> wrote: >Keith Thompson wrote: >> That's a slight exaggeration. C does have array types and array >> objects. For example this: >> int a[10]; >> declares a as an array of 10 ints, very much like Ada's >> A: array(0 .. 9) of Integer; >> It does not, contrary to popular misconception, declare a as a >> pointer. > >That would explain why a[0] and *a are different notations for the same >thing, and a[2], *(a+2), and 2[a] are also different notations for the >same thing. "int a[2];" is not the same as "int *(a+2);" which is not a legal declaration. "extern int *a;" does not work if a is defined as "int a[2];". Just because the same notation can be used in some circumstaces, and implicit conversion happens, doesn't mean they are the same thing. -- David Starner - dstarner98@aasaa.ofe.org If you wish to strive for peace of soul then believe; if you wish to be a devotee of truth, then inquire. -- Friedrich Nietzsche ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Keith Thompson 2000-01-19 0:00 ` Jeff Carter @ 2000-01-19 0:00 ` Ole-Hjalmar Kristensen 2000-01-19 0:00 ` Gisle S�lensminde 2 siblings, 0 replies; 55+ messages in thread From: Ole-Hjalmar Kristensen @ 2000-01-19 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > Jeff Carter <jrcarter010@earthlink.net> writes: > [...] > > > With true arrays, do you mean out of bound checking, etc? This can be done > > > with _proper_ programming in C! > > > > C does not have arrays; it only has different notations for address > > arithmetic. > > That's a slight exaggeration. C does have array types and array > objects. For example this: > int a[10]; > declares a as an array of 10 ints, very much like Ada's > A: array(0 .. 9) of Integer; > It does not, contrary to popular misconception, declare a as a > pointer. > > What often causes confusion is that, in most expression contexts, a > reference to the name of an array object "decays" to a pointer to the > array's first element. > > C arrays are not first-class types, but they do exist. > > -- > Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> > San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> > Welcome to the last year of the 20th century. I would say you are both right. C guarantees that in your example, a is a constant pointer. I also guarantees that a[i] == *(a+i). A somewhat curious fact is that i[a] == *(i+a) == *(a+i), so it is completely legal C to write for instance : 9[a] = 13; The only use of this is probably if you're competing in the obfuscated C code contest :-) Ole-Hj. Kristensen -- E pluribus Unix ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-18 0:00 ` Keith Thompson 2000-01-19 0:00 ` Jeff Carter 2000-01-19 0:00 ` Ole-Hjalmar Kristensen @ 2000-01-19 0:00 ` Gisle S�lensminde 2 siblings, 0 replies; 55+ messages in thread From: Gisle S�lensminde @ 2000-01-19 0:00 UTC (permalink / raw) In article <yecya9mpsv8.fsf@king.cts.com>, Keith Thompson wrote: >Jeff Carter <jrcarter010@earthlink.net> writes: >[...] >> > With true arrays, do you mean out of bound checking, etc? This can be done >> > with _proper_ programming in C! >> >> C does not have arrays; it only has different notations for address >> arithmetic. > >That's a slight exaggeration. C does have array types and array >objects. For example this: > int a[10]; >declares a as an array of 10 ints, very much like Ada's > A: array(0 .. 9) of Integer; >It does not, contrary to popular misconception, declare a as a >pointer. > >What often causes confusion is that, in most expression contexts, a >reference to the name of an array object "decays" to a pointer to the >array's first element. > >C arrays are not first-class types, but they do exist. The semantics of C array is confusing for a lot of people, and they are frequently incorrectly used. C arrays are passed by reference to functions, but not if they are placed inside a struct. I have frequently seen code like this one: (Which not even gives warning on several compilers, like sunpro CC) char* dig2hex(char digest[20]){ int i; char hexstr[40]; /* insert calculation here */ return hexstr; /* returns a pointer to a local - may corrupt data later*/ } This code returns a pointer to a local variable, and since these data is placed on the stack, they will typically be overwritten later. Instead you can place the array inside a struct, like this: typedef struct hexstruct { char hexstr[40]; } hex; hex dig2hex(char digest[20]){ int i; hex tmphex; /* insert calculation here */ return tmphex; /* return the struct including array by copy - ok*/ } As long as the array is placed inside a struct you get by copy semantics, while an array on it's own behaves like a different notation for a pointer. A strange behavior here, is that the struct must be typedefed. Otherwise it won't compile. -- Gisle S�lensminde ( gisle@ii.uib.no ) ln -s /dev/null ~/.netscape/cookies ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke ` (2 preceding siblings ...) 2000-01-18 0:00 ` Jeff Carter @ 2000-01-18 0:00 ` Pascal Obry 2000-01-21 0:00 ` Ada vs. C/C++ (was re: bitwise something-or-other) Mark Lundquist 4 siblings, 0 replies; 55+ messages in thread From: Pascal Obry @ 2000-01-18 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1210 bytes --] Alexander Van Hecke <alexke@hotmail.com> a �crit dans le message : 38836CF2.AB738B8B@hotmail.com... > > Would you agree that C++ is just as good in that as Ada. No. > Don't forget that > ANY C++ code can be easily translated into C? Please, do not forget that every programming language can be easily translated into machine code ! That is what is done by a compiler :) Ok, and what can we conclude from there ? Pascal. -- --|------------------------------------------------------------ --| Pascal Obry Team-Ada Member | --| | --| EDF-DER-IPN-SID- T T I | --| Intranet: http://cln46gb | --| Bureau N-023 e-mail: pascal.obry@edf.fr | --| 1 Av G�n�ral de Gaulle voice : +33-1-47.65.50.91 | --| 92141 Clamart CEDEX fax : +33-1-47.65.50.07 | --| FRANCE | --|------------------------------------------------------------ --| --| http://ourworld.compuserve.com/homepages/pascal_obry --| --| "The best way to travel is by means of imagination" ^ permalink raw reply [flat|nested] 55+ messages in thread
* Ada vs. C/C++ (was re: bitwise something-or-other) 2000-01-17 0:00 ` Alexander Van Hecke ` (3 preceding siblings ...) 2000-01-18 0:00 ` Pascal Obry @ 2000-01-21 0:00 ` Mark Lundquist 2000-01-21 0:00 ` Mark Lundquist 2000-01-24 0:00 ` Hyman Rosen 4 siblings, 2 replies; 55+ messages in thread From: Mark Lundquist @ 2000-01-21 0:00 UTC (permalink / raw) To: Alexander Van Hecke Alexander Van Hecke wrote: >> Ada makes creating and using abstractions easier than C (packages for >> encapsulation and information hiding; private types for information >> hiding). > > Would you agree that C++ is just as good in that as Ada. Well, I wouldn't agree! I find C++ a lot more awkward and primitive. > Don't forget that > ANY C++ code can be easily translated into C? I'm not sure what you mean. If you mean that a translation program can do it, so "it's as easy as invoking the translator", then your observation is true, but irrelevant. Right? (Just think -- a compiler transforms an HLL into machine code, just as cfront transforms C++ into C. What would you think if someone claimed this fact in support of an argument that coding an equivalent program in machine code is no harder than writing the high-level language program?) If, on the other hand, you mean that given any C++ construct (e.g. a class), it's just as easy to program the C equivalent, then I doubt you can really be serious! Have you ever actually looked at the C text produced by cfront? Can you really say you'd just as soon write that yourself? For instance, C++ has its VPTR/VTABLE crap, which hides your C callback stuff. Don't you think there's some benefit in not having to code that yourself? The point isn't that you *can't* do that in principle... no one is claiming that! The point is, who'd want to? C++, despite its flaws, was invented for a reason. And as much as I'd rather use Ada than C++, I'd still rather use C++ than C. This is the whole purpose of higher-level languages, to take programs that are in principle writable by someone with unlimited patience, unlimited time, and perfect memory and record-keeping, and make them actually writeable by real people! The C level of abstraction is OK for little things, but it doesn't scale up. You can write big things in C -- with a lot of effort and pain. C++ actually does give the programmer a higher view of programming than C, in certain areas. It's all about the level of abstraction you get to work in. > For that matter, everything else you mentioned (namespace control, (easy) > generics, exceptions and exception handlers, typing) is easily achieved in > C++ (and thus C). Your line of reasoning seems to be: 1) Ada and C++ are equivalent 2) C++ and C are equivalent, because you can translate C++ to C 3) Therefore, Ada and C are equivalent! ("Ada feature X is 'easily achieved' in C") You seemed to take it for granted that anyone should concede (1), but those who really know both Ada and C++ will be able to tell you all the ways in which that is so wrong! Ada is not C++ with better syntax. As for (2), as I discussed above, the argument from translatability is specious. The translation in question is not transliteration, it's expressing higher-level abstractions in terms of lower-level ones. When you move up and down the "abstraction level continuum", you don't get to use the "translatability" argument, because you're trying to apply it with regard to expressive power when it's only relevant to operational equivalence, which is already assumed... Am I makin' sense here? > As I have said already a few times, and as I said in my original post : I > THINK IT'S A NICE FEATURE OF ADA THAT YOU CAN WRITE READABLE CODE, BUT > THAT > DOES NOT NECESSARILY MEAN THAT THE LANGUAGE IS MORE POWERFUL! Once again, nobody is saying that there are programs that you can write in Ada that you can't write in some other language. If this is what you're arguing against, it's a straw-man argument. The whole Turing-equivalence thing is kind of something that Everybody Knows -- I think you can safely assume that when someone claims that Ada is "more powerful" in some way, this is not what they mean! Yet that appears to be, from your "translation" argument, just what you are arguing against... The 'readability' thing always sounds like a superficial, syntax-level kind of concern ("You say, 'tomato', I say..."). And certainly there's an aspect of that, from the relatively inconsequential, like curly braces vs. "begin...end", to stuff that makes more of a difference. While human-engineering at the syntax level is important, I don't think anyone is going to say that getting it right results in huge gains in productivity/reliability/whatever. But the differences between Ada and C/C++ run much deeper than this. When an Ada advocate says things like "Ada is designed to be readable", they are using the term "readable" in a way that doesn't really do justice to the concept. What they actually mean is that the source text lends itself to a level of deep understanding of the programmer's intent. For instance, the "contract model" can result in a lot more information for the programmer who is reading the declaration of a generic entity, when compared to a C++ template declaration -- in the template "equivalent", the information would have to be given in comments (and in that case, the compiler can't guarantee its veracity), but is more likely going to be ignored by the writer of the template. In the C++ world, it's going to an extreme to document that sort of thing. For the "client" programmer to find out the hard way when they try to compile an instantiation of the template, is just considered business as usual. That's just one example, but the theme of making it easy for the programmer to express design intent, not just operation, runs all the way through the design of the language. > It might > be > easier to use once you've mastered it, but it also is harder to learn. OK, a couple of points... 1) I assume we're talking about C here, not C++. I think C++ is a lot harder to learn than Ada, because while it's roughly the same in "size", it has a lot of deep concepts (like "const correctness", linkage, etc.) that are not only arcane, but are hightly cross-coupled, so that you kind of have to understand all of it and keep your brain wrapped around it all in order to really get any of it right. For this reason, I don't think knowing C gives one any real advantage when it comes to learning C++ vs. learning Ada. Instead, what it gives you is a false sense that "I'm already halfway there", which gives you the hope you need to keep trying to learn the screwy language! You're not really halfway there, but it helps to think you are... :-) 2) While Ada is larger than C, you don't have to learn the whole language in order to start using it., e.g. if you don't need tasking, you don't have to learn Ada tasking, etc. 3) Since C is smaller, it's easier to master all the basic elements of the language... but then so what? What has it gotten you? Now, in addition, you also have to learn or invent ad hoc techniques, as in your example of structs with callbacks. And not only do you have to master the technique intellectually, you then have to apply it correctly, and if you don't get it right, the compiler can't tell you, because it has no clue what you are up to. You're going to have to debug it. Debugging can be fun, but we usually have little control over the circumstances that make it fun or un-fun. And after you raise the level of language abstraction so that you're detecting more bugs at compile-time, there will still be plenty of honest run-time bugs left to go around, so you won't miss the ones you don't have to debug anymore! :-) > > Ada has > > packages, > > C was ment to be used modular and for reuse : put your code in separate .c > and .h files. > > > private types, > > C has that! > > > exceptions, > > you can program exceptions in C. I never said that C has all these things, > but you can program them, and there are masses of libraries available that > have just what you need. > > > generics, > > use structs and callback functions and you have perfect generic types! > > > tasks, > > threads > > true enumeration types, true arrays, > enumeration types in Ada are no different than they are in C. Just because > you have some fancy attributes (SUCC, PRED) doesn't mean that they are > different or more powerful! You can write functions that do exactly the > same, even more, these functions have already been written numerous times > and are available. > With true arrays, do you mean out of bound checking, etc? This can be done > with _proper_ programming in C! So, we have: In Ada In C ----- --- packages "header file / implementation file" convention private types ??? exceptions "you can program it", setjmp()/longjmp(), whatever generics structs & callbacks tasks threads Yet, the Ada advocate claimed advantages for Ada because it has the things in the first column. What could be the explanation for this? I see three possibilities: 1) The Ada advocate is not aware of the things in the second column. E.g., he doesn't know that you can declare things in a shared header file, and then supply the definitions of those things in a ".c" file. 2) The things in column 2 are equivalent to the things in column 1, or they are just as good or better, e.g. threads give you everything that Ada tasks do, and just as well, but the Ada advocate does not understand this. For some reason, he persists in his belief that the Ada version is better. He just doesn't get it. 3) The things in column 1 really are better than the things in column 2. I think (1) can be safely dismissed. You can probably assume, for example, that Ada people know about #include. Don't forget, a lot of Ada advocates are C++ experts. Believe me, those people understand #include. Deeply. In all its glory. Same with the example of tasking. I don't think that when people cite tasking as an advantage of Ada, they mean nothing more than "you can do concurrent programming in Ada". So it's gotta be either (2) or (3). Let me take on the package thing, just as an example. Let's say I have some C-style module, with the interface in "foo.h" and the implementation in "foo.c". OK, superficially, I have something analogous to an Ada package spec and body. But the thing is, "analogous" is as far as it goes. In important ways, they are not "equivalent"... For instance... it's legal for foo.c to be incomplete. It can even be empty. How does foo.c "know" that it's supposed to be the "implementation" of foo.h? It doesn't. It can't. Only the programmer knows. C++ fixes this a little bit, and in a not-very-satisfactory way, with its scopes (classes and namespaces). But then, if you are using C++ and you have a function declaration in a .h file that is at the global scope, then there's another problem, which is that thanks to overloading you can get the definition wrong (doesn't match the prototype) and it's quite legal. As far as C++ is concerned, you didn't get it "wrong" (because only you know what "right" is...), all you did was supply an additional, legal overloading at file scope within the '.c' file. For all these problems, you get to find out about it when you link the program -- but only if there is an actual unresolved reference (think about the implications of that for component development). This is an irritation for small, self-contained, one-person projects, but for large projects with multiple teams, a product integration cycle, etc., it's more than an irritation. In C, everything is made to depend upon the linker. This, along with textual inclusion (independent compilation), is kind of the sine qua non of C/C++. At the linker level, which is primary in the C conception of modularity, the fundamental unit is not the module, but the symbol. The information loss between what the compiler knows and what the linker can know is considerable. (In combination with C++'s template design, this results in some truly inscrutable link-time error messages!) In Ada, the package spec is like a contract that the body has to fulfill, and if it doesn't, it won't compile. How does the body of Foo know that it has anything to do with the spec of Foo? Simple, it says so right there: "package body Foo is..." That's not all... When you put stuff in a .h file, you are making it available for other things to #include. And when they do that, they are dumping the stuff in your .h file into their global scope, which is flat. There's no way to say "The Initialize() from foo.h" vs. "the Initialize() from bar.h" -- in fact, you can't have both and include both. The second one #included will result in a redeclaration error. So everyone has to use ad hoc naming conventions, like "FooInitialize()". So what's wrong with that, besides being hokey? Well, does your concept of a "module" really line up with the reality of a global scope that gets extended when you #include the next thing? Isn't the point of modularity supposed to have something to do with encapsulation? What place does "defensive naming" have in any theory of modules? Now, a C++ class defines a scope, so it gives you some namespace control. But a class is also a data type, so using one where all you want is namespace control is awkward. What was needed was a pure namespace that does not define a data type. This is why the C++ 'namespace' construct was invented. But C++ namespaces are not that great. For one thing, they are textually disjoint. Each file that declares namespace "foo" extends that namespace. Namespaces partition the global namespace, but that's it. They are not like Ada packages. There is no concept of separating interface and implementation, yet enforcing the relationship at compile-time. So while namespaces provide one of the elements of a true module, they are not modules! Also, neither namespaces nor the .h/.c convention give you vsibility control (as in Ada's private declarations). Only classes give you something like this. So C++ has three different mechanisms (header files, classes, and namespaces) that overlap each other to some degree, and none of which gives you what you should expect from a "module". They only approximate it in different ways. Not only that, but each #include of foo.h is subject to whatever #defines are in effect at the point of the inclusion, which are not necessarily the same at all the places where foo.h is #included. Well, that's about all I have for now... Respectfully, Mark Lundquist ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Ada vs. C/C++ (was re: bitwise something-or-other) 2000-01-21 0:00 ` Ada vs. C/C++ (was re: bitwise something-or-other) Mark Lundquist @ 2000-01-21 0:00 ` Mark Lundquist 2000-01-24 0:00 ` Hyman Rosen 1 sibling, 0 replies; 55+ messages in thread From: Mark Lundquist @ 2000-01-21 0:00 UTC (permalink / raw) To: alexke Once again, I am the first (maybe only) person to follow up on my _own_ posting... how pathetic, how typical... :-) But some editorial corrections are in order... Mark Lundquist (c'est moi) wrote: > ... > 1) I assume we're talking about C here, not C++. I think C++ is a lot harder > to learn than Ada, because while it's roughly the same in "size", it has a > lot of deep concepts (like "const correctness", linkage, etc.) that are not > only arcane, but are hightly cross-coupled, so that you kind of have to > understand all of it and keep your brain wrapped around it all in order to > really get any of it right. The following should have been in parentheses, because... well, it's parenthetical! It reads as if I thought Alex were arguing a particular point (viz. C knowledge making it easier to learn C++) and I'm arguing back against it. But he wasn't arguing that, so don't get me wrong. Some people have argued this (in fact it's one of the "core values" of C++), but like I said... in this context, it's parenthetical. > For this reason, I don't think knowing C gives > one any real advantage when it comes to learning C++ vs. learning Ada. > Instead, what it gives you is a false sense that "I'm already halfway there", > which gives you the hope you need to keep trying to learn the screwy > language! You're not really halfway there, but it helps to think you > are... :-) OK, next... > So, we have: > > In Ada In C > ----- --- > > packages "header file / implementation file" > convention > > private types ??? > > exceptions "you can program it", > setjmp()/longjmp(), whatever > > generics structs & callbacks > > tasks threads My little table was obligingly reformatted by Netscape :-( so it came out all screwy.Row 1 column 1 should read "packages", and row 1 column 2 should read "'header file / implementation file' convention". Row 3, column 2 should read "'you can program it', setjmp()/longjmp(), whatever". (Note, the row and column numbers start at 1... :-) sorry, very bad joke...) -- Mark ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Ada vs. C/C++ (was re: bitwise something-or-other) 2000-01-21 0:00 ` Ada vs. C/C++ (was re: bitwise something-or-other) Mark Lundquist 2000-01-21 0:00 ` Mark Lundquist @ 2000-01-24 0:00 ` Hyman Rosen 1 sibling, 0 replies; 55+ messages in thread From: Hyman Rosen @ 2000-01-24 0:00 UTC (permalink / raw) Mark Lundquist <mark@rational.com> writes: > For instance, C++ has its VPTR/VTABLE crap You probably know this, but just for the record, the vptr/vtable technique is part of an implementation to handle virtual method dispatching, and is not defined within C++ itself. Ada dispatching is done in exactly the same way. Indeed, I believe GNAT makes Ada tagged records compatible with corresponding C++ classes so that pointers to such objects may be exchanged between the two languages. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke ` (5 preceding siblings ...) 2000-01-17 0:00 ` Jeff Carter @ 2000-01-18 0:00 ` Ted Dennison 2000-01-18 0:00 ` DuckE 7 siblings, 0 replies; 55+ messages in thread From: Ted Dennison @ 2000-01-18 0:00 UTC (permalink / raw) In article <3882FC1C.2BA8C959@hotmail.com>, Alexander Van Hecke <alexke@hotmail.com> wrote: > In C you'd have one while loop, and you'd put your condition in the > while expression and that's it. Nothing more to learn about it! I'm a bit confused at this. Ada has a while loop construct too eg: while x < y loop end loop; This is one of the situations where the two languages are essentially similar. The main difference is that Ada doesn't require parens around the conditional. An improvement as far as ease of learning goes, I'd say. I could go on a while about C vs. Ada loops. I like C's do..while loops. Its kind of a shame Ada doesn't have that. But Ada essentially has an "anywhere-tested" loop with the construct: loop ... exit when x=y; ... end loop; You can of course simulate that in C with break, but that's really more like doing a "if ... exit; endif;" in Ada, so I don't consider it the same. And the for (;;) you use to make the infinite loop looks goofy. It really comes off looking like a hack, where in Ada its quite natural. C's continue statement would be helpful often in my Ada code, but it does make the code tougher to follow. The power of C's for statement is kind of neat. But I think this may be a situation where power corrupts. I'm always too tempted to put the entire contents of the loop in the for conditional (in the middle term, separated by commas). Proper use of Ada's "for" statement is without question easier for a beginner to pick up. While I'm on that subject, I think the question mark operator is another C feature I love a little too much which was wisely left out of Ada. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-17 0:00 ` Alexander Van Hecke ` (6 preceding siblings ...) 2000-01-18 0:00 ` bitwise comparators Ted Dennison @ 2000-01-18 0:00 ` DuckE 7 siblings, 0 replies; 55+ messages in thread From: DuckE @ 2000-01-18 0:00 UTC (permalink / raw) Alexander Van Hecke <alexke@hotmail.com> wrote in message news:3882FC1C.2BA8C959@hotmail.com... > > I'd also like to point out that the "while" construct you are using is > > common for 'C' or Pascal, but in Ada you could use a "loop" construct with > > "exit when" > > > > thank you all for your response! > As many of you have pointed out, I could have used exit when ... > But as you probably noticed, I have a C background and I'm not that familiar > with Ada. I think it's a nice feature of Ada that you can write 'readable' > code, but IMHO Ada takes a lot longer to learn, there are more constructs, > keywords, etc... In a word, the language is more complicated, yet not > necessarily more powerfull (hope I don't get flamed for this :-)). In C you'd > have one while loop, and you'd put your condition in the while expression and > that's it. Nothing more to learn about it! > What's your opinion on this? > > alex > I've done projects in both C and Ada, and when given a choice on a new project I choose Ada. Yes it takes a while to learn all of the nuances of Ada, but the same is true of C. There are numerous bugs I have run across in C programs that have been a bear to track down, that are very visible in Ada. Here's a few examples: for( i = 0 ; i < 10 ; i++ ); { printf( "Value of i is %d\n", i ); } Gives the output: Value of i is 0 To "spot the bug" here's the equivalent Ada code: for i in 0 .. 9 loop end loop begin ada.text_io.put( "Value of i is " ); ada.integer_text_io.put( i ); ada.text_io.new_line; end; An experienced C programmer might see that extra semicolon instantly when looking at the source code, but when digging for a needle in a haystack in a large body of existing code, I personally can do without this kind of trap. There are several other examples of simple C coding errors that can trip you up, but you probably get my point. SteveD ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-15 0:00 bitwise comparators Alexander Van Hecke ` (2 preceding siblings ...) 2000-01-16 0:00 ` DuckE @ 2000-01-16 0:00 ` Jeff Carter 2000-01-16 0:00 ` Bryce Bardin 4 siblings, 0 replies; 55+ messages in thread From: Jeff Carter @ 2000-01-16 0:00 UTC (permalink / raw) In article <3880D375.7E363123@hotmail.com>, Alexander Van Hecke <alexke@hotmail.com> wrote: > hello, > > I want to do the following : > OK_to_proceed : BOOLEAN := FALSE; > data : Unsigned_8; > > while (not OK_to_proceed) loop > -- do stuff > OK_to_proceed := (data BITWISE AND 2#1#); > end loop; > > so I want to exit the loop if bit one of data is set, but I don't know > what the bitwise and is! If Unsigned_8 is a modular type, such as Interfaces.Unsigned_8, then the operator "and" performs a bitwise and between values of the type: Data and 1 The result of this is of type Unsigned_8. You have a number of options to convert this to Boolean: OK_To_Proceed := Boolean'Val (Data and 1); is probably the best. Others include comparing the result to 1 (OK) and using an unchecked conversion (not recommended). I think that loop exit when OK_To_Proceed; is easer to read and understand than the negative logic used with a while loop. -- Jeff Carter "Now go away or I shall taunt you a second time." -- Monty Python and the Holy Grail Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: bitwise comparators 2000-01-15 0:00 bitwise comparators Alexander Van Hecke ` (3 preceding siblings ...) 2000-01-16 0:00 ` Jeff Carter @ 2000-01-16 0:00 ` Bryce Bardin 4 siblings, 0 replies; 55+ messages in thread From: Bryce Bardin @ 2000-01-16 0:00 UTC (permalink / raw) Alexander Van Hecke wrote: > > hello, > > I want to do the following : > OK_to_proceed : BOOLEAN := FALSE; > data : Unsigned_8; > > while (not OK_to_proceed) loop > -- do stuff > OK_to_proceed := (data BITWISE AND 2#1#); > end loop; > > so I want to exit the loop if bit one of data is set, but I don't know > what the bitwise and is! > > alex Data : Interfaces.Unsigned_8; Bit_0 : constant := 2**0; -- Clearer intent than 2#1# or 1 -- This might be given an application-specific name and -- (optionally) be given an explicit type, e.g.: Command_Accepted : constant Interfaces.Unsigned_8 := 2**0; -- Evaluated at compilation time. loop -- Do something that changes the value of Data. exit when (Data and Command_Accepted) = Command_Accepted; end loop; ^ permalink raw reply [flat|nested] 55+ messages in thread
end of thread, other threads:[~2000-02-09 0:00 UTC | newest] Thread overview: 55+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-01-15 0:00 bitwise comparators Alexander Van Hecke 2000-01-15 0:00 ` David C. Hoos, Sr. 2000-01-16 0:00 ` Matthew Heaney 2000-01-16 0:00 ` DuckE 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David C. Hoos, Sr. 2000-01-17 0:00 ` tmoran 2000-01-17 0:00 ` Mike Silva 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` Gautier 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Mike Silva 2000-01-18 0:00 ` Charles Hixson 2000-01-17 0:00 ` Brian Rogoff 2000-02-05 0:00 ` Ashley Deas Eachus 2000-02-05 0:00 ` Jeff Carter 2000-02-06 0:00 ` Andy 2000-02-07 0:00 ` Brian Rogoff 2000-02-09 0:00 ` Robert Iredell Eachus 2000-01-17 0:00 ` Gautier 2000-01-18 0:00 ` Keith Thompson 2000-01-19 0:00 ` Ole-Hjalmar Kristensen 2000-01-17 0:00 ` Matthew Heaney 2000-01-17 0:00 ` Jeff Carter 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner 2000-01-18 0:00 ` Preben Randhol 2000-01-18 0:00 ` Fraser 2000-01-18 0:00 ` Bertrand Augereau 2000-01-19 0:00 ` Ted Dennison 2000-01-19 0:00 ` Marin D. Condic 2000-01-19 0:00 ` Ted Dennison 2000-01-18 0:00 ` Ted Dennison 2000-01-17 0:00 ` Gautier 2000-01-17 0:00 ` Alexander Van Hecke 2000-01-17 0:00 ` David Starner 2000-01-18 0:00 ` Gautier 2000-01-18 0:00 ` Ted Dennison 2000-01-18 0:00 ` Jeff Carter 2000-01-18 0:00 ` Keith Thompson 2000-01-19 0:00 ` Jeff Carter 2000-01-19 0:00 ` Keith Thompson 2000-01-19 0:00 ` David Starner 2000-01-19 0:00 ` Ole-Hjalmar Kristensen 2000-01-19 0:00 ` Gisle S�lensminde 2000-01-18 0:00 ` Pascal Obry 2000-01-21 0:00 ` Ada vs. C/C++ (was re: bitwise something-or-other) Mark Lundquist 2000-01-21 0:00 ` Mark Lundquist 2000-01-24 0:00 ` Hyman Rosen 2000-01-18 0:00 ` bitwise comparators Ted Dennison 2000-01-18 0:00 ` DuckE 2000-01-16 0:00 ` Jeff Carter 2000-01-16 0:00 ` Bryce Bardin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox