🚀 go-pugleaf

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.

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

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! :-)

Andrew Bell
abell@mindspring.com

* Although impure functions might be illegal in functions that might
be used by children because of the Exon Amendment....
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]