Introductory Presentations, especially aimed at C++ programmers!

Introductory Presentations, especially aimed at C++ programmers!

[John McCabe]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[jimmaureenrogers]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[wwilson]

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/

Re: Introductory Presentations, especially aimed at C++ programmers!

[jimmaureenrogers]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Stephen Leake]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[wwilson]

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/

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jean-Pierre Rosen]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[john]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Luke A. Guest]

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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

> 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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Maciej Sobczak]

> > 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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Maciej Sobczak]

> 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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Dmitry A. Kazakov]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Maciej Sobczak]

> 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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Adam Jensen]

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).

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[J-P. Rosen]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[G.B.]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

"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?

Re: Introductory Presentations, especially aimed at C++ programmers!

[J-P. Rosen]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[J-P. Rosen]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Robert A Duff]

"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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Robert A Duff]

"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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Shark8]

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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Randy Brukardt]

"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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Maciej Sobczak]

> 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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Niklas Holsti]

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
       .      @       .

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Niklas Holsti]

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
       .      @       .

Re: Introductory Presentations, especially aimed at C++ programmers!

[Jeffrey R. Carter]

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

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

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.

Re: Introductory Presentations, especially aimed at C++ programmers!

[Paul Rubin]

"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.