From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9ce095aba33fe8d0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!sumatra.thomas-huehn.de!news.uni-stuttgart.de!news.belwue.de!irazu.switch.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!cern.ch!news From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Negative float problem Date: Fri, 28 Oct 2005 10:34:03 +0200 Organization: CERN - European Laboratory for Particle Physics Message-ID: References: <1130351574.313991.229420@g14g2000cwa.googlegroups.com> NNTP-Posting-Host: abpc10883.cern.ch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sunnews.cern.ch 1130488442 1802 (None) 137.138.37.241 X-Complaints-To: news@sunnews.cern.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Red Hat/1.7.12-1.1.3.2.SL3 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:6025 Date: 2005-10-28T10:34:03+02:00 List-Id: Robert A Duff wrote: >>What about Argument-Dependent Lookup (C++ has it)? > > What's ADL? I'm reasonably fluent in C++, but I don't know that term. Which means that the feature is well designed. ;-) > Also, can you give an example? Sure. #include int main() { std::cout << "Hello!\n"; } Above, iostream was #included, but there is no "using namespace std;" in the code. The result is that you have to qualify cout (so that you have to write std::cout), but at the same time you don't have to qualify the operator<<, even though it is also defined in namespace std and is otherwise *not* directly visible. Basically, the function (and operator) names are *additionally* looked up in those namespaces where their parameters are declared. This is usefull for operators like above (and certainly applies to the original Ada problem in this thread), but can also help with normal functions. Without this feature, you would have to write: std::operator<<(std::cout, "Hello\n"); which obviously is not what is wanted. > It's not particularly an issue of how smart the compiler is. > Certainly, if the rules were as you suggest, compilers could > implement them just as easily as the current rules. In fact, > the rules you suggest are equivalent to always having a use clause, > if I understand what you mean. No, it is not like this. It is an extension of the lookup mechanism, not the implicit use clause. > As to "why not other operations as well?" -- I think it's reasonable to > require a use clause to get them. If you allow ADL for operators, it is reasonable to allow it for all functions and procedures. There is no point in complicating rules and creating further special cases. > And in many cases, it's useful to > avoid the use clause, and use Package_Name.Procedure_Name notation, > because that allows the reader to understand where Procedure_Name > comes from. Absolutely. ADL is *not* an implicit use clause and is used in those places, where it significantly helps rather than obscuring the code. And nobody prevents you from writing fully qualified names even when it is not necessary, but you find it to improve the readability of the code. > Note that in C++, you will generally be referring to an object name as a > prefix, which somewhat mimics the Ada "Package_Name." idea. Note that in C++ there are also free functions, which use objects as their arguments (in fact, the operator<< for ostream falls into this category). This is exactly where ADL is supposed to help (and it cannot be used anywhere else for that matter, so it does not kick in where it's not wanted). >>I'm really surprised that the code posted at the beginning of this >>thread does not compile. > > Many people are. So - why not having ADL in Ada? :) -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/