* Introductory Presentations, especially aimed at C++ programmers! @ 2009-07-10 12:24 John McCabe 2009-07-10 21:49 ` jimmaureenrogers ` (3 more replies) 0 siblings, 4 replies; 52+ messages in thread From: John McCabe @ 2009-07-10 12:24 UTC (permalink / raw) Hi all, It's now quite a long time since I used Ada in anger, but I've got a possible opportunity to present an introduction to Ada to a small group of C++ programmers (that I work with). Unfortunately I can't really spare the time to put together my own presentation so I wondered if anyone knew of a good one that's been published online that I could err, reuse :-) These guys have all been doing this C++ stuff for a while and we're all working on a multi-threaded embedded system using C++. I guess the main aim would be to show how it could have been done more easily with Ada. I realise this may seem an odd question but if you can help it would be most appreciated. All the best John ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-10 12:24 Introductory Presentations, especially aimed at C++ programmers! John McCabe @ 2009-07-10 21:49 ` jimmaureenrogers 2009-07-10 23:37 ` wwilson 2009-07-11 8:15 ` Stephen Leake ` (2 subsequent siblings) 3 siblings, 1 reply; 52+ messages in thread From: jimmaureenrogers @ 2009-07-10 21:49 UTC (permalink / raw) On Jul 10, 6:24 am, John McCabe <j...@nospam.assen.demon.co.uk> wrote: > Hi all, > > It's now quite a long time since I used Ada in anger, but I've got a > possible opportunity to present an introduction to Ada to a small > group of C++ programmers (that I work with). Unfortunately I can't > really spare the time to put together my own presentation so I > wondered if anyone knew of a good one that's been published online > that I could err, reuse :-) > > These guys have all been doing this C++ stuff for a while and we're > all working on a multi-threaded embedded system using C++. I guess the > main aim would be to show how it could have been done more easily with > Ada. > > I realise this may seem an odd question but if you can help it would > be most appreciated. > > All the best > John I have a modest html document demonstrating concurrent design patterns using Ada. You can have it if you want. Jim Rogers ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-10 21:49 ` jimmaureenrogers @ 2009-07-10 23:37 ` wwilson 2009-07-11 0:07 ` jimmaureenrogers 0 siblings, 1 reply; 52+ messages in thread From: wwilson @ 2009-07-10 23:37 UTC (permalink / raw) To: jimmaureenrogers On Fri, 10 Jul 2009 17:49:27 -0400, <jimmaureenrogers@worldnet.att.net> wrote: > On Jul 10, 6:24ï¿œam, John McCabe <j...@nospam.assen.demon.co.uk> wrote: >> Hi all, >> >> It's now quite a long time since I used Ada in anger, but I've got a >> possible opportunity to present an introduction to Ada to a small >> group of C++ programmers (that I work with). Unfortunately I can't >> really spare the time to put together my own presentation so I >> wondered if anyone knew of a good one that's been published online >> that I could err, reuse :-) >> >> These guys have all been doing this C++ stuff for a while and we're >> all working on a multi-threaded embedded system using C++. I guess the >> main aim would be to show how it could have been done more easily with >> Ada. >> >> I realise this may seem an odd question but if you can help it would >> be most appreciated. >> >> All the best >> John > > I have a modest html document demonstrating concurrent design patterns > using Ada. You can have it if you want. > > Jim Rogers Sounds interesting. How can I get a copy? Is it on the net somewhere? Thanks for any help. Lee -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-10 23:37 ` wwilson @ 2009-07-11 0:07 ` jimmaureenrogers 2009-07-12 4:00 ` wwilson 0 siblings, 1 reply; 52+ messages in thread From: jimmaureenrogers @ 2009-07-11 0:07 UTC (permalink / raw) On Jul 10, 5:37 pm, wwilson <leon.wins...@notes.udayton.edu> wrote: > On Fri, 10 Jul 2009 17:49:27 -0400, <jimmaureenrog...@worldnet.att.net> > wrote: > > > > > On Jul 10, 6:24 am, John McCabe <j...@nospam.assen.demon.co.uk> wrote: > >> Hi all, > > >> It's now quite a long time since I used Ada in anger, but I've got a > >> possible opportunity to present an introduction to Ada to a small > >> group of C++ programmers (that I work with). Unfortunately I can't > >> really spare the time to put together my own presentation so I > >> wondered if anyone knew of a good one that's been published online > >> that I could err, reuse :-) > > >> These guys have all been doing this C++ stuff for a while and we're > >> all working on a multi-threaded embedded system using C++. I guess the > >> main aim would be to show how it could have been done more easily with > >> Ada. > > >> I realise this may seem an odd question but if you can help it would > >> be most appreciated. > > >> All the best > >> John > > > I have a modest html document demonstrating concurrent design patterns > > using Ada. You can have it if you want. > > > Jim Rogers > > Sounds interesting. How can I get a copy? Is it on the net somewhere? > > Thanks for any help. > > Lee > -- > Using Opera's revolutionary e-mail client:http://www.opera.com/mail/ It is at http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html Jim Rogers ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-11 0:07 ` jimmaureenrogers @ 2009-07-12 4:00 ` wwilson 0 siblings, 0 replies; 52+ messages in thread From: wwilson @ 2009-07-12 4:00 UTC (permalink / raw) To: jimmaureenrogers Thanks. It looks good. Lee On Fri, 10 Jul 2009 20:07:17 -0400, <jimmaureenrogers@worldnet.att.net> wrote: > On Jul 10, 5:37ᅵpm, wwilson <leon.wins...@notes.udayton.edu> wrote: >> On Fri, 10 Jul 2009 17:49:27 -0400, <jimmaureenrog...@worldnet.att.net> >> ᅵ >> wrote: >> >> >> >> > On Jul 10, 6:24ᅵam, John McCabe <j...@nospam.assen.demon.co.uk> wrote: >> >> Hi all, >> >> >> It's now quite a long time since I used Ada in anger, but I've got a >> >> possible opportunity to present an introduction to Ada to a small >> >> group of C++ programmers (that I work with). Unfortunately I can't >> >> really spare the time to put together my own presentation so I >> >> wondered if anyone knew of a good one that's been published online >> >> that I could err, reuse :-) >> >> >> These guys have all been doing this C++ stuff for a while and we're >> >> all working on a multi-threaded embedded system using C++. I guess >> the >> >> main aim would be to show how it could have been done more easily >> with >> >> Ada. >> >> >> I realise this may seem an odd question but if you can help it would >> >> be most appreciated. >> >> >> All the best >> >> John >> >> > I have a modest html document demonstrating concurrent design patterns >> > using Ada. You can have it if you want. >> >> > Jim Rogers >> >> Sounds interesting. ᅵHow can I get a copy? Is it on the net somewhere? >> >> Thanks for any help. >> >> Lee >> -- >> Using Opera's revolutionary e-mail client:http://www.opera.com/mail/ > > It is at > http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html > > Jim Rogers -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-10 12:24 Introductory Presentations, especially aimed at C++ programmers! John McCabe 2009-07-10 21:49 ` jimmaureenrogers @ 2009-07-11 8:15 ` Stephen Leake 2009-07-15 6:43 ` Jean-Pierre Rosen 2016-12-07 17:06 ` john 3 siblings, 0 replies; 52+ messages in thread From: Stephen Leake @ 2009-07-11 8:15 UTC (permalink / raw) John McCabe <john@nospam.assen.demon.co.uk> writes: > It's now quite a long time since I used Ada in anger, but I've got a > possible opportunity to present an introduction to Ada to a small > group of C++ programmers (that I work with). Unfortunately I can't > really spare the time to put together my own presentation so I > wondered if anyone knew of a good one that's been published online > that I could err, reuse :-) AdaCore has some good stuff on their website http://www.adacore.com. In particular, see the "Ada answers" page http://www.adacore.com/home/ada_answers/. You could also ask them to come in and give a presentation. You might have to commit to paying for their tools if the presentation succeeds, but that's a good idea anyway. -- -- Stephe ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-10 12:24 Introductory Presentations, especially aimed at C++ programmers! John McCabe 2009-07-10 21:49 ` jimmaureenrogers 2009-07-11 8:15 ` Stephen Leake @ 2009-07-15 6:43 ` Jean-Pierre Rosen 2016-12-07 17:06 ` john 3 siblings, 0 replies; 52+ messages in thread From: Jean-Pierre Rosen @ 2009-07-15 6:43 UTC (permalink / raw) John McCabe a �crit : > Hi all, > > It's now quite a long time since I used Ada in anger, but I've got a > possible opportunity to present an introduction to Ada to a small > group of C++ programmers (that I work with). Unfortunately I can't > really spare the time to put together my own presentation so I > wondered if anyone knew of a good one that's been published online > that I could err, reuse :-) > I gave a general one-hour presentation of Ada at this year's FOSDEM event. The slides are available (PDF and ODP) from Ada-Belgium: http://www.cs.kuleuven.be/~dirk/ada-belgium/events/09/090207-fosdem.html -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2009-07-10 12:24 Introductory Presentations, especially aimed at C++ programmers! John McCabe ` (2 preceding siblings ...) 2009-07-15 6:43 ` Jean-Pierre Rosen @ 2016-12-07 17:06 ` john 2016-12-07 17:44 ` Luke A. Guest 2016-12-08 18:54 ` Adam Jensen 3 siblings, 2 replies; 52+ messages in thread From: john @ 2016-12-07 17:06 UTC (permalink / raw) Dear all, Please accept my apologies for my rudeness at having not responded to your comments. If you're all still around, here goes.... Jim - thanks for that. It looks good (I found it at AdaIC) but possibly in a lot more depth that I was thinking of. J-P - thanks too; that looks like a really useful presentation - I imagine I could talk for hours about it but it might be I could've cut it down. Stephen - thanks - I'll bear the AdaCore stuff in mind. For what it's worth, this idea never did come off in the end (lack of enthusiasm for the 1/2 hour presentation amongst the rest of the team probably had something to with it), but I found this thread as I thought it might be nice to pick one or two particular aspects of Ada that are so much nicer than C++ and present them. This was prompted by reviewing a piece of code someone had written where they needed to add an extra parameter to a function call. To try to maintain compatibility with existing code they changed the signature to add the new parameter at the end with a default value. In reality the new parameter was intrinsically tied to an existing parameter that's listed earlier in the sequence and requires a value to be supplied; it just looked wrong to me to do it that way, but it made me think how nice it is to have named parameter association in subroutine calls. Then I thought how nice it is to be able to declare arrays indexed by enumeration types, and so on.... Anyway - enough for now. Thank you all again for your advice; I'm very sorry I didn't reply then! John ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 17:06 ` john @ 2016-12-07 17:44 ` Luke A. Guest 2016-12-07 18:35 ` Jeffrey R. Carter 2016-12-08 8:23 ` Maciej Sobczak 2016-12-08 18:54 ` Adam Jensen 1 sibling, 2 replies; 52+ messages in thread From: Luke A. Guest @ 2016-12-07 17:44 UTC (permalink / raw) A good way to compare is to take something that is easy but easily fuckupable, like cycling an int between it's bounds in C++. Implement a cyclic buffer in both languages, show iteration over the container. Show the use of modular types for the index and the for x in container loop notation. And shoot down the bullshit argument if "any good Programmer wouldn't make that mistake" because it can happen to anyone. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 17:44 ` Luke A. Guest @ 2016-12-07 18:35 ` Jeffrey R. Carter 2016-12-07 23:03 ` Randy Brukardt 2016-12-08 8:23 ` Maciej Sobczak 1 sibling, 1 reply; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-07 18:35 UTC (permalink / raw) On 12/07/2016 10:44 AM, Luke A. Guest wrote: > > And shoot down the bullshit argument if "any good Programmer wouldn't make > that mistake" because it can happen to anyone. Examine the change logs of long-lived, open-source, C++ projects, especially those that communicate over the internet, like Firefox, and you'll find lots of fixes for buffer overflows and signed integer overflows, same as with C: things that are impossible in a well designed language. The proportion of such errors doesn't seem to decrease with time, either, so they are continuing to create new errors even as they patch the old ones. We have decades of experience with these languages that show beyond the shadow of a doubt that it is impossible for humans to write code in them without making such errors. -- Jeff Carter "In the frozen land of Nador they were forced to eat Robin's minstrels, and there was much rejoicing." Monty Python & the Holy Grail 70 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 18:35 ` Jeffrey R. Carter @ 2016-12-07 23:03 ` Randy Brukardt 2016-12-07 23:47 ` Jeffrey R. Carter 0 siblings, 1 reply; 52+ messages in thread From: Randy Brukardt @ 2016-12-07 23:03 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:o29kmm$mt7$1@dont-email.me... > On 12/07/2016 10:44 AM, Luke A. Guest wrote: >> >> And shoot down the bullshit argument if "any good Programmer wouldn't >> make >> that mistake" because it can happen to anyone. > > Examine the change logs of long-lived, open-source, C++ projects, > especially those that communicate over the internet, like Firefox, and > you'll find lots of fixes for buffer overflows and signed integer > overflows, same as with C: things that are impossible in a well designed > language. The proportion of such errors doesn't seem to decrease with > time, either, so they are continuing to create new errors even as they > patch the old ones. We have decades of experience with these languages > that show beyond the shadow of a doubt that it is impossible for humans to > write code in them without making such errors. To be fair, though, such things can happen in Ada, too. Case in point: something that happened to me today. A customer had what appears to be a permissions problem installing Janus/Ada, so before contacting us, they tried an uninstall. The uninstaller crashed. I asked them to send me the exact message, and it proved to be overflow error in Claw.Registry. Tracking that down showed that the buffer for reading a registry variable (so stuff could be removed from it) wasn't big enough. Of course, Ada detected the error and crashed, but that's only an iota better than what would have happened in C (the uninstaller didn't do its job either way). The problem seemed familar, and it turns out that I had a similar problem in the installer a few years back. And I had increased the buffer size in the installer program back then. But I failed to increase the buffer size in the separate uninstaller program. A rookie mistake. After 35 years of Ada programming. (You may argue precisely what the rookie mistake was, but surely there is one here.) Yet another data point that no one is immune from making silly errors, in any language. It at least helps to have a language where the culture is to detect rather than ignore errors (and especially when customers think the same way, allowing a more rapid squashing of bugs). Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 23:03 ` Randy Brukardt @ 2016-12-07 23:47 ` Jeffrey R. Carter 2016-12-08 0:08 ` Paul Rubin ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-07 23:47 UTC (permalink / raw) On 12/07/2016 04:03 PM, Randy Brukardt wrote: > > To be fair, though, such things can happen in Ada, too. Case in point: > something that happened to me today. > > A customer had what appears to be a permissions problem installing > Janus/Ada, so before contacting us, they tried an uninstall. The uninstaller > crashed. I asked them to send me the exact message, and it proved to be > overflow error in Claw.Registry. Tracking that down showed that the buffer > for reading a registry variable (so stuff could be removed from it) wasn't > big enough. Of course, Ada detected the error and crashed, but that's only > an iota better than what would have happened in C (the uninstaller didn't do > its job either way). Well, no, that's not the same thing. You didn't overflow a buffer; you tried to overflow a buffer, but Ada wouldn't let you. To my mind, that's exponentially better than what you get in C. Nobody was able to take control of your computer because your program crashed. And exponentially better than being prevented from overflowing a buffer is being able to figure out how to do declare B : Buffer (1 .. Just_The_Right_Size); which is usually possible. -- Jeff Carter "In the frozen land of Nador they were forced to eat Robin's minstrels, and there was much rejoicing." Monty Python & the Holy Grail 70 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 23:47 ` Jeffrey R. Carter @ 2016-12-08 0:08 ` Paul Rubin 2016-12-09 22:01 ` Randy Brukardt 2016-12-08 8:08 ` Maciej Sobczak 2016-12-09 21:58 ` Randy Brukardt 2 siblings, 1 reply; 52+ messages in thread From: Paul Rubin @ 2016-12-08 0:08 UTC (permalink / raw) > exponentially better than being prevented from overflowing a buffer is > being able to figure out how to do > declare > B : Buffer (1 .. Just_The_Right_Size); Alternatively the buffer could be dynamically sized according to the data. That's not in the Ada spirit because of the possible OOM and memory allocation latency getting in the way of embedded realtime applications, but for a workstation app it's perfectly workable. Horses for courses. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-08 0:08 ` Paul Rubin @ 2016-12-09 22:01 ` Randy Brukardt 2016-12-09 22:18 ` Jeffrey R. Carter 0 siblings, 1 reply; 52+ messages in thread From: Randy Brukardt @ 2016-12-09 22:01 UTC (permalink / raw) "Paul Rubin" <no.email@nospam.invalid> wrote in message news:877f7b5llo.fsf@nightsong.com... >> exponentially better than being prevented from overflowing a buffer is >> being able to figure out how to do >> declare >> B : Buffer (1 .. Just_The_Right_Size); > > Alternatively the buffer could be dynamically sized according to the > data. That's not in the Ada spirit because of the possible OOM and > memory allocation latency getting in the way of embedded realtime > applications, but for a workstation app it's perfectly workable. > Horses for courses. That's one possible way to use the API in question, since there's no way to find out beforehand how much data you'll need. (You could ask for the size ahead of time, but of course that's a potential race condition so it doesn't really help.) Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 22:01 ` Randy Brukardt @ 2016-12-09 22:18 ` Jeffrey R. Carter 2016-12-13 0:53 ` Randy Brukardt 0 siblings, 1 reply; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-09 22:18 UTC (permalink / raw) On 12/09/2016 03:01 PM, Randy Brukardt wrote: > "Paul Rubin" <no.email@nospam.invalid> wrote in message > news:877f7b5llo.fsf@nightsong.com... >>> exponentially better than being prevented from overflowing a buffer is >>> being able to figure out how to do >>> declare >>> B : Buffer (1 .. Just_The_Right_Size); >> >> Alternatively the buffer could be dynamically sized according to the >> data. That's not in the Ada spirit because of the possible OOM and >> memory allocation latency getting in the way of embedded realtime >> applications, but for a workstation app it's perfectly workable. >> Horses for courses. > > That's one possible way to use the API in question, since there's no way to > find out beforehand how much data you'll need. (You could ask for the size > ahead of time, but of course that's a potential race condition so it doesn't > really help.) I was including in being able to do declare B : Buffer (1 .. Just_The_Right_Size); such things as declare S : String := Get_Line; and there's usually a way to do that even when you don't know beforehand how big the result will be. After all, the Get_Line function doesn't know beforehand how long a String it will return. I don't how the API in question works, so I can't say for sure if there's a way to do this for it, but there usually is. -- Jeff Carter "If you don't get the President of the United States on that phone, ... you're going to have to answer to the Coca-Cola Company." Dr. Strangelove 32 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 22:18 ` Jeffrey R. Carter @ 2016-12-13 0:53 ` Randy Brukardt 2016-12-13 3:21 ` Jeffrey R. Carter 0 siblings, 1 reply; 52+ messages in thread From: Randy Brukardt @ 2016-12-13 0:53 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:o2fagv$n4s$1@dont-email.me... > On 12/09/2016 03:01 PM, Randy Brukardt wrote: >> "Paul Rubin" <no.email@nospam.invalid> wrote in message >> news:877f7b5llo.fsf@nightsong.com... >>>> exponentially better than being prevented from overflowing a buffer is >>>> being able to figure out how to do >>>> declare >>>> B : Buffer (1 .. Just_The_Right_Size); >>> >>> Alternatively the buffer could be dynamically sized according to the >>> data. That's not in the Ada spirit because of the possible OOM and >>> memory allocation latency getting in the way of embedded realtime >>> applications, but for a workstation app it's perfectly workable. >>> Horses for courses. >> >> That's one possible way to use the API in question, since there's no way >> to >> find out beforehand how much data you'll need. (You could ask for the >> size >> ahead of time, but of course that's a potential race condition so it >> doesn't >> really help.) > > I was including in being able to do > > declare > B : Buffer (1 .. Just_The_Right_Size); > > such things as > > declare > S : String := Get_Line; > > and there's usually a way to do that even when you don't know beforehand > how big the result will be. After all, the Get_Line function doesn't know > beforehand how long a String it will return. I don't how the API in > question works, so I can't say for sure if there's a way to do this for > it, but there usually is. For reading from a device (like a keyboard), it's impossible to know ahead of time what is going to be read (without forcing some sort of pause into the program which is usually not wanted). A Get_Line like the above generally requires some sort of incremental allocation (a buffer is allocated, if its not big enough a bigger one is allocated, the first one is copied into it, and then we repeat until a <LF> appears), and thus you need to avoid such Get_Lines for things where performance might matter (like reading from a file). [If you can figure out what kind of entity a handle accesses, then perhaps you could use a different implementation for a file vs. a device; as always, how complicated do you want to make your I/O libraries??] Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 0:53 ` Randy Brukardt @ 2016-12-13 3:21 ` Jeffrey R. Carter 2016-12-13 21:15 ` Robert A Duff 2016-12-13 22:50 ` Randy Brukardt 0 siblings, 2 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-13 3:21 UTC (permalink / raw) On 12/12/2016 05:53 PM, Randy Brukardt wrote: > > A Get_Line like the above > generally requires some sort of incremental allocation (a buffer is > allocated, if its not big enough a bigger one is allocated, the first one is > copied into it, and then we repeat until a <LF> appears), As the person who created the Get_Line function, I can assure that's not how most versions are implemented. -- Jeff Carter "Alms for an ex-leper!" Monty Python's Life of Brian 75 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 3:21 ` Jeffrey R. Carter @ 2016-12-13 21:15 ` Robert A Duff 2016-12-13 22:05 ` Jeffrey R. Carter 2016-12-13 22:50 ` Randy Brukardt 1 sibling, 1 reply; 52+ messages in thread From: Robert A Duff @ 2016-12-13 21:15 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > On 12/12/2016 05:53 PM, Randy Brukardt wrote: >> >> A Get_Line like the above >> generally requires some sort of incremental allocation (a buffer is >> allocated, if its not big enough a bigger one is allocated, the first one is >> copied into it, and then we repeat until a <LF> appears), > > As the person who created the Get_Line function, I can assure that's not > how most versions are implemented. That's how it's done in GNAT. How is it done in "most versions"? From a-textio.adb: function Get_Line (File : File_Type) return String is function Get_Rest (S : String) return String; -- This is a recursive function that reads the rest of the line and -- returns it. S is the part read so far. -------------- -- Get_Rest -- -------------- function Get_Rest (S : String) return String is -- The first time we allocate a buffer of size 500. Each following -- time we allocate a buffer the same size as what we have read so -- far. This limits us to a logarithmic number of calls to Get_Rest -- and also ensures only a linear use of stack space. Buffer : String (1 .. Integer'Max (500, S'Length)); Last : Natural; begin Get_Line (File, Buffer, Last); declare R : constant String := S & Buffer (1 .. Last); begin if Last < Buffer'Last then return R; else pragma Assert (Last = Buffer'Last); -- If the String has the same length as the buffer, and there -- is no end of line, check whether we are at the end of file, -- in which case we have the full String in the buffer. if End_Of_File (File) then return R; else return Get_Rest (R); end if; end if; end; end Get_Rest; -- Start of processing for Get_Line begin return Get_Rest (""); end Get_Line; - Bob ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 21:15 ` Robert A Duff @ 2016-12-13 22:05 ` Jeffrey R. Carter 2016-12-13 22:52 ` Robert A Duff 2016-12-13 23:05 ` Randy Brukardt 0 siblings, 2 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-13 22:05 UTC (permalink / raw) On 12/13/2016 02:15 PM, Robert A Duff wrote: > > That's how it's done in GNAT. How is it done in "most versions"? Yes, but the GNAT implementation is rather poor. A better way doesn't need to copy anything: function Get_Line return String is Buffer : String (1 .. 1_000); Last : Natural; begin -- Get_Line Get_Line (Item => Buffer, Last => Last); if Last < Buffer'Last then return Buffer (1 .. Last); end if; return Buffer & Get_Line; end Get_Line; -- Jeff Carter "Apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh water system, and public health, what have the Romans ever done for us?" Monty Python's Life of Brian 80 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 22:05 ` Jeffrey R. Carter @ 2016-12-13 22:52 ` Robert A Duff 2016-12-14 0:02 ` Jeffrey R. Carter 2016-12-13 23:05 ` Randy Brukardt 1 sibling, 1 reply; 52+ messages in thread From: Robert A Duff @ 2016-12-13 22:52 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > Yes, but the GNAT implementation is rather poor. It depends on whether you care about very long lines. If so, you want to double the buffer size each time (or similar). If the line is a million characters, the GNAT version does around 20 recursive calls, whereas the version below does around 1000 recursive calls. I'm too lazy to measure the speed, and anyway, the computation might be swamped by the disk access. Text_IO should be (should have been!) designed for convenience, not efficiency. You don't call Text_IO in the inner loops of an embedded real-time system. ;-) >... A better way doesn't > need to copy anything: You can't do "return Buffer & Get_Line;" without some copying. I'm willing to believe that GNAT does more copying than is absolutely necessary. > function Get_Line return String is > Buffer : String (1 .. 1_000); > Last : Natural; > begin -- Get_Line > Get_Line (Item => Buffer, Last => Last); > > if Last < Buffer'Last then > return Buffer (1 .. Last); > end if; > > return Buffer & Get_Line; > end Get_Line; - Bob ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 22:52 ` Robert A Duff @ 2016-12-14 0:02 ` Jeffrey R. Carter 0 siblings, 0 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-14 0:02 UTC (permalink / raw) On 12/13/2016 03:52 PM, Robert A Duff wrote: > > It depends on whether you care about very long lines. > If so, you want to double the buffer size each time > (or similar). One can double the buffer size each time without making an explicit copy, as GNAT's version does. > If the line is a million characters, the GNAT version > does around 20 recursive calls, whereas the version below > does around 1000 recursive calls. True. But in my experience a fixed buffer of 1,000 won't involve any recursion for 99.9% of calls, and will rarely recurse more than once. Worrying about the efficiency of very rare situations, given the general inefficiency of Text_IO anyway, seems like a waste of time. > You can't do "return Buffer & Get_Line;" without some copying. > I'm willing to believe that GNAT does more copying than is > absolutely necessary. I didn't copy anything. How the compiler translates what I wrote is immaterial, and I presume it will do a better job of optimizing the return than I could. -- Jeff Carter "Apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh water system, and public health, what have the Romans ever done for us?" Monty Python's Life of Brian 80 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 22:05 ` Jeffrey R. Carter 2016-12-13 22:52 ` Robert A Duff @ 2016-12-13 23:05 ` Randy Brukardt 2016-12-14 0:13 ` Jeffrey R. Carter 1 sibling, 1 reply; 52+ messages in thread From: Randy Brukardt @ 2016-12-13 23:05 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:o2pr84$fis$1@dont-email.me... ... > return Buffer & Get_Line; This does dynamic allocation of some sort under the covers, and in any case copies the contents of both parts of the string. The version Bob shows is more complicated in order to control the amount of stack space used, and appears to be designed to maximize the use of stack space rather than allocated temporaries for GNAT. That seems like a win for their implementation. In Janus/Ada, both of these formulations would do a heck of a lot of dynamic allocation under the covers (anything dynamically sized is allocated from a storage pool ultimately). [That's what I was thinking of when I said "dynamically allocated".] & of unconstrained strings is VERY expensive, so I would write a routine similar to the one Bob showed, but I'd use slicing rather than & to create the final result. (Given the general nature of Get_Line, and the way it is used, it will be on some program's critical path, so it can never be fast enough.) [I used future tense as this particular Ada 2005 change hasn't yet made it into Janus/Ada.] Conclusion: I don't see any difference between Bob's version and yours in terms of dynamic memory allocation needed. Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 23:05 ` Randy Brukardt @ 2016-12-14 0:13 ` Jeffrey R. Carter 2016-12-14 22:48 ` Randy Brukardt 0 siblings, 1 reply; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-14 0:13 UTC (permalink / raw) On 12/13/2016 04:05 PM, Randy Brukardt wrote: > > Conclusion: I don't see any difference between Bob's version and yours in > terms of dynamic memory allocation needed. The difference is that, for every recursive call, the GNAT version declares 2 buffers, and mine only declares 1. -- Jeff Carter "Apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh water system, and public health, what have the Romans ever done for us?" Monty Python's Life of Brian 80 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-14 0:13 ` Jeffrey R. Carter @ 2016-12-14 22:48 ` Randy Brukardt 2016-12-15 0:00 ` Jeffrey R. Carter 0 siblings, 1 reply; 52+ messages in thread From: Randy Brukardt @ 2016-12-14 22:48 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:o2q2o6$c16$1@dont-email.me... > On 12/13/2016 04:05 PM, Randy Brukardt wrote: >> >> Conclusion: I don't see any difference between Bob's version and yours in >> terms of dynamic memory allocation needed. > > The difference is that, for every recursive call, the GNAT version > declares 2 buffers, and mine only declares 1. ...and generates a second one implicitly. Still no difference. The semantics of & require a copy, it can't be optimized out (with the possible exception of a direct assignment to something). From a different message of Jeff's: >... Worrying about the efficiency of very rare situations, given the >general > inefficiency of Text_IO anyway, seems like a waste of time. Customers would disagree with you. I once had to refund a customer because they complained about the efficiency of our Text_IO vs. that of the similar C functions. I spent several weeks redoing Text_IO in part because of that experience (mostly so the performance of Get_Line from files is better). It's very usual that a new customer will write a trial program with their shiny new compiler that just reads some text file with Get_Line. Us old Ada hands know better than to expect great performance from that, but one does not want someone's first impression of Ada to be bad. Thus the performance of Get_Line is one of those things that has to be optimized absolutely as much as possible. (One cannot get into arguments of premature optimization if they are returning their compiler and switching to some other language!!!) Randy. Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-14 22:48 ` Randy Brukardt @ 2016-12-15 0:00 ` Jeffrey R. Carter 2016-12-15 10:46 ` Maciej Sobczak 2016-12-15 20:14 ` Niklas Holsti 0 siblings, 2 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-15 0:00 UTC (permalink / raw) On 12/14/2016 03:48 PM, Randy Brukardt wrote: > "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message > news:o2q2o6$c16$1@dont-email.me... >> >> The difference is that, for every recursive call, the GNAT version >> declares 2 buffers, and mine only declares 1. > > ...and generates a second one implicitly. Still no difference. The semantics > of & require a copy, it can't be optimized out (with the possible exception > of a direct assignment to something). Maybe. I'm not a compiler writer, and I understand that GNAT's version may have been written with a deep understanding of what the GNAT compiler will do with the code. But from a general point of view, I take the view that the compiler can do a better job of optimization than I can, so letting it do an implicit 2nd declaration is the way to go. Also return Line & Get_Line; is tail recursion; IIUC, Erlang compilers are required to optimize tail recursion away, so such an optimization must be reasonably easy to implement. Maybe an Ada compiler does it, too. Again, I'd rather give the compiler the ability to do that optimization. >> ... Worrying about the efficiency of very rare situations, given the >> general >> inefficiency of Text_IO anyway, seems like a waste of time. > > Customers would disagree with you. I once had to refund a customer because > they complained about the efficiency of our Text_IO vs. that of the similar > C functions. I spent several weeks redoing Text_IO in part because of that > experience (mostly so the performance of Get_Line from files is better). > > It's very usual that a new customer will write a trial program with their > shiny new compiler that just reads some text file with Get_Line. Us old Ada > hands know better than to expect great performance from that, but one does > not want someone's first impression of Ada to be bad. Thus the performance > of Get_Line is one of those things that has to be optimized absolutely as > much as possible. (One cannot get into arguments of premature optimization > if they are returning their compiler and switching to some other > language!!!) I suspect your customer was looking for an excuse not to use Ada. There's no way Text_IO can be as efficient as C equivalents. I'm not aware of a C equivalent of the Get_Line function. Anyway, since Janus/Ada is an Ada-95 compiler, you're talking about a different Get_Line. -- Jeff Carter "I was in love with a beautiful blonde once, dear. She drove me to drink. That's the one thing I'm indebted to her for." Never Give a Sucker an Even Break 109 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 0:00 ` Jeffrey R. Carter @ 2016-12-15 10:46 ` Maciej Sobczak 2016-12-16 7:37 ` Paul Rubin 2016-12-15 20:14 ` Niklas Holsti 1 sibling, 1 reply; 52+ messages in thread From: Maciej Sobczak @ 2016-12-15 10:46 UTC (permalink / raw) > I suspect your customer was looking for an excuse not to use Ada. No, you got it backwards. Hint: think about that customer's customers. Ada is a niche language that needs to actively compete for its place in the programmer's mindset. Being slower than equivalent C (or C++, where you will find the std::getline function) is not the right way to compete. Let's please stop with this "premature optimization" nonsense. Most of the software needs to be designed for performance up-front and this in particular (general-purpose libraries) is a very good example. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 10:46 ` Maciej Sobczak @ 2016-12-16 7:37 ` Paul Rubin 0 siblings, 0 replies; 52+ messages in thread From: Paul Rubin @ 2016-12-16 7:37 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: > Being slower than equivalent C (or C++, where you will find the > std::getline function) is not the right way to compete. std::getline is actually pathetically slow for some reason. I replaced it with the C library fgets in a program that did a lot of line input, and it sped up the whole program by several times. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 0:00 ` Jeffrey R. Carter 2016-12-15 10:46 ` Maciej Sobczak @ 2016-12-15 20:14 ` Niklas Holsti 2016-12-15 20:27 ` Jeffrey R. Carter 1 sibling, 1 reply; 52+ messages in thread From: Niklas Holsti @ 2016-12-15 20:14 UTC (permalink / raw) On 16-12-15 02:00 , Jeffrey R. Carter wrote: > Also > > return Line & Get_Line; > > is tail recursion; No, the last operation called is "&", not Get_Line. It might be considered a special sort of recursion -- "appending tail recursion" -- and perhaps some Ada compilers might optimize such use of "&" by just arranging for the variable Line and the result of the recursive call of Get_Line to be placed contiguously in some sort of return-value stack (secondary stack). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 20:14 ` Niklas Holsti @ 2016-12-15 20:27 ` Jeffrey R. Carter 2016-12-15 21:04 ` Niklas Holsti 2016-12-16 7:41 ` Paul Rubin 0 siblings, 2 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-15 20:27 UTC (permalink / raw) On 12/15/2016 01:14 PM, Niklas Holsti wrote: > On 16-12-15 02:00 , Jeffrey R. Carter wrote: > >> Also >> >> return Line & Get_Line; >> >> is tail recursion; > > No, the last operation called is "&", not Get_Line. In Erlang, list_length ([]) -> 0; list_length ([First | Rest]) -> 1 + list_length (Rest). is considered tail recursion and is required to be optimized away, so that's how I was using the term. -- Jeff Carter "I'm particularly glad that these lovely children were here today to hear that speech. Not only was it authentic frontier gibberish, it expressed a courage little seen in this day and age." Blazing Saddles 88 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 20:27 ` Jeffrey R. Carter @ 2016-12-15 21:04 ` Niklas Holsti 2016-12-15 21:40 ` Jeffrey R. Carter 2016-12-16 7:41 ` Paul Rubin 1 sibling, 1 reply; 52+ messages in thread From: Niklas Holsti @ 2016-12-15 21:04 UTC (permalink / raw) On 16-12-15 22:27 , Jeffrey R. Carter wrote: > On 12/15/2016 01:14 PM, Niklas Holsti wrote: >> On 16-12-15 02:00 , Jeffrey R. Carter wrote: >> >>> Also >>> >>> return Line & Get_Line; >>> >>> is tail recursion; >> >> No, the last operation called is "&", not Get_Line. > > In Erlang, > > list_length ([]) -> > 0; > list_length ([First | Rest]) -> > 1 + list_length (Rest). > > is considered tail recursion and is required to be optimized away, so > that's how I was using the term. Can you give me a reference on that? I'm skeptical. According to the Erlang manual I found, http://erlang.org/doc/pdf/otp-system-documentation.pdf, section 5.6.3, "If the last expression of a function body is a function call, a tail recursive call is done", but goes on to say that this example of the factorial function: fact(N) when N>0 -> N * fact(N-1); fact(0) -> 1. is "not tail-recursive, since a multiplication is done on the result of the recursive call to fact(N-1)". -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 21:04 ` Niklas Holsti @ 2016-12-15 21:40 ` Jeffrey R. Carter 0 siblings, 0 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-15 21:40 UTC (permalink / raw) On 12/15/2016 02:04 PM, Niklas Holsti wrote: > > Can you give me a reference on that? Afraid not. It's been quite a while since I learned Erlang, and I'm talking from memory. I recall seeing a function like that and a comment that Erlang is required to optimize the recursive call away, but my memory may be incorrect. -- Jeff Carter "I'm particularly glad that these lovely children were here today to hear that speech. Not only was it authentic frontier gibberish, it expressed a courage little seen in this day and age." Blazing Saddles 88 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-15 20:27 ` Jeffrey R. Carter 2016-12-15 21:04 ` Niklas Holsti @ 2016-12-16 7:41 ` Paul Rubin 1 sibling, 0 replies; 52+ messages in thread From: Paul Rubin @ 2016-12-16 7:41 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes: > list_length ([]) -> > 0; > list_length ([First | Rest]) -> > 1 + list_length (Rest). > is considered tail recursion and is required to be optimized away, so > that's how I was using the term. That's not tail recursion because after the recursive call, the result has to be passed to +. You'd write it tail recursively something like: list_length(X) -> go(X, 0). go([], n) -> n; go([First|Rest], n) -> go(Rest, n+1). That lets the compiler transform the recursive call into a jump. I don't remember the name of this trick of using an extra argument to make something tail recursive, but it's idiomatic in functional programming. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 3:21 ` Jeffrey R. Carter 2016-12-13 21:15 ` Robert A Duff @ 2016-12-13 22:50 ` Randy Brukardt 2016-12-14 0:08 ` Jeffrey R. Carter 1 sibling, 1 reply; 52+ messages in thread From: Randy Brukardt @ 2016-12-13 22:50 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:o2npd6$a9a$1@dont-email.me... > On 12/12/2016 05:53 PM, Randy Brukardt wrote: >> >> A Get_Line like the above >> generally requires some sort of incremental allocation (a buffer is >> allocated, if its not big enough a bigger one is allocated, the first one >> is >> copied into it, and then we repeat until a <LF> appears), > > As the person who created the Get_Line function, I can assure that's not > how most versions are implemented. Huh? This function has been in Ada.Text_IO since 2005. Why would anyone other than a compiler writer implement it? Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-13 22:50 ` Randy Brukardt @ 2016-12-14 0:08 ` Jeffrey R. Carter 2016-12-14 1:01 ` Shark8 0 siblings, 1 reply; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-14 0:08 UTC (permalink / raw) On 12/13/2016 03:50 PM, Randy Brukardt wrote: > > Huh? This function has been in Ada.Text_IO since 2005. Why would anyone > other than a compiler writer implement it? Yes. Before that it was part of the PragmAda Reusable Components. See Carter, J., "Variable-Length String Input in Ada", /Ada Letters/, 1989 May/Jun available via http://pragmada.x10hosting.com/papers.html -- Jeff Carter "Apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh water system, and public health, what have the Romans ever done for us?" Monty Python's Life of Brian 80 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-14 0:08 ` Jeffrey R. Carter @ 2016-12-14 1:01 ` Shark8 0 siblings, 0 replies; 52+ messages in thread From: Shark8 @ 2016-12-14 1:01 UTC (permalink / raw) On Tuesday, December 13, 2016 at 5:08:41 PM UTC-7, Jeffrey R. Carter wrote: > > Carter, J., "Variable-Length String Input in Ada", /Ada Letters/, 1989 May/Jun > > available via > > http://pragmada.x10hosting.com/papers.html I'm sure I've seen your link to papers before, and I think I thanked you for it at the time... but I'd like to go out of my way to thank you again for making your papers available. Thank you very much. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 23:47 ` Jeffrey R. Carter 2016-12-08 0:08 ` Paul Rubin @ 2016-12-08 8:08 ` Maciej Sobczak 2016-12-08 8:38 ` Dmitry A. Kazakov 2016-12-08 10:25 ` Paul Rubin 2016-12-09 21:58 ` Randy Brukardt 2 siblings, 2 replies; 52+ messages in thread From: Maciej Sobczak @ 2016-12-08 8:08 UTC (permalink / raw) > > Of course, Ada detected the error and crashed, but that's only > > an iota better than what would have happened in C (the uninstaller didn't do > > its job either way). > > Well, no, that's not the same thing. You didn't overflow a buffer; you tried to > overflow a buffer, but Ada wouldn't let you. But it is not what you have been referring to earlier. You have proposed to browse the log of changes of any long-lived internet-oriented open-source project in C++ and see how many fixes there were for buffer overflow problems. Randy has correctly shown that in Ada it would not be any better - the log history would contain the same number of fixes for what is the same programming error. The run-time consequences of such errors might be different, but that was not your argument, either. Instead, you have written: "it is impossible for humans to write code in them without making such errors" The problem is - you did not provide any evidence to claim that those same humans would not make such errors in Ada. SPARK is a game-changer in this area - but there are too few long-lived internet-oriented open-source projects in SPARK to make a realistic comparison either. That is, if for whatever reason it is unrealistic to write such projects in SPARK, then SPARK is not a solution, either. > To my mind, that's exponentially > better than what you get in C. Nobody was able to take control of your computer > because your program crashed. And *this* is a real argument. Ada is safer not because it would prevent programmers from making errors, but because it would help them *contain the damage* resulting from those errors. Use the right arguments, then you will be (more) convincing. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-08 8:08 ` Maciej Sobczak @ 2016-12-08 8:38 ` Dmitry A. Kazakov 2016-12-08 10:25 ` Paul Rubin 1 sibling, 0 replies; 52+ messages in thread From: Dmitry A. Kazakov @ 2016-12-08 8:38 UTC (permalink / raw) On 08/12/2016 09:08, Maciej Sobczak wrote: > The problem is - you did not provide any evidence to claim that > those same humans would not make such errors in Ada. > > SPARK is a game-changer in this area - but there are too few > long-lived internet-oriented open-source projects in SPARK to make a > realistic comparison either. That is, if for whatever reason it is > unrealistic to write such projects in SPARK, then SPARK is not a > solution, either. That's right. Exception contracts are long overdue and the design of proofs must allow mixed strategies instead of all-or-nothing. In most cases it would be enough to statically prove absence of exceptions. However, in the given case the proof must be about "no exception when registry key value is less than N" That goes more towards a full correctness proof. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-08 8:08 ` Maciej Sobczak 2016-12-08 8:38 ` Dmitry A. Kazakov @ 2016-12-08 10:25 ` Paul Rubin 2016-12-08 13:39 ` Maciej Sobczak 1 sibling, 1 reply; 52+ messages in thread From: Paul Rubin @ 2016-12-08 10:25 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: > Randy has correctly shown that in Ada it would not be any better - the > log history would contain the same number of fixes for what is the > same programming error. I'm not convinced: because of C's lack of checks, more bugs make it through the testing process, and end getting noticed after released, resulting in fixes in the log. An Ada programmer might code the same bug, but it might get caught right away during the developer's private workflow, so the buggy version wouldn't make it into the public repo resulting in a bug ticket and fix. > Instead, you have written: "it is impossible for humans to write code > in them without making such errors" > > The problem is - you did not provide any evidence to claim that those > same humans would not make such errors in Ada. I think the claim was that it's impossible for humans to stop making silly errors in general, not that specific error of mismatched bounds on a buffer. > SPARK is a game-changer in this area - but there are too few > long-lived internet-oriented open-source projects in SPARK to make a > realistic comparison either. That is, if for whatever reason it is > unrealistic to write such projects in SPARK, then SPARK is not a > solution, either. In this case another solution is dynamically allocated buffers and automatic reclamation (GC, RAII, or whatever). Then a bug could result in OOM, but that doesn't seem to happen nearly as often as buffer overflows. > And *this* is a real argument. Ada is safer not because it would > prevent programmers from making errors, but because it would help them > *contain the damage* resulting from those errors. Best is to do both. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-08 10:25 ` Paul Rubin @ 2016-12-08 13:39 ` Maciej Sobczak 2016-12-09 1:30 ` Paul Rubin 0 siblings, 1 reply; 52+ messages in thread From: Maciej Sobczak @ 2016-12-08 13:39 UTC (permalink / raw) > I'm not convinced: because of C's lack of checks, more bugs make it > through the testing process, How? Your unit test contains the checks for proper program outcome, so you don't need them in the language. And conversely, if your tests are incomplete (that is, their coverage is incomplete), then language checks will not help, either, as they will not be ignited. > An Ada programmer might code the same > bug, but it might get caught right away during the developer's private > workflow How? Let's say I made a bug that overflows the array under some specific conditions, but my "private workflow" for testing does not involve input that overflows that array. This error will go to release, no matter what is the programming language. You might argue that there is some class of errors that can appear harmless even under test (like overflowing forth-and-back arithmetic) and language checks can help detect those errors even with partial unit tests. This would be a good argument for Ada. You can also claim that Ada errors are "safer" (the damage containment that I already mentioned) or that error handling in Ada is more assisting, thus reducing the diagnostic effort, but these are different arguments. > I think the claim was that it's impossible for humans to stop making > silly errors in general Agreed. But the argument was that Ada would prevent humans from making such errors, which is (yet) an unfounded claim. Of course, there are errors that can be detected at compile-time and there are some that are even prevented by the grammar itself - arguably Ada is stronger in this area than C (or C++), but buffer overflows are not, at least directly, in this category. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-08 13:39 ` Maciej Sobczak @ 2016-12-09 1:30 ` Paul Rubin 2016-12-09 8:31 ` J-P. Rosen 2016-12-09 8:35 ` G.B. 0 siblings, 2 replies; 52+ messages in thread From: Paul Rubin @ 2016-12-09 1:30 UTC (permalink / raw) Maciej Sobczak <see.my.homepage@gmail.com> writes: > How? Your unit test contains the checks for proper program outcome, This type of thing wouldn't show up in unit tests, since the bug was from a mismatch between behaviours of two separate units. But it could show up during whole-system testing. > Let's say I made a bug that overflows the array under some > specific conditions, but my "private workflow" for testing does not > involve input that overflows that array. This error will go to > release, no matter what is the programming language. Let's say you write the program in C, and you do make such a bug. Assigning arbitrary probabilities to possible outcomes, let's say: 1) with 40% likelihood, your test inputs don't encounter the bug, so you don't detect the bug, and you ship the buggy code. 2) with 30% likelihood, the test input encounters the bug and the program crashes. You find and fix the bug before shipping. 3) with 30% likelihood, the test input encounters the bug, but the program keeps running with no observable misbehaviour (you've written outside the array bounds in a way that doesn't break anything for that particular input). You don't notice the bug so you ship the buggy code. So you have 70% chance of shipping the buggy code. With Ada and subscript checks, you eliminate possibility #3, so it becomes 40% #1 and 60% #2. You aren't guaranteed to fix the bug before shipping, but your chances of doing so have nearly doubled. Sounds like a win to me. >> I think the claim was that it's impossible for humans to stop making >> silly errors in general > Agreed. But the argument was that Ada would prevent humans from making > such errors, which is (yet) an unfounded claim. I think the claim is that Ada prevents a certain class of silly errors, not that it eliminates all silly errors. If you write the code in assembler, there might be 100 places where you could go wrong. If you write it in C, you get control structures, named variables, etc. so that might eliminate 50 of the 100 possible error sites. With Ada you get a serious type system, much more runtime checks, etc., so that might eliminate another 30. It's possible (say with SPARK) to eliminate even more, but never all 100, and it gets harder and harder as you push closer to machine-checked perfection. > Of course, there are errors that can be detected at compile-time and > there are some that are even prevented by the grammar itself - > arguably Ada is stronger in this area than C (or C++), but buffer > overflows are not, at least directly, in this category. I would say that C++ is stronger in this area than Ada, since it has dynamically sized strings in the STL container library. You'd use those instead of fixed-size buffers, so there's no way to overflow except OOM. The main cost becomes non-deterministic timing from the dynamic allocation, making STL strings unsuitable for realtime control. But since we're talking about a desktop application, it's ok to use them. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 1:30 ` Paul Rubin @ 2016-12-09 8:31 ` J-P. Rosen 2016-12-09 8:58 ` Paul Rubin 2016-12-09 8:35 ` G.B. 1 sibling, 1 reply; 52+ messages in thread From: J-P. Rosen @ 2016-12-09 8:31 UTC (permalink / raw) Le 09/12/2016 à 02:30, Paul Rubin a écrit : > I would say that C++ is stronger in this area than Ada, since it has > dynamically sized strings in the STL container library. ??? So has Ada: Ada.Strings.Unbounded -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 8:31 ` J-P. Rosen @ 2016-12-09 8:58 ` Paul Rubin 2016-12-09 9:18 ` J-P. Rosen 0 siblings, 1 reply; 52+ messages in thread From: Paul Rubin @ 2016-12-09 8:58 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > So has Ada: Ada.Strings.Unbounded I thought there was no way to reclaim runtime-allocated memory in Ada. Is there? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 8:58 ` Paul Rubin @ 2016-12-09 9:18 ` J-P. Rosen 2016-12-09 9:27 ` Paul Rubin 0 siblings, 1 reply; 52+ messages in thread From: J-P. Rosen @ 2016-12-09 9:18 UTC (permalink / raw) Le 09/12/2016 à 09:58, Paul Rubin a écrit : > "J-P. Rosen" <rosen@adalog.fr> writes: >> So has Ada: Ada.Strings.Unbounded > > I thought there was no way to reclaim runtime-allocated memory in Ada. > Is there? > Explicit reclaim has always been there: Unchecked_Deallocation. Unbounded_Strings are controlled types that perform automatic reclamation, the user doesn't have to worry. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 9:18 ` J-P. Rosen @ 2016-12-09 9:27 ` Paul Rubin 2016-12-09 10:49 ` J-P. Rosen 0 siblings, 1 reply; 52+ messages in thread From: Paul Rubin @ 2016-12-09 9:27 UTC (permalink / raw) "J-P. Rosen" <rosen@adalog.fr> writes: > Unbounded_Strings are controlled types that perform automatic > reclamation, the user doesn't have to worry. You mean they're reclaimed when the scope exits, something like C++? That's good to know. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 9:27 ` Paul Rubin @ 2016-12-09 10:49 ` J-P. Rosen 2016-12-09 19:58 ` Jeffrey R. Carter 0 siblings, 1 reply; 52+ messages in thread From: J-P. Rosen @ 2016-12-09 10:49 UTC (permalink / raw) Le 09/12/2016 à 10:27, Paul Rubin a écrit : > "J-P. Rosen" <rosen@adalog.fr> writes: >> Unbounded_Strings are controlled types that perform automatic >> reclamation, the user doesn't have to worry. > > You mean they're reclaimed when the scope exits, something like C++? > That's good to know. > Yes. They are implemented with hidden pointers, with automatic reclaimation when assigned or going out of scope. This is almost the canonical example of using controlled types. You should have a look at controlled types, especially if you miss C++ destructors ;-) -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 10:49 ` J-P. Rosen @ 2016-12-09 19:58 ` Jeffrey R. Carter 0 siblings, 0 replies; 52+ messages in thread From: Jeffrey R. Carter @ 2016-12-09 19:58 UTC (permalink / raw) On 12/09/2016 03:49 AM, J-P. Rosen wrote: > Le 09/12/2016 à 10:27, Paul Rubin a écrit : >> "J-P. Rosen" <rosen@adalog.fr> writes: >>> Unbounded_Strings are controlled types that perform automatic >>> reclamation, the user doesn't have to worry. >> >> You mean they're reclaimed when the scope exits, something like C++? >> That's good to know. >> > Yes. They are implemented with hidden pointers, with automatic > reclaimation when assigned or going out of scope. This is almost the > canonical example of using controlled types. > > You should have a look at controlled types, especially if you miss C++ > destructors ;-) And this has been around since Ada 95. -- Jeff Carter "If you don't get the President of the United States on that phone, ... you're going to have to answer to the Coca-Cola Company." Dr. Strangelove 32 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 1:30 ` Paul Rubin 2016-12-09 8:31 ` J-P. Rosen @ 2016-12-09 8:35 ` G.B. 2016-12-09 8:57 ` Paul Rubin 2016-12-09 22:15 ` Randy Brukardt 1 sibling, 2 replies; 52+ messages in thread From: G.B. @ 2016-12-09 8:35 UTC (permalink / raw) On 09.12.16 02:30, Paul Rubin wrote: > I would say that C++ is stronger in this area than Ada, since it has > dynamically sized strings in the STL container library. You'd use those > instead of fixed-size buffers, so there's no way to overflow except OOM. But can you pass std::string to the functions of Win32? (I'm curious about the specifics in this example, since, e.g., RegQueryValueEx has a usage protocol associated with it and seems to not produce an overflow of the BYTE far* buffer.) Also, I think that the STL still requires discipline when one uses indexing. This little playground can produce a number of results that only prompt a cliché: "any competent programmer will avoid any of these mistakes"... void reorder(std::string& s) { using str = std::string; const str::const_iterator right_end = s.end(); const str::const_reverse_iterator left_end = s.rend(); str::iterator lr; str::reverse_iterator rl; for (lr = s.begin(), rl = s.rbegin() - 1; lr != right_end && rl != left_end; lr += 2, rl += 2) // or try `rl -= 2` { *(lr + 2) = *lr; *(rl + 2) = *rl; // and `rl - 2` } } Segfaults, null characters, and some harder to test algorithmic errors, depending on variation. -- "HOTDOGS ARE NOT BOOKMARKS" Springfield Elementary teaching staff ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 8:35 ` G.B. @ 2016-12-09 8:57 ` Paul Rubin 2016-12-09 22:15 ` Randy Brukardt 1 sibling, 0 replies; 52+ messages in thread From: Paul Rubin @ 2016-12-09 8:57 UTC (permalink / raw) "G.B." <bauhaus@notmyhomepage.invalid> writes: > But can you pass std::string to the functions of Win32? I don't know. There might be some C++ bindings to an underlying Win32 API that wants null-terminated strings or something. But remember, the issue here was buffer sizes in the client program. > for (lr = s.begin(), rl = s.rbegin() - 1; > lr != right_end && rl != left_end; > lr += 2, rl += 2) // or try `rl -= 2` > { > *(lr + 2) = *lr; > *(rl + 2) = *rl; // and `rl - 2` > } This is pretty horrific. Trying to shuffle the string in place at all is a code smell. What the heck is it even supposed to do? > Segfaults, null characters, and some harder to test algorithmic > errors, depending on variation. Doubtless. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-09 8:35 ` G.B. 2016-12-09 8:57 ` Paul Rubin @ 2016-12-09 22:15 ` Randy Brukardt 1 sibling, 0 replies; 52+ messages in thread From: Randy Brukardt @ 2016-12-09 22:15 UTC (permalink / raw) "G.B." <bauhaus@notmyhomepage.invalid> wrote in message news:o2dq9o$37c$1@dont-email.me... ... > (I'm curious about the specifics in this example, since, e.g., > RegQueryValueEx has a usage protocol associated with it and > seems to not produce an overflow of the BYTE far* buffer.) The specific case is a call to the Claw procedure Claw.Registry.Get, which takes an String and Last value much like Text_IO.Get_Line. This routine raises an exception if the result doesn't fit, as the output buffer has fixed bounds. One could imagine a Claw.Registry.Get that took an Unbounded_String, which would be able to avoid the overflow problem, but we didn't include one in the Claw package. I believe that is because doing so (throughout Claw) would force Ada.Strings.Unbounded to be loaded as part of every Claw program, and that seemed like a large enough package that we didn't want that. There is a way to recover from the Overflow_Error raised by Claw.Registry.Get, but I only found that out examining the code yesterday -- I didn't use that mechanism in either the installer or uninstaller, or any other Claw program that I've written, either. (Most of the others are tying a GUI to the registry key, and the GUI enforces a maximum length, so there isn't as much need.) Randy. Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 23:47 ` Jeffrey R. Carter 2016-12-08 0:08 ` Paul Rubin 2016-12-08 8:08 ` Maciej Sobczak @ 2016-12-09 21:58 ` Randy Brukardt 2 siblings, 0 replies; 52+ messages in thread From: Randy Brukardt @ 2016-12-09 21:58 UTC (permalink / raw) "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message news:o2a6vq$q8s$1@dont-email.me... > On 12/07/2016 04:03 PM, Randy Brukardt wrote: >> >> To be fair, though, such things can happen in Ada, too. Case in point: >> something that happened to me today. >> >> A customer had what appears to be a permissions problem installing >> Janus/Ada, so before contacting us, they tried an uninstall. The >> uninstaller >> crashed. I asked them to send me the exact message, and it proved to be >> overflow error in Claw.Registry. Tracking that down showed that the >> buffer >> for reading a registry variable (so stuff could be removed from it) >> wasn't >> big enough. Of course, Ada detected the error and crashed, but that's >> only >> an iota better than what would have happened in C (the uninstaller didn't >> do >> its job either way). > > Well, no, that's not the same thing. You didn't overflow a buffer; you > tried to overflow a buffer, but Ada wouldn't let you. To be fair, the attempt to overflow the buffer came from a Windows API call, which wouldn't let you do that no matter what the language. A C program could still get in trouble by ignoring the failing API result, but that wouldn't be hard in Ada, either. The main difference here is the culture surrounding the languages, where in Ada a library ignoring failure would be a library no one would use; can't say that about C libraries. Randy. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 17:44 ` Luke A. Guest 2016-12-07 18:35 ` Jeffrey R. Carter @ 2016-12-08 8:23 ` Maciej Sobczak 1 sibling, 0 replies; 52+ messages in thread From: Maciej Sobczak @ 2016-12-08 8:23 UTC (permalink / raw) > A good way to compare is to take something that is easy but easily > fuckupable, like cycling an int between it's bounds in C++. It is trivial with a wider type (like int64_t) as a base and really nobody needs to do full-cycle over int64_t. This example is nice, but not convincing. > Implement a > cyclic buffer in both languages, http://www.boost.org/doc/libs/1_61_0/doc/html/circular_buffer.html > show iteration over the container. If you take Ada 2012, make sure to take C++11 (or C++14) as well, for fair comparison: http://www.cprogramming.com/c++11/c++11-ranged-for-loop.html Note also that containers are much easier for beginners in C++, as they require less clutter at declaration. Try to recode examples from the above link in Ada to see why you would not convince a C++ programmer with such arguments. -- Maciej Sobczak * http://www.inspirel.com ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Introductory Presentations, especially aimed at C++ programmers! 2016-12-07 17:06 ` john 2016-12-07 17:44 ` Luke A. Guest @ 2016-12-08 18:54 ` Adam Jensen 1 sibling, 0 replies; 52+ messages in thread From: Adam Jensen @ 2016-12-08 18:54 UTC (permalink / raw) On 12/07/2016 12:06 PM, john@mccabe.org.uk wrote: [snip] > I thought it might be nice to pick one or two particular aspects of Ada that are so much nicer than C++ and present them. I would be most impressed by a computer programming technology if there were epistemological and pedagogical sophistication in the human interface materials. A simple way to start making improvements might be by addressing the battology problem. http://grammar.about.com/od/words/a/Campaign-To-Cut-The-Clutter-Zinssers-Brackets.htm It may also be useful if a community performed natural language analysis on its human interface materials. There could probably be patterns to be found that would suggest something about the culture. Conversely, style guides, linguistic templates, controlled vocabularies, etc. could be used in the human interface materials to promote a culture. Lastly, the methods by which the educational and reference materials are generated could be systematized. Rather than striving for a cult-like social organization that surrounds a charismatic personality or a fetishized technology, an engineered scientific organization (rational-legal) would be a much more appropriate and interesting goal. https://en.wikipedia.org/wiki/Tripartite_classification_of_authority But, of course, putting on war paint and gibbering brainwashy hype over an over while shaking your junk at a rival gang does seem to sell tickets (I guess). ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2016-12-16 7:41 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-07-10 12:24 Introductory Presentations, especially aimed at C++ programmers! John McCabe 2009-07-10 21:49 ` jimmaureenrogers 2009-07-10 23:37 ` wwilson 2009-07-11 0:07 ` jimmaureenrogers 2009-07-12 4:00 ` wwilson 2009-07-11 8:15 ` Stephen Leake 2009-07-15 6:43 ` Jean-Pierre Rosen 2016-12-07 17:06 ` john 2016-12-07 17:44 ` Luke A. Guest 2016-12-07 18:35 ` Jeffrey R. Carter 2016-12-07 23:03 ` Randy Brukardt 2016-12-07 23:47 ` Jeffrey R. Carter 2016-12-08 0:08 ` Paul Rubin 2016-12-09 22:01 ` Randy Brukardt 2016-12-09 22:18 ` Jeffrey R. Carter 2016-12-13 0:53 ` Randy Brukardt 2016-12-13 3:21 ` Jeffrey R. Carter 2016-12-13 21:15 ` Robert A Duff 2016-12-13 22:05 ` Jeffrey R. Carter 2016-12-13 22:52 ` Robert A Duff 2016-12-14 0:02 ` Jeffrey R. Carter 2016-12-13 23:05 ` Randy Brukardt 2016-12-14 0:13 ` Jeffrey R. Carter 2016-12-14 22:48 ` Randy Brukardt 2016-12-15 0:00 ` Jeffrey R. Carter 2016-12-15 10:46 ` Maciej Sobczak 2016-12-16 7:37 ` Paul Rubin 2016-12-15 20:14 ` Niklas Holsti 2016-12-15 20:27 ` Jeffrey R. Carter 2016-12-15 21:04 ` Niklas Holsti 2016-12-15 21:40 ` Jeffrey R. Carter 2016-12-16 7:41 ` Paul Rubin 2016-12-13 22:50 ` Randy Brukardt 2016-12-14 0:08 ` Jeffrey R. Carter 2016-12-14 1:01 ` Shark8 2016-12-08 8:08 ` Maciej Sobczak 2016-12-08 8:38 ` Dmitry A. Kazakov 2016-12-08 10:25 ` Paul Rubin 2016-12-08 13:39 ` Maciej Sobczak 2016-12-09 1:30 ` Paul Rubin 2016-12-09 8:31 ` J-P. Rosen 2016-12-09 8:58 ` Paul Rubin 2016-12-09 9:18 ` J-P. Rosen 2016-12-09 9:27 ` Paul Rubin 2016-12-09 10:49 ` J-P. Rosen 2016-12-09 19:58 ` Jeffrey R. Carter 2016-12-09 8:35 ` G.B. 2016-12-09 8:57 ` Paul Rubin 2016-12-09 22:15 ` Randy Brukardt 2016-12-09 21:58 ` Randy Brukardt 2016-12-08 8:23 ` Maciej Sobczak 2016-12-08 18:54 ` Adam Jensen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox