From -3226003361243490789 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e5c2db50725662d X-Google-Attributes: gidf78e5,public From: "Kit Smithers" Subject: Re: Problem with using typedef in a namespace Date: 1999/05/13 Message-ID: <926546143.23350.0.nnrp-12.9e98df50@news.demon.co.uk>#1/1 X-Deja-AN: 477547307 Approved: Valentin Bonnard References: <925941289.21893.0.nnrp-01.9e98df50@news.demon.co.uk> X-Original-Date: Wed, 12 May 1999 22:57:46 +0100 Organization: - X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUANzs0iawEuYhIxRhxAQHIjgH/UHCh7nYUEfj1CNUFslKdAbK+jgMWNXnV JaRKkvwF6MkRpO79vDBVYJt1t3b+wIKMxGaLwrOnK4zXodGpvSRx4g== =I3VR X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Newsgroups: comp.std.c++ Joerg Barfurth wrote in message <37321825.7EFA9645@vossnet.de>... > >Kit Smithers wrote: >> >> I'm having trouble understanding why the following code produces different >> results. (snipped code showing typedef producing correct but for me surprising results when used in a namespace) >In namespace ABC (and thereby in myFunc) both operators from namespace CSS >can't be found by unqualified name lookup, nor are they explicitly qualified >in your code (you can't write gstream CSS::<< mystring anyways). So if any of >them can still be found, it has to be by argument dependent (or 'Koenig') name >lookup. Basically this means that, in addition to the local scope, the >namespaces where the arguments' types are defined are also searched for >matching 'candidate' function declarations. >This is covered in the standard in section 4.3.2 [basic.lookup.koenig]. In >paragraph 2 it reads: >"For each argument type T in the function call, there is a set of zero or more >associated namespaces [...] to be considered. The set of namespaces [...] is >determined entirely by the types of the function arguments (...). TYPEDEF >NAMES [...] DO NOT CONTIBUTE TO THIS SET." (emphasis added by me). >This is in accordance with the semantics of typedef mentioned above (referring >to 7.1.3). Thanks for the explanation. A number of people have pointed me towards the argument dependent lookup rules and I know have a better understanding of what I did wrong. My thanks to all of them. My followup really relates to the problems that I feel exist with the typedef keyword. I find that the resulting actions of doing a typedef dont allow for the kind of flexibility that I would like. In this case I would like to effectively produce a new "type" that is the same as another one but to behave as if I had defined it myself. Another example of why I find this troublesome is that you cant make a forward declaration for something that is typedef'd eg. // header file with forward declaration of MyClass class MyClass; // header file for MyClass which is actually typdef'd to MyOtherClass class MyOtherClass {}; typedef MyOtherClass MyClass; would cause the second header file to fail to compile (if preceeded by the first) because I've previously declared MyClass as a class. I can easily change the forward declaration header file to work. And why do I want to do this? The reason is that I want to make use of a 3rd party library within the library that I am building but I dont want to make users of my library aware of this other library. Sometimes I just want them to see my names (in my namespace) for the types in order to give me the option at a later date of replacing the class with one of my own. I dont want to wrap up the 3rd party class in all cases because of the work involved - ideally I would do that but there are time constraints on producing the work. Anyway to finally get to my point. I feel that the standard doesnt provide a suitable way of allowing you to create "copies" of other types. The typedef provides a form of naming alias which doesnt seem much better than doing a #define. Conversely I suppose that the problem extends in the other way where sometimes you want to make copies of types that arent "the same" eg: typedef int Altitude; typedef int Speed; which would allow you to assign a Speed to Altitude with the potential for disaster that could cause. I'm aware of how to get around the problem above but I cant help feeling that once again I'm being let down by the typedef keyword. -- Kit Smithers --- [ 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 ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]