🚀 go-pugleaf

In article <4k7c9s$t5e@mule1.mindspring.com> abell@mindspring.com
(Andrew Bell) writes:

|> jbuck@Synopsys.COM (Joe Buck) wrote:
|>  >abell@mindspring.com (Andrew Bell) writes:
|> >>The problem is the compiler needs to know the "purity" of the
|> >>functions a given function calls during its compilation, or it can't
|> >>optimize the code.  You would thus have to compile all the called
|> >>functions first,

|> >No, you wouldn't. 

|> Tsk, tsk, Joe, you misidentified someone else's statements as Jason's,
|> and then edited out the part I was responding to, thus making it look
|> like I was responding to something I wasn't.  I was responding to
|> Jason's comment that "pure" and "clean" as modifiers weren't necessary
|> with a slightly smarter compiler.  My response was that in that case,
|> all the code would have to be precompiled for purity/cleanliness,
|> before anything could be compiled, a statement I still stand by.

Concerning the qualification of `pure': I had considered a pragma for C
to this effect back when I was doing compiler work (late 80's).  In the
end, if I remember right, I decided that it wouldn't work, because most
of the functions you would want to label `pure' in fact aren't.  For
example, most of the mathematical functions (which was the main interest
at the time) aren't pure, because they may modify the global variable
`errno'.

I still think that the pragma idea has merit.  There are functions (like
exp or sqrt) that you want to the compiler to treat as pure, even though
they are not pure according to the strict rules.

|> >>With the proposed idea, a function that claims to pure and isn't would
|> >>be tagged with a compiler error.  This might be problematic with
|> >>templates, as instantiation for a particular type may lead to non-pure
|> >>functions being called.

|> >Replace "pure" with "const".  It's no different.

|> In that case, pure would have to be part of the function
|> prototype(specification? Not sure if I'm using the right term here),
|> which would increase its impact on the language specification.  It
|> also means you could conceivably have both pure and impure (*) and
|> clean and unclean versions of the same function, though you could
|> restrict it to not allow this.  

To have both versions, you would have to have a criteria in order for
the compiler to select one or the other.  In this case, having both
would imply that any call to the function was, by definition, ambiguous.
So it is implicitly forbidden.  (Note that const/non-const is only valid
for member functions.)

|> I suspect the standardization committee might be reluctant to make
|> such a change just for optimization reasons (especially at this
|> point), but maybe there will be a C++ '98 or some such.  (Gotta be,
|> for my wrappers proposal! :-)

I am 99.9% certain that such a proposal will not be considered for the
current round of standardization.  It really is too late.  So it won't
make it into C++ '98.  (The year normally refers to the year in which
the standard is formally adapted.  so C++ '98 is about the earliest
possible for this round.)  How about C++ '05?
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]