comp.lang.ada
 help / color / mirror / Atom feed
From: Michael S <already5chosen@yahoo.com>
Subject: Re: Have the Itanium critics all been proven wrong?
Date: Wed, 22 Aug 2012 07:00:31 -0700 (PDT)
Date: 2012-08-22T07:00:31-07:00	[thread overview]
Message-ID: <eddaeeee-8cfa-402e-964a-e795c4590dbe@q22g2000vbx.googlegroups.com> (raw)
In-Reply-To: k12jul$t5q$1@dont-email.me

On Aug 22, 3:39 pm, Brian Drummond <br...@shapes.demon.co.uk> wrote:
> On Wed, 22 Aug 2012 03:32:00 -0700, Michael S wrote:
> > On Aug 22, 12:09 am, Brian Drummond <br...@shapes.demon.co.uk> wrote:
>
> >> Heh, the book I learned C++ from didn't even mention STL, (or
> >> namespaces for that matter) and regarded templates as a bit unstable.
> >> When did STL appear? (And yes, I have newer books now...)
>
> > Interview with Alex Stepanov.
> >http://www.sgi.com/tech/stl/drdobbs-interview.html
>
> So, not long after Ada-95.
> Interesting article - he even speculates that STL could be implemented in
> Ada. I suppose Ada.Containers goes some way towards that.
>
> >> > Obsession with separate compilation does not help either.
>
> >> Does not help what? I'm unclear what point you have in mind?
> > Ada has his own library/link system. They can store as little or as much
> > info as they like in the intermediate files and do as much processing as
> > needed in the link phase.
> > Times change, noways C and in particular C++ developers very rarely rely
> > on language-agnostic linkers, but language features that would make that
> > type of analysis possible still absent.
>
> Indeed - in gcc, Ada and C use the same linker! though Ada passes through
> a binding stage handling additional inter-module information. C and C++,
> as far as I can see, still rely on external tools to (mis?)manage the
> dependencies.

Well, we are not at managing dependencies now, don't we?
We are at error/warning detection and reporting during link phase.
Gnu ld of today is very far of language agnostic. In Microsoft world
people routinely use link-time  code generation. So, original
technical reasons for not doing that sort of checks do not exist any
more. But the checks are still not provided due to deficiencies of the
language itself.

>
> > BTW, how Ada deals with that? That it how pointer (access) to auto
> > object distinguished from pointers to  dynamic or static objects when
> > they (pointers) are passed to the different module?
>
> Now you have caught me; it's a good question but I can't answer it
> accurately. So I have added c.l.a to the newsgroups in the hope that
> others will keep me straight.
>
> I believe pointers to "auto" (C-speak for stack-allocated?) objects can
> only be passed down the call stack; accessibility checks would otherwise
> fail (unless defeated by unchecked_access).
>
> Given modules A and B, it's not normal to actually access B's pointers
> from module A. More commonly A would only see a "private type" exported
> from B, and not even know it was a pointer. A can hold such types, but
> can only use them by invoking methods from B (such as accessors) on them.
> This puts B in charge of the object lifetimes; if A wants to access a
> stale object, expect an exception.

Exception, if I am lucky.
If I am less lucky, the physical place of old auto object is now
occupied by new auto object of the same or compatible type and the
call to accessor caused silent corruption.

>
> >> Ada ... doesn't by default supply a garbage collector.
> > Automatic garbage collection not aided by compiler is certainly possible
> > and done in practice (Boehm ?). But is not such GC significantly less
> > efficient than GC aided by compiler?
>
> such as Java's GC for example?
>
> I don't know that would generally be the case. If you need GC, you may
> often be able to structure the application to gain some advantage from
> its properties; for example, it may make identical sized garbage objects,
> or it may have natural "down times" when you can harmlessly schedule
> (part of) a GC.

That's not a good argument.
Compiler-supplied GC can also provide hint interface, like
Compact_righ_now, Please_do_not_compact_if_you_dont_have_to.

>
> Without knowing those properties, you can't design a GC to optimally fit.
> So I believe that compiler-supplied GC would often be less efficient. In
> that respect, I agree with the decision shared by Ada and C++, to not
> provide it by default.
>
> - Brian

But when compiler is aware of GC the tracking of liveness of objects
become much easier (for some implementations - trivial). You can
organize your memory database in such way that you will never have to
scan things.






  reply	other threads:[~2012-08-26 14:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5021874F.1747D0BF@sonic.net>
     [not found] ` <1e1tf9-0kp2.ln1@ntp6.tmsw.no>
     [not found]   ` <k0gn5r$l9h$1@needham.csi.cam.ac.uk>
     [not found]     ` <GPRWr.31944$Bw1.31300@newsfe05.iad>
     [not found]       ` <k0gq97$li8$1@needham.csi.cam.ac.uk>
     [not found]         ` <k0h6ef$jke$1@speranza.aioe.org>
     [not found]           ` <46f19bfc-930e-4f06-b5a6-c60f39cfda0c@p14g2000yqk.googlegroups.com>
     [not found]             ` <k0r609$4ij$1@speranza.aioe.org>
     [not found]               ` <077b12f6-1196-4b5c-bbdb-04291b1ae616@q22g2000vbx.googlegroups.com>
     [not found]                 ` <k0rree$lkn$1@speranza.aioe.org>
     [not found]                   ` <CC5730C5.1BC2E%yaldnif.w@blueyonder.co.uk>
     [not found]                     ` <k0t67b$b8r$1@speranza.aioe.org>
     [not found]                       ` <CC585119.1BCCC%yaldnif.w@blueyonder.co.uk>
     [not found]                         ` <k0uenp$fbg$1@speranza.aioe.org>
     [not found]                           ` <k0vo9u$fer$1@dont-email.me>
     [not found]                             ` <589825d2-d998-456a-9c37-c8ae13e1e7bc@e29g2000vbm.googlegroups.com>
2012-08-21 20:48                               ` Have the Itanium critics all been proven wrong? Niklas Holsti
2012-08-21 22:32                                 ` Robert A Duff
     [not found]                                 ` <keb838pn40uf3pq1536e9b3dptgd57h3se@invalid.netcom.com>
2012-08-22  2:32                                   ` Bill Findlay
2012-08-22  2:42                                     ` Adam Beneschan
2012-08-22  4:08                                       ` Bill Findlay
2012-08-22  4:40                                         ` Adam Beneschan
2012-08-22  9:29                                 ` Michael S
2012-08-22 10:14                                   ` Dmitry A. Kazakov
2012-08-22 10:28                                   ` Ludovic Brenta
2012-08-22 12:48                                     ` Brian Drummond
2012-08-22 15:42                                       ` Ludovic Brenta
2012-08-22 10:54                                   ` Niklas Holsti
2012-08-22 12:43                                     ` Michael S
2012-08-22 13:20                                       ` Michael S
2012-08-22 22:30                                         ` Randy Brukardt
     [not found]                               ` <k10tdr$nm6$1@dont-email.me>
     [not found]                                 ` <bb4e5231-142b-437c-8c2a-bbd6daf34df8@g2g2000vba.googlegroups.com>
2012-08-22 12:39                                   ` Brian Drummond
2012-08-22 14:00                                     ` Michael S [this message]
2012-08-22 15:06                                       ` Brian Drummond
2012-08-22 15:21                                         ` Bill Findlay
2012-08-22 15:59                                         ` Michael S
2012-08-22 16:01                                           ` Michael S
2012-08-22 16:58                                           ` Georg Bauhaus
2012-08-22 18:18                                           ` Bill Findlay
2012-08-22 15:05                                     ` Simon Wright
     [not found] <k0jkb3$hm1$1@dont-email.me>
     [not found] ` <632eec054470aafb59e98744e950ea8b@dizum.com>
     [not found]   ` <k0m5c3$t6t$1@dont-email.me>
     [not found]     ` <CC545B6F.1BA11%yaldnif.w@blueyonder.co.uk>
2012-08-22 22:35       ` Bill Findlay
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox