* Look what I caught! was re:Ada paper critic @ 2002-06-17 17:35 Alderson, Paul A. 2002-06-17 18:31 ` Darren New ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Alderson, Paul A. @ 2002-06-17 17:35 UTC (permalink / raw) Here's what I caught on my troll: 1.) People who missed the point (maybe intentionally) of the big chain of package names you end up with in some Ada packages. The point here is if your company has a policy against using "uses" in their code, then you have to: A.) Use a renames B.) Use the fully specified name. C.) Ignore the standard and use use. Now if you use a rename, then you introduce more work for the code reviewer (remember code is written once and looked at many times). Yes it is a small diversion, which only extends the search a few seconds further. If you use the fully specified name the reviewer can immediately start searching the Ada code for that package (not file). Now why did the company forbid "use"? Probably because it leads to possible errors and isn't being precise...which is why they chose Ada. For those who couldn't get past the case, change the case to your liking and continue. 2.) People assumed I was the one that had the problems with using global variables (even though the globals referred to were actually package variables) and etc. If one lives in the Ada industry long enough you will find that much of the embedded code written with Ada uses package variables extensively. Why? Mostly because pushing and popping things on and off stacks is time consuming. Secondly ...wait I'll make this point #3... 3.) Many people in this group seem to have a "write the code and never look at it again" attitude. Writing code is only one small aspect of the software development life cycle. When you start looking at verification on Level-A systems the use of certain software structures becomes iffy. For example if you don't use ANY global variables (You know because global variables are bad!) Then one must insure that the stack will not collide with heap or code space. If you take some time to think about this, you'll not be so quick to say globals are bad! This brings up my discussion on why not being able to tell an array from a function is a problem. From the writing of the code its nice to be able to change your mind on the implementation of a function to array. But then again why are you changing something like this? This is an indication that proper design was not followed. And again the code will be viewed many more times than written (hopefully anyway). So when reviewing and testing this code one will see that: x := a.y(z); -- Purposefully descriptive names. And we know z's range and if we knew it was an array we could easily set values within "a.y". Unfortunately we can't tell this with this language and have to again perform the ole search of the code to find out what a.y is. Needlessly.... Yes its only a few seconds.... I concede that replacing a function with and array would be nice on the development end. Unfortunately when you do this and the verification occurs (level - A) now all those tests magically break and strangely enough the code didn't change! Now what would have been a simple search and replace by the developer is now a big search and destroy mission by the verification team. 4.) Some missed the point I was making about how Ada was not designed to be purely a high level language. The point that Ada uses integers is that an integer (no matter what the size) is a hardware notion. The language does allow for pure ranges, but yet keeps its feet firmly tied to the hardware. Again how many instances do you really need the full range of an int? Rarely...so why did the type ever exist? My guess is because at the time of its design it was too far reaching to simply declare ranges and making the compiler figure out the appropriate size. The point here is that Ada is still tied to the hardware. The pre-emptive counter point here was knowing people would say they didn't have to use integers but are just an option. Which is why I said people didn't need to use pointers in C either, yet it is scrutinized for its pointer problem (Rightfully so). 5.) Yet another argument was that the language can help keep bad programmers from doing bad things. I must agree 100% on this and simply say that Ada doesn't do nearly enough to do this. Yes...other languages are even worse. The danger here is that MANY people believe Ada is really good at preventing bad things from happening. It prevents some of them, but really if redesigned could be leaps and bounds better. (Yes I'm criticizing Ada in a vacuum...I don't care how evil other languages are...I want it right dammit!) 6.) Because I criticize the language people immediately think that I'm saying another language is "better" than Ada. The original poster simply asked for the bad things about Ada. I posted them... and yes while no other language offers as much, we have a long way to go. 7.) Ada isn't taught anymore people...Its a general statement. Your suppose to get the idea behind it. For those who are 100% literal. Ada is no longer being taught at as many institutes of learning as it had been. In fact very few places continue to teach it. If trends continue as they are, Ada will be completely phased out from public learning institutions in the near future. Latin is a dead language, yet it is taught. Is it really "taught" however? 8.) People seem to miss the point that no matter how great the language is, if it has crappy compilers, crappy debugging and a crappy IDE's then its going to be a interesting blip on the software radar screen that fades out fast. The language itself can help with easy development of these tools. Was it Ada's fault for the lack of these tools or other issues? No idea... 9.) Gimpel Lint - Very good piece of software for C programmers. Style, pointer checks, type checks.... Can't do run-time checks - which if your language is designed right from the start you don't need.... (No main stream language exists YET that will allow static analysis, thus eliminating run time checks.) 10.) Just because I like having lists of ten! 8) And you thought you were SOOOOO RIGHT. Turns out you were only MOSTLY RIGHT! SO THERE! 8) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 17:35 Look what I caught! was re:Ada paper critic Alderson, Paul A. @ 2002-06-17 18:31 ` Darren New 2002-06-17 21:40 ` Vinzent Hoefler 2002-06-19 13:52 ` Ted Dennison 2 siblings, 0 replies; 20+ messages in thread From: Darren New @ 2002-06-17 18:31 UTC (permalink / raw) "Alderson, Paul A." wrote: > (No main stream language exists YET that will allow > static analysis, thus eliminating run time checks.) Nor is it ever likely to, methinks. Certainly not a general purpose language, and very certainly not a language capable of real-time work. See, there's this thing called "the halting problem".... -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 17:35 Look what I caught! was re:Ada paper critic Alderson, Paul A. 2002-06-17 18:31 ` Darren New @ 2002-06-17 21:40 ` Vinzent Hoefler 2002-06-17 23:14 ` Darren New ` (2 more replies) 2002-06-19 13:52 ` Ted Dennison 2 siblings, 3 replies; 20+ messages in thread From: Vinzent Hoefler @ 2002-06-17 21:40 UTC (permalink / raw) "Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote: >Here's what I caught on my troll: :-) >1.) People who missed the point (maybe intentionally) of the big > chain of package names you end up with in some Ada packages. > >The point here is if your company has a policy against using >"uses" in their code, then you have to: > > A.) Use a renames > B.) Use the fully specified name. Like in SPARK. > C.) Ignore the standard and use use. And get "use"d to be fired. ;) >Now if you use a rename, then you introduce more work for the >code reviewer (remember code is written once and looked at many >times). Yes it is a small diversion, which only extends the >search a few seconds further. Still, it would depend on *how* you do it. >2.) People assumed I was the one that had the problems with using > global variables (even though the globals referred to were > actually package variables) and etc. > >If one lives in the Ada industry long enough you will find that >much of the embedded code written with Ada uses package variables >extensively. Why? Mostly because pushing and popping things >on and off stacks is time consuming. That thing hasn't anything to do with Ada. If you are forced to use global variables because of efficiency requirements, you'll be forced to use them in *any* language. >3.) Many people in this group seem to have a "write the code > and never look at it again" attitude. I got another impression from most Ada program(mer)s I've seen. My personal experience shows me that the *hurry, hurry fast, if it works, I'll never look at it again* approach is more wide-spread in other languages. > Writing code is only > one small aspect of the software development life cycle. About 10%, if not even less, I'd say. > This brings up my discussion on why not being able to tell > an array from a function is a problem. From the writing > of the code its nice to be able to change your mind on > the implementation of a function to array. But then again > why are you changing something like this? This is an > indication that proper design was not followed. No. A design you have can be implemented in at least 10 different ways. The design says very little about its implementation. > x := a.y(z); -- Purposefully descriptive names. > And we know z's range and if we knew it was an array > we could easily set values within "a.y". Unfortunately > we can't tell this with this language and have to > again perform the ole search of the code to find out what > a.y is. Well, hmm. Surely I miss something, but how can "y" be a function here? > Needlessly.... Yes its only a few seconds.... Well, considering how many of those few seconds I already hang around with C++ code to see how this or that function is declared and if it changes something, this sounds funny. In C++ I can even overload the [] operator, this changes the whole world. > I concede that replacing a function with and array would be > nice on the development end. Unfortunately when you do this > and the verification occurs (level - A) now all those tests > magically break and strangely enough the code didn't change! Well, try to place a simple "virtual" in C++ code at appropriate declarations of a class and strangely see, that although the code has not changed at all, it completely f***s up. In Ada the semantic does not change, if you switch the declaration from an array to a function or vice versa unless you do very nasty things. > Now what would have been a simple search and replace by the > developer is now a big search and destroy mission by the > verification team. Well, when does verification occur in the *normal* case? I'd guess at the end of a development phase. And I'd guess, the verification must occur again, if some of the code was changed. >4.) Some missed the point I was making about how Ada was not > designed to be purely a high level language. The point > that Ada uses integers is that an integer (no matter what > the size) is a hardware notion. Not really. Just that 'range is implementation defined. It says "nothing" about the hardware. > The language does allow > for pure ranges, but yet keeps its feet firmly tied to the > hardware. Oh well. What other kind of integers can you imagine? We use programing languages to program computers and computers *are* still hardware. And if I imagine a machine which only knows floating point registers, I'd guess, the meaning of Integer would be the same still although the hardware representation might be totally different. > Again how many instances do you really need > the full range of an int? Rarely...so why did the type > ever exist? For type compatibility reasons, I'd guess. Ada knows *sub*types. So you need a base type at least. Well, you could say, ok, so let the programmer define the base type, but that also means, he has to implement the arithmetic operations on that type. And how to do that if you don't have a type on where those operations are defined? > My guess is because at the time of its design > it was too far reaching to simply declare ranges and > making the compiler figure out the appropriate size. Well, the compiler normally does this. If the standard integer size is 16-bit and you declare a range of 0 .. 100_000 the compiler will probably implement is as a 32-bit value (or maybe 24 bits or so...). In the case of a range of 0 .. 10_000 the compiler will *probably* implement is as the most effective hardware abstraction - in 16 bit. But nothing stops the compiler from implementing it in 14 bits. So it is really not any view on the hardware in the language in that case. The compiler simply assures you that your range will fit in the chosen representation. With "for ... use" you are still able to override this (normally hidden) behaviour if you *have to* rely on a specific implementation. Still this declaration then should work on another machine with another default integer size in the *same* way. So I can't see no really hardware specific thing here. Perhaps one: Ada might rely on the machine to actually have integers at all. So it's certainly the wrong language for quantum probability computers or so... ;-) > The point here is that Ada is still tied to the hardware. That's simply wrong. Yes, the *compiler* normally tries to use the most effective representation on the specific hardware. And no, this hasn't anything to do with Ada being *tied* to hardware. > The pre-emptive counter point here was knowing people > would say they didn't have to use integers but are just > an option. Well, IMO you shouldn't use pure Integers without a good reason. They aren't good for anything other than deriving types *from* it. :-) What's wrong with specifying a range or even a modular type? > Which is why I said people didn't need to > use pointers in C either, yet it is scrutinized for its > pointer problem (Rightfully so). Well, look at the C runtime library and tell me, how many functions you could use without using pointers? Not to mention the nasty "array" thing... >5.) Yet another argument was that the language can help keep > bad programmers from doing bad things. I must agree > 100% on this and simply say that Ada doesn't do nearly > enough to do this. To this one I might agree. Although I'm still sometimes struggling with the compiler what's right. Damn, I *know*, I can assign this type of variable to another one, why is the compiler preventing me from doing this? ;-) So actually it does even prevent me from doing the right things if I don't express them the right way. I like that, no wonder, why this language is called after a woman. ;-) > (Yes I'm criticizing Ada in a vacuum...I don't care how > evil other languages are...I want it right dammit!) That's simple: *Do* it right. This is possible in either language, yes. The good thing with Ada is that the possibility to do it right has a greater probability. :-) >6.) Because I criticize the language people immediately think >that I'm saying another language is "better" than Ada. The original >poster simply asked for the bad things about Ada. I posted them... You can do bad things in Ada, yes. But some of the things you said, can't be prevented in any (procedurale) language. And some were simply wrong. >7.) Ada isn't taught anymore people...Its a general statement. But even with this stated generality: It's wrong. >8.) People seem to miss the point that no matter how great the > language is, if it has crappy compilers, crappy debugging > and a crappy IDE's then its going to be a interesting blip > on the software radar screen that fades out fast. Well, gcc has no IDE at all and I would state that it is one of the most widely used compilers in the world. And if the rumours are right, gcc3.1 does surprisingly include Ada95 (again?). > The > language itself can help with easy development of these > tools. Was it Ada's fault for the lack of these tools or > other issues? No idea... Well, I can't see the lack of tools. Might be there are less tools than for C or Java or $WHATEVER but in the end it simply boils down to using *one* tool. Actually *two*: an editor and a compiler. :-) >9.) Gimpel Lint - Very good piece of software for C programmers. Well, so it seems you need a *post*-processor to verify you did the right thing. And my question: how widely used is *that* one? > Can't do run-time checks - which if your language is > designed right from the start you don't need.... No. Its not a long time ago (was it in c.l.a.?) I read that C arrays are one element more on the right and left side because this becomes handy in using some algorithms that intentionally might get out of bounds. Such a design should make the code easier to write. Well, do you call that *right*? I would not. > (No main stream language exists YET that will allow > static analysis, thus eliminating run time checks.) It might be not possible at all, if you need data from a given environment or user out of the computer's small world. >10.) Just because I like having lists of ten! 8) > >And you thought you were SOOOOO RIGHT. Turns out you were only MOSTLY >RIGHT! SO THERE! 8) Well, I don't *think* I'm right. I *know* I am. 8-) ;-) Vinzent. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 21:40 ` Vinzent Hoefler @ 2002-06-17 23:14 ` Darren New 2002-06-18 14:49 ` Hyman Rosen 2002-06-18 22:36 ` Vinzent Hoefler 2002-06-18 13:28 ` Marin David Condic 2002-06-18 19:16 ` Kevin Cline 2 siblings, 2 replies; 20+ messages in thread From: Darren New @ 2002-06-17 23:14 UTC (permalink / raw) Vinzent Hoefler wrote: > No. Its not a long time ago (was it in c.l.a.?) I read that C arrays > are one element more on the right and left side because this becomes > handy in using some algorithms that intentionally might get out of > bounds. You're probably thinking of what I said, which was that a pointer into an array is allowed to be increased to point off the end of the array by one element, but you can't access it. Not because it might intentionally get out of bounds, but because you do things like while (*s++ == 0) ; meaning that you never *reference* the pointer when it's out of bounds, but you do point out of bounds. You don't necessarily get to point two out of bounds, tho. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 23:14 ` Darren New @ 2002-06-18 14:49 ` Hyman Rosen 2002-06-18 22:36 ` Vinzent Hoefler 1 sibling, 0 replies; 20+ messages in thread From: Hyman Rosen @ 2002-06-18 14:49 UTC (permalink / raw) Darren New wrote: > You're probably thinking of what I said, which was that a pointer into an > array is allowed to be increased to point off the end of the array by one > element, but you can't access it. You don't necessarily get to point two > out of bounds, tho. Right, only one past the end is permitted. As you say, this is used in algorithms which march a pointer through an array and find it convenient to post-increment, as in the traditional copying loop of strcpy: strcpy(char *to, char *from) { while (*to++ = *from++); } In C++, this approach has been adopted by the STL algorithms. Whenever they need to operate on a sequence of elements, that sequence is specified by a half-open range of iterators, [begin, end), which mirrors the pointer approach, and in fact pointers are valid iterators, so that STL algorithms can be used on simple arrays. For example, copy is template<typename T> T copy(T begin, T end, T to) { while (begin != end) *to++ = *begin++; return to; } ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 23:14 ` Darren New 2002-06-18 14:49 ` Hyman Rosen @ 2002-06-18 22:36 ` Vinzent Hoefler 1 sibling, 0 replies; 20+ messages in thread From: Vinzent Hoefler @ 2002-06-18 22:36 UTC (permalink / raw) Darren New <dnew@san.rr.com> wrote: >Vinzent Hoefler wrote: >> No. Its not a long time ago (was it in c.l.a.?) I read that C arrays >> are one element more on the right and left side because this becomes >> handy in using some algorithms that intentionally might get out of >> bounds. > >You're probably thinking of what I said, which was that a pointer into an >array is allowed to be increased to point off the end of the array by one >element, but you can't access it. Ok. Thanks for clarifying that. I was quite confused, because hell a lot of C code (including the little pieces I already did) wouldn't have worked at all then. Vinzent. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 21:40 ` Vinzent Hoefler 2002-06-17 23:14 ` Darren New @ 2002-06-18 13:28 ` Marin David Condic 2002-06-24 19:17 ` Vinzent Hoefler 2002-06-18 19:16 ` Kevin Cline 2 siblings, 1 reply; 20+ messages in thread From: Marin David Condic @ 2002-06-18 13:28 UTC (permalink / raw) Have you ever heard of *anyone* being fired for violating a coding standard? :-) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Vinzent Hoefler" <JeLlyFish.software@gmx.net> wrote in message news:3d0e5750_2@news.bluewin.ch... > > And get "use"d to be fired. ;) > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-18 13:28 ` Marin David Condic @ 2002-06-24 19:17 ` Vinzent Hoefler 0 siblings, 0 replies; 20+ messages in thread From: Vinzent Hoefler @ 2002-06-24 19:17 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote: >Have you ever heard of *anyone* being fired for violating a coding standard? >:-) Mmh. Good point. More it seems, permanently and strictly violating a coding standard tends to become the new coding standard after all... :-D Vin"Yes, I *hate* Hungarian notation. It's braindead."zent. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 21:40 ` Vinzent Hoefler 2002-06-17 23:14 ` Darren New 2002-06-18 13:28 ` Marin David Condic @ 2002-06-18 19:16 ` Kevin Cline 2002-06-18 22:36 ` Vinzent Hoefler 2 siblings, 1 reply; 20+ messages in thread From: Kevin Cline @ 2002-06-18 19:16 UTC (permalink / raw) Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3d0e5750_2@news.bluewin.ch>... > I got another impression from most Ada program(mer)s I've seen. My > personal experience shows me that the *hurry, hurry fast, if it works, > I'll never look at it again* approach is more wide-spread in other > languages. Other languages are used by for-profit companies in competitive markets. Ada tends to be used for long term one-of-a-kind development projects being paid for by governmental agencies. >... > Well, considering how many of those few seconds I already hang around > with C++ code to see how this or that function is declared and if it > changes something, this sounds funny. In C++ I can even overload the > [] operator, this changes the whole world. You can overload the function-call operator too. Both are very useful in the right situation. >... > No. Its not a long time ago (was it in c.l.a.?) I read that C arrays > are one element more on the right and left side because this becomes > handy in using some algorithms that intentionally might get out of > bounds. Such a design should make the code easier to write. Well, do > you call that *right*? I would not. Knowing so little about C and C++ I would think you would be more reluctant to criticize them. A C array does not contain "one element more" on either side. The standard allows setting a pointer to the next element after the end of an array, but such a pointer can not be dereferenced. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-18 19:16 ` Kevin Cline @ 2002-06-18 22:36 ` Vinzent Hoefler 2002-06-19 14:29 ` Wes Groleau 0 siblings, 1 reply; 20+ messages in thread From: Vinzent Hoefler @ 2002-06-18 22:36 UTC (permalink / raw) kcline17@hotmail.com (Kevin Cline) wrote: >Vinzent Hoefler <JeLlyFish.software@gmx.net> wrote in message news:<3d0e5750_2@news.bluewin.ch>... > >> I got another impression from most Ada program(mer)s I've seen. My >> personal experience shows me that the *hurry, hurry fast, if it works, >> I'll never look at it again* approach is more wide-spread in other >> languages. > >Other languages are used by for-profit companies in competitive markets. Well, might be. >Ada tends to be used for long term one-of-a-kind development projects >being paid for by governmental agencies. Well. I have not seen a lot of Ada code from such projects now. I can only refer to the things I have seen and for me Ada looked substantially better even if written by a non-professional than the average C/C++ code from experienced people who should know much better how to write readable code. So *for me* it seems that the Ada-language seems to encourage people of using a more readable style. >> Well, considering how many of those few seconds I already hang around >> with C++ code to see how this or that function is declared and if it >> changes something, this sounds funny. In C++ I can even overload the >> [] operator, this changes the whole world. > >You can overload the function-call operator too. Both are very useful >in the right situation. ACK. So "()" vs. "[]" changes nothing. You will *always* have to take a look at the declaration if you want to know for sure. >> No. Its not a long time ago (was it in c.l.a.?) I read that C arrays >> are one element more on the right and left side because this becomes >> handy in using some algorithms that intentionally might get out of >> bounds. Such a design should make the code easier to write. Well, do >> you call that *right*? I would not. > >Knowing so little about C and C++ I would think you would be >more reluctant to criticize them. *grr* Shall I be able to repeat the C++ language reference out of my mind before qualifying to state about the language? IMO, I have done enough things in C and even C++ that I consider me being able to spot the points that made *my* life harder with that language. I have heard a lot of silly things about Ada from people who didn't even ever seen Ada code and I've seen a lot of silly things in C that turned out to be true. So please let me the right to state things that might not be correct about a language I'm quite used to without ever falling in love with it. The thing is I do substantially better code in C since I've did my first readings about Ada. Especially after reading the Q&S. Is there anything comparable for C++ available for free? I know a lot of people I would give it to... > A C array does not contain >"one element more" on either side. The standard allows setting >a pointer to the next element after the end of an array, but >such a pointer can not be dereferenced. Well. It *can*. With undefined results. These "undefined results" I have come over too often really pissed me off. And hence, it was not *my* code. I just had to *maintain* it. Vin"Ok, I'll get a little drink from my "Buffer Overflow" glass from thinkgeek now. :-)"zent. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-18 22:36 ` Vinzent Hoefler @ 2002-06-19 14:29 ` Wes Groleau 2002-06-19 16:59 ` Darren New ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Wes Groleau @ 2002-06-19 14:29 UTC (permalink / raw) > > A C array does not contain > >"one element more" on either side. The standard allows setting > >a pointer to the next element after the end of an array, but > >such a pointer can not be dereferenced. The standard does? But most compilers ignore this, right? Or is the some other explanation why it's so @#$%@#$% easy to get a segmentation fault in C ? Or did I completely misunderstand the statement? -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 14:29 ` Wes Groleau @ 2002-06-19 16:59 ` Darren New 2002-06-19 17:48 ` Wes Groleau 2002-06-19 17:11 ` Frank J. Lhota 2002-06-19 19:37 ` Robert A Duff 2 siblings, 1 reply; 20+ messages in thread From: Darren New @ 2002-06-19 16:59 UTC (permalink / raw) Wes Groleau wrote: > > > > A C array does not contain > > >"one element more" on either side. The standard allows setting > > >a pointer to the next element after the end of an array, but > > >such a pointer can not be dereferenced. > > The standard does? But most compilers ignore this, right? The pointer can be dereferenced, of course, but it's "undefined behavior". In other words, the programmer shouldn't do this, because the compiler is allowed to enforce that you don't. Of course, most C compilers implement pointers as raw addresses, so it's generally hard to make sure you're doing the Right Thing that way. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 16:59 ` Darren New @ 2002-06-19 17:48 ` Wes Groleau 2002-06-19 17:56 ` Darren New 0 siblings, 1 reply; 20+ messages in thread From: Wes Groleau @ 2002-06-19 17:48 UTC (permalink / raw) > > > >"one element more" on either side. The standard allows setting > > > >a pointer to the next element after the end of an array, but > > > >such a pointer can not be dereferenced. > > > > The standard does? But most compilers ignore this, right? > > The pointer can be dereferenced, of course, but it's "undefined behavior". > Actually, what the C standard says is that if you have a pointer just after > the end of an array, then the result of dereferencing that pointer is > "unpredictable". Such dereferences can cause segmentation fault, trash some That's what I thought. The original claim was in error. The correct statement is "such a pointer should not be dereferenced" -- Wes Groleau http://freepages.rootsweb.com/~wgroleau ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 17:48 ` Wes Groleau @ 2002-06-19 17:56 ` Darren New 0 siblings, 0 replies; 20+ messages in thread From: Darren New @ 2002-06-19 17:56 UTC (permalink / raw) Wes Groleau wrote: > That's what I thought. The original claim was in error. > The correct statement is "such a pointer should not be dereferenced" Well, alternately, "on some compilers, such a pointer will flag a programming error if dereferenced". I've used (for example) C interpreters that carried around more than just raw addresses, for obvious reasons. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://home.san.rr.com/dnew/DNResume.html ** ** http://images.fbrtech.com/dnew/ ** My brain needs a "back" button so I can remember where I left my coffee mug. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 14:29 ` Wes Groleau 2002-06-19 16:59 ` Darren New @ 2002-06-19 17:11 ` Frank J. Lhota 2002-06-19 19:31 ` Robert A Duff 2002-06-19 19:37 ` Robert A Duff 2 siblings, 1 reply; 20+ messages in thread From: Frank J. Lhota @ 2002-06-19 17:11 UTC (permalink / raw) Actually, what the C standard says is that if you have a pointer just after the end of an array, then the result of dereferencing that pointer is "unpredictable". Such dereferences can cause segmentation fault, trash some other memory, or do nothing at all. Any of these outcomes is consistent with the standard. It's up to the programmer to avoid this behaviour. Really, all the standard requires is that the compiler can generate a pointer (not a corresponding object!) just past the right end of the array. In others words, if we define PLANET solar_system[ 9 ]; PLANET *past_pluto = solar_system + 9; Then all the standard requires is that past_pluto can be computed, and that it will compare correctly with pointers to other elements in solar_system, e.g. ( past_pluto > solar_system + 0 ) && ( past_pluto > solar_system + 1 ) && ( past_pluto > solar_system + 2 ) && ... ( past_pluto > solar_system + 8 ) That's all that's required. Access *past_pluto, and you're on your own. Also, the standard only requires a valid pointer to the point just after the end of an array; no similar rule applies to the beginning of the array. For example, if you declare PLANET *before_mercury = solar_system - 1; then the standard does NOT require that before_mercury compare meaningfully with the addresses of the solar_system elements. Of course, the result of dereferencing before_mercury is unpredictable. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 17:11 ` Frank J. Lhota @ 2002-06-19 19:31 ` Robert A Duff 2002-06-19 20:02 ` Hyman Rosen 0 siblings, 1 reply; 20+ messages in thread From: Robert A Duff @ 2002-06-19 19:31 UTC (permalink / raw) "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes: > Also, the standard only requires a valid pointer to the point just after the > end of an array; no similar rule applies to the beginning of the array. For > example, if you declare > > PLANET *before_mercury = solar_system - 1; > > then the standard does NOT require that before_mercury compare meaningfully > with the addresses of the solar_system elements. Really? I thought the above was OK. The STL of C++ depends heavily on this idiom. Is this a difference between C and C++? If so, what's the rationale (in C)? - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 19:31 ` Robert A Duff @ 2002-06-19 20:02 ` Hyman Rosen 2002-09-24 15:23 ` Matthew Heaney 0 siblings, 1 reply; 20+ messages in thread From: Hyman Rosen @ 2002-06-19 20:02 UTC (permalink / raw) Robert A Duff wrote: > "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes: >>Also, the standard only requires a valid pointer to the point just after the >>end of an array; no similar rule applies to the beginning of the array. For >>example, if you declare >> PLANET *before_mercury = solar_system - 1; >>then the standard does NOT require that before_mercury compare meaningfully >>with the addresses of the solar_system elements. > > Really? I thought the above was OK. The STL of C++ depends heavily on > this idiom. Is this a difference between C and C++? If so, what's the > rationale (in C)? It's not OK, and the STL never uses this idiom. The STL uses half-open intervals [begin,end) where the begin iterator points to the start of the sequence being manipulated, and the end iterator points to one past the end of the sequence being manipulated, and the canonical STL algorithm loop is while (begin != end) { operate_on(*begin++); } The "one past the end" pointer can be logical instead of physical, depending on the underlying container, but the algorithms don't care. For example, suppose I wish to copy a sequnce of integers from standard input into a vector. I can do it this way #include <iostream> #include <vector> #include <iterator> #include <algorithm> using namespace std; int main() { vector<int> v; copy( /* begin */ istream_iterator<int>(cin), /* end */ istream_iterator<int>(), /* to */ back_insert_iterator(v) ); } The istream_iterator<int>() reprsents a logical past-the-end iterator for reading from an input stream. A real input stream iterator will compare equal to that one once it has tried to read past the end-of-file on the input stream. The code one writes for something like copy (copy itself is part of the standard library) is completely ignorant of these shenaningans. It looks like a simple pointer loop - template<typename II, typename OI> OI copy(II begin, II end, OI to) { while (begin != end) *to++ = *begin++; return to; } The various iterator types have overloaded operators which implement their behavior. For example, incrementing an istream_iterator causes it to read the next object from the input stream. Dereferencing the iterator returns that object. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 20:02 ` Hyman Rosen @ 2002-09-24 15:23 ` Matthew Heaney 0 siblings, 0 replies; 20+ messages in thread From: Matthew Heaney @ 2002-09-24 15:23 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3D10E366.2010303@mail.com... > Robert A Duff wrote: > > > > Really? I thought the above was OK. The STL of C++ depends heavily on > > this idiom. Is this a difference between C and C++? If so, what's the > > rationale (in C)? > > It's not OK, and the STL never uses this idiom. The > STL uses half-open intervals [begin,end) where the > begin iterator points to the start of the sequence > being manipulated, and the end iterator points to > one past the end of the sequence being manipulated, > and the canonical STL algorithm loop is > > while (begin != end) { operate_on(*begin++); } STL iterators are a generalization of normal pointers. It is true that you can't address the element "before" the start of the array, because the compiler can allocate the array at the base of a segment, which doesn't have a "before" address. To iterate in reverse, and use a sentinel allowing you to fall off the beginning of the sequence to terminate the iteration, the STL uses a reverse iterator which is implemented as a wrapper around a normal, forward iterator (which you can always recover using the base() member function of the reverse iterator class). You don't really use roaming pointers in Ada; rather, you use an array object and a separate index. You never index the array prior to the first element of the array (nor past the last element, for that matter), but of course the value of the index can have a value the preceeds the T'First of the array. This has precedent in Ada; for example, you often see string searches implemented this way: function Find (S : String; C : Character) return Natural; Here, the function returns the value 0 to indicate that the character C wasn't found in array (string) S. In Charles, I have generalized the STL iterator behavior, such that you're allowed to have an iterator that designates the element "before" the start of the sequence. The Front iterator value has the sense of Index_Subtype'Pred (Array_Object'First), and the Back iterator value has the sense of Index_Subtype'Succ (Array_Object'Last). The First and Last iterators have their traditional sense. The complete mapping is: Charles STL -------- --- Front <no analog> First begin() Last iter = end(), --iter; Back end() The loop above can be written as: declare I : Iterator_Type := First (C); J : constant Iterator_Type := Back (C); begin while I /= J loop E := Element (I); <do something with E> I := Succ (I); end loop; end; Of course, it's often simpler to just use a passive iterator, similer to an STL algorithm: declare procedure Process (E : T) is begin <do something with E> end; procedure Iterate is new Generic_Select_Elements (Process); begin Iterate (First (C), Back (C)); end; In C++, (non-const) iterators return T&. You don't have reference types in Ada, but you can accomplish something very similar using access types. All the containers in Charles have a generic operation for returning an access type designating the container element (which are always aliased). For example, given a subprogram like this: procedure Do_Something (E : in out T); then you can do this: type T_Access is access all T; for T_Access'Storage_Size use 0; function To_Access is new Generic_Element (T_Access); I : Iterator_Type := First (C); J : constant Iterator_Type := Back (C); while I /= J loop declare E : Element_Type renames To_Access (I).all; begin Do_Something (E); end; I := Succ (I); end loop; which is exactly analogous to this STL fragment: void do_something(t& e); iterator i = c.begin(); const iterator j = c.end(); while (i != j) { t& e = *i; do_something(e); ++i; } > The "one past the end" pointer can be logical instead > of physical, depending on the underlying container, but > the algorithms don't care. That's also true in Charles. For example, the copy algorithm spec looks like this: generic type Source_Type is private; type Target_Type (<>) is limited private; with procedure Assign (Target : in Target_Type; Source : in Source_Type) is <>; with procedure Succ (Source : in out Source_Type) is <>; with procedure Succ (Target : in out Target_Type) is <>; with function "=" (L, R : Source_Type) return Boolean is <>; procedure Charles.Algorithms.Generic_Copy (First, Back : in Source_Type; Target : in out Target_Type); You don't have automatic instantiation in Ada as you have in C++, but you don't really need it. An instantiation of the algorithm above would look like this: declare procedure Assign (T : P1.Iterator_Type; S : P2.Iterator_Type) is begin Replace_Element (T, By => Element (S)); end; procedure Copy is new Generic_Copy (P2.Iterator_Type; P1.Iterator_Type); --everything else defaults I : P1.Iterator_Type := First (C2); begin ... Copy (First (C1), Back (C1), I); end; This is why reverse iterators aren't needed, either. All you need to do to iterate over the source in reverse is supply a different function as the generic actual: declare procedure Assign (T : P1.Iterator_Type; S : P2.Iterator_Type) is begin Replace_Element (T, By => Element (S)); end; procedure Copy is new Generic_Copy (P2.Iterator_Type; P1.Iterator_Type, Assign, Pred); -- this line is different I : P1.Iterator_Type := First (C2); begin ... Copy (Last (C1), Front (C1), I); --this is dif't too end; Of course, it's usually simpler to just use a passive iterator: declare I : P1.Iterator_Type := First (C2); procedure Process (E : T) is begin Replace_Element (I, By => E); I := Succ (I); end; procedure Iterate is new P2.Generic_Reverse_Select_Elements (Process); begin Iterate (First (C1), Back (C1)); end; You can even iterate over the target container in reverse using this technique: declare I : P1.Iterator_Type := Last (C2); procedure Process (E : T) is begin Replace_Element (I, By => E); I := Pred (I); end; procedure Iterate is new P2.Generic_Select_Elements (Process); begin Iterate (First (C1), Back (C1)); end; > The code one writes for something like copy (copy itself is > part of the standard library) is completely ignorant of these > shenaningans. It looks like a simple pointer loop - > > template<typename II, typename OI> > OI copy(II begin, II end, OI to) > { > while (begin != end) > *to++ = *begin++; > return to; > } The copy algorithm in Charles is implemented this way: procedure Charles.Algorithms.Generic_Copy (First, Back : in Source_Type; Target : in out Target_Type) is Source : Source_Type := First; begin while Source /= Back loop Assign (Target, Source); Succ (Source); Succ (Target); end loop; end Charles.Algorithms.Generic_Copy; which is basically the same as in the C++ example above. You can get the latest version of Charles at my home page: http://home.earthlink.net/~matthewjheaney/charles-20020923.zip I'll probably submit a paper to the Ada-Europe conference about Charles. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-19 14:29 ` Wes Groleau 2002-06-19 16:59 ` Darren New 2002-06-19 17:11 ` Frank J. Lhota @ 2002-06-19 19:37 ` Robert A Duff 2 siblings, 0 replies; 20+ messages in thread From: Robert A Duff @ 2002-06-19 19:37 UTC (permalink / raw) Wes Groleau <wesgroleau@despammed.com> writes: > > > A C array does not contain > > >"one element more" on either side. The standard allows setting > > >a pointer to the next element after the end of an array, but > > >such a pointer can not be dereferenced. > > The standard does? But most compilers ignore this, right? > > Or is the some other explanation why it's so @#$%@#$% easy > to get a segmentation fault in C ? I think the statement that the standard "can not be dereferenced" is correct, if you interpret it to mean "any program that does so does not conform to the C standard". The reason it's "so @#$%@#$% easy..." is that the C standard does not require compilers to detect programs that violate the C standard in this way (and many other ways). The Fortran and Pascal standards take the same attitude: compilers are not required to detect non-conforming programs. The Ada standard of course requires such detection in most cases, which is a huge advantage of Ada. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Look what I caught! was re:Ada paper critic 2002-06-17 17:35 Look what I caught! was re:Ada paper critic Alderson, Paul A. 2002-06-17 18:31 ` Darren New 2002-06-17 21:40 ` Vinzent Hoefler @ 2002-06-19 13:52 ` Ted Dennison 2 siblings, 0 replies; 20+ messages in thread From: Ted Dennison @ 2002-06-19 13:52 UTC (permalink / raw) "Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message news:<mailman.1024335422.31035.comp.lang.ada@ada.eu.org>... > Here's what I caught on my troll: > > 1.) People who missed the point (maybe intentionally) of the big > chain of package names you end up with in some Ada packages. > > The point here is if your company has a policy against using > "uses" in their code, then you have to: > > A.) Use a renames > B.) Use the fully specified name. > C.) Ignore the standard and use use. This honestly sounds like someone who hasn't used the language a whole lot. The idiom one should adopt in "no use" code is to make the package name part of the object's name, rather than tacking on extra stuff to an object's name to differentiate it from objects in other packages (the typical C approach). If you choose your names wisely, then you loose nothing by using the fully-specified object name (perhaps some "_"s change to "."s). One of the reasons a lot of newbies don't get this for a while is that the ARM sets a really bad example with its object naming. And yes, the result is unspeakably ugly. Shame on the ARM writers. > 3.) Many people in this group seem to have a "write the code > and never look at it again" attitude. Writing code is only A week ago I would have disagreed, but today I think you are right. However, we try to educate them when they pop up. :-) > This brings up my discussion on why not being able to tell > an array from a function is a problem. From the writing An array is just a built-in mapping function. There's no reason you need to know how the mapping function is implemented, unless you *do* want to check the implementation for errors (in which case you'd have to check anyway). > of the code its nice to be able to change your mind on > the implementation of a function to array. But then again > why are you changing something like this? This is an o Because some new factor arose that made the mapping dynamic instead of static. (Perhaps in version 2, the customer requested more control over the mapping). o Because another factor has been added that makes it not a simple lookup (but you can perhaps default out all but one of the parameters, leaving most user's code untouched). o Because you are using extreme programming techniques, so you start with a simple array lookup to get things running, then later replace it with the complicated mapping function. > 8.) People seem to miss the point that no matter how great the > language is, if it has crappy compilers, crappy debugging > and a crappy IDE's then its going to be a interesting blip > on the software radar screen that fades out fast. The Then why is Microsoft still in the compiler business? Their C++ compiler totally sucks (worst error messages ever). Their IDE might be somewhat nice now, but it sure didn't start out that way. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2002-09-24 15:23 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-17 17:35 Look what I caught! was re:Ada paper critic Alderson, Paul A. 2002-06-17 18:31 ` Darren New 2002-06-17 21:40 ` Vinzent Hoefler 2002-06-17 23:14 ` Darren New 2002-06-18 14:49 ` Hyman Rosen 2002-06-18 22:36 ` Vinzent Hoefler 2002-06-18 13:28 ` Marin David Condic 2002-06-24 19:17 ` Vinzent Hoefler 2002-06-18 19:16 ` Kevin Cline 2002-06-18 22:36 ` Vinzent Hoefler 2002-06-19 14:29 ` Wes Groleau 2002-06-19 16:59 ` Darren New 2002-06-19 17:48 ` Wes Groleau 2002-06-19 17:56 ` Darren New 2002-06-19 17:11 ` Frank J. Lhota 2002-06-19 19:31 ` Robert A Duff 2002-06-19 20:02 ` Hyman Rosen 2002-09-24 15:23 ` Matthew Heaney 2002-06-19 19:37 ` Robert A Duff 2002-06-19 13:52 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox