From: Paul Derbyshire <pderbysh@usa.net>
To: egcs@egcs.cygnus.com
Subject: Re: Bug in libm or libstdc++.
Date: Tue, 02 Mar 1999 08:32:00 -0000 [thread overview]
Message-ID: <3.0.6.32.19990302113149.009338b0@pop.globalserve.net> (raw)
In-Reply-To: < 199903012007.MAA14269@atrus.synopsys.com >
At 12:07 PM 3/1/99 PST, you wrote:
[Deleted]
['export' is in Stroustrup 3rd Ed.]
Interesting. There is one lone mention in connection with templates, which
seems to describe some usage that never actually occurs, namely, putting a
template in a .cc file and expecting another .cc file to magically be able
to use it, instead of putting it in a .h file. How would such a scheme be
implemented anyways? Making the compiler scan the filesystem (and then
maybe the net) for .cc files that might define a template after it sees one
used without definition in a translation unit it is processing, strikes me
as impractical... Perhaps the idea is for the "export" to cause a compiler,
on reading a .cc file, to add any instantiations of the template in
question to a global collection of object files the linker always links
against, but then of course,
1. What if the other cc file is encountered first?
2. What if the other cc file uses a combination of template
parameters the first does not instantiate?
3. What if the compiler does this and the linker expects otherwise,
or vice versa?
>Please note that while Stroustrup's 3rd edition is an excellent book, it
>contains many errors. See http://www.research.att.com/~bs/3rd_errata.html
>for a list of the known ones.
Read them. (For the printing that produced my copy.) The only one with
potential to really trip someone up is:
pg 218 s/if (atexit(&my_cleanup))/if (atexit(&my_cleanup)==0)/
:-)
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
WARNING: multiple messages have this Message-ID
From: Paul Derbyshire <pderbysh@usa.net>
To: egcs@egcs.cygnus.com
Subject: Re: Bug in libm or libstdc++.
Date: Wed, 31 Mar 1999 23:46:00 -0000 [thread overview]
Message-ID: <3.0.6.32.19990302113149.009338b0@pop.globalserve.net> (raw)
Message-ID: <19990331234600.L7ydaWPrAnDLmc8arC2-0rUbQdxuw70fUJqQk2qDn28@z> (raw)
In-Reply-To: <199903012007.MAA14269@atrus.synopsys.com>
At 12:07 PM 3/1/99 PST, you wrote:
[Deleted]
['export' is in Stroustrup 3rd Ed.]
Interesting. There is one lone mention in connection with templates, which
seems to describe some usage that never actually occurs, namely, putting a
template in a .cc file and expecting another .cc file to magically be able
to use it, instead of putting it in a .h file. How would such a scheme be
implemented anyways? Making the compiler scan the filesystem (and then
maybe the net) for .cc files that might define a template after it sees one
used without definition in a translation unit it is processing, strikes me
as impractical... Perhaps the idea is for the "export" to cause a compiler,
on reading a .cc file, to add any instantiations of the template in
question to a global collection of object files the linker always links
against, but then of course,
1. What if the other cc file is encountered first?
2. What if the other cc file uses a combination of template
parameters the first does not instantiate?
3. What if the compiler does this and the linker expects otherwise,
or vice versa?
>Please note that while Stroustrup's 3rd edition is an excellent book, it
>contains many errors. See http://www.research.att.com/~bs/3rd_errata.html
>for a list of the known ones.
Read them. (For the printing that produced my copy.) The only one with
potential to really trip someone up is:
pg 218 s/if (atexit(&my_cleanup))/if (atexit(&my_cleanup)==0)/
:-)
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
next prev parent reply other threads:[~1999-03-02 8:32 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-01 11:44 Mike Stump
[not found] ` < 199903011944.LAA09214@kankakee.wrs.com >
1999-03-01 12:08 ` Joe Buck
[not found] ` < 199903012007.MAA14269@atrus.synopsys.com >
1999-03-02 8:32 ` Paul Derbyshire [this message]
1999-03-02 23:17 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
1999-03-31 23:46 ` Joe Buck
1999-03-31 23:46 ` Mike Stump
-- strict thread matches above, loose matches on Subject: below --
1999-03-02 19:07 N8TM
1999-03-31 23:46 ` N8TM
1999-03-02 18:59 N8TM
1999-03-31 23:46 ` N8TM
1999-03-02 8:31 Doug Semler
1999-03-31 23:46 ` Doug Semler
1999-02-26 14:04 Mike Stump
[not found] ` < 199902262203.OAA07030@kankakee.wrs.com >
1999-02-27 20:44 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Mike Stump
1999-02-24 15:13 Paul Derbyshire
[not found] ` < 3.0.6.32.19990222090333.00847df0@pop.globalserve.net >
1999-02-24 15:34 ` Joe Buck
[not found] ` < 199902242332.PAA09334@atrus.synopsys.com >
1999-02-25 22:25 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990226012513.008e5450@pop.globalserve.net >
1999-02-26 10:38 ` Joe Buck
[not found] ` < 199902261836.KAA17757@atrus.synopsys.com >
1999-02-26 22:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990227012120.0084e180@pop.globalserve.net >
1999-02-27 9:40 ` Marc Espie
[not found] ` < 199902271740.SAA14323@quatramaran.ens.fr >
1999-02-27 20:45 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 0:19 ` Alexandre Oliva
[not found] ` < ord82tlj4l.fsf@araguaia.dcc.unicamp.br >
1999-03-02 7:58 ` Paul Derbyshire
1999-03-02 23:08 ` Alexandre Oliva
1999-03-31 23:46 ` Alexandre Oliva
1999-03-31 23:46 ` Paul Derbyshire
1999-03-31 23:46 ` Alexandre Oliva
1999-02-28 22:53 ` Marc Espie
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Joe Buck
1999-02-24 15:42 ` Bob McWhirter
[not found] ` < Pine.LNX.3.96.990224183714.7438r-100000@exeter.exeter.org >
1999-02-25 22:20 ` Paul Derbyshire
[not found] ` <199902261635.LAA23787@wagner.Princeton.EDU>
1999-02-27 19:08 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-03-01 8:30 ` Joern Rennecke
[not found] ` < 199903011630.QAA00110@phal.cygnus.co.uk >
1999-03-02 8:04 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990302110405.00945870@pop.globalserve.net >
1999-03-02 8:38 ` Joern Rennecke
1999-03-31 23:46 ` Joern Rennecke
1999-03-31 23:46 ` Paul Derbyshire
1999-03-31 23:46 ` Joern Rennecke
[not found] ` <Pine.SUN.3.91.990228142826.5950V-100000@is>
1999-02-28 4:57 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Bob McWhirter
1999-02-28 22:53 ` Paul Derbyshire
[not found] <Paul>
[not found] ` <Derbyshire's>
[not found] ` <message>
[not found] ` <of>
[not found] ` <"Sat,>
[not found] ` <27>
[not found] ` <Feb>
[not found] ` <1999>
[not found] ` <23:44:45>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3.0.6.32.19990302113149.009338b0@pop.globalserve.net \
--to=pderbysh@usa.net \
--cc=egcs@egcs.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).