unusing a namespace or #disincluding a header?
Hattuari
available through a using directive. Correct?
I have basically the same question regarding a header file. This answer is
pretty obvious, so consider this question rhetorical. Is there no way to
remove all the symbols (or whatever the best word is) that were added
though an #include directive with a single directive?
Do people understand what I'm asking? Do you understand /why/ I'm asking? I
can't imagine such things have never been proposed or considered for C/C++.
Do you know the history of any attempts to implement such mechanisms? Do
you know where the bodies of the proponents of the design are buried?
--
p->m == (*p).m == p[0].m
John Carson
news:ofWdnRioKOC...@speakeasy.net
> AFAIK, there is no way in C++ to close a namespace that has been made
> available through a using directive. Correct?
Just enclose the directive in a block and it will cease to operate once you
exit the block.
> I have basically the same question regarding a header file. This
> answer is pretty obvious, so consider this question rhetorical. Is
> there no way to remove all the symbols (or whatever the best word is)
> that were added though an #include directive with a single directive?
If you are talking about macros, then you can undefine them with #undef. If
you are talking about identifiers, then you can manage them with namespaces.
> Do people understand what I'm asking? Do you understand /why/ I'm
> asking? I can't imagine such things have never been proposed or
> considered for C/C++. Do you know the history of any attempts to
> implement such mechanisms? Do you know where the bodies of the
> proponents of the design are buried? --
The fact that your first attempt to achieve something does not succeed is
not evidence of a deficiency in language design. It is more likely evidence
that you will have to do something in ways that are not familiar. Your
tendency to blame the language for all your newbie problems is really
getting old.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)
Hattuari
> "Hattuari" <susu...@setidava.kushan.aa> wrote in message
> news:ofWdnRioKOC...@speakeasy.net
>> AFAIK, there is no way in C++ to close a namespace that has been made
>> available through a using directive. Correct?
>
> Just enclose the directive in a block and it will cease to operate once
> you exit the block.
And if that using directive is in a library header?
>> I have basically the same question regarding a header file. This
>> answer is pretty obvious, so consider this question rhetorical. Is
>> there no way to remove all the symbols (or whatever the best word is)
>> that were added though an #include directive with a single directive?
>
> If you are talking about macros, then you can undefine them with #undef.
> If you are talking about identifiers, then you can manage them with
> namespaces.
Read what I wrote.
> The fact that your first attempt to achieve something does not succeed is
> not evidence of a deficiency in language design. It is more likely
> evidence that you will have to do something in ways that are not familiar.
> Your tendency to blame the language for all your newbie problems is really
> getting old.
I was actually thinking about the common practices which seem to go against
the principles of limited visibility. It is not always the application
programmer who introduces a using directive into the translation unit.
John Harrison
"Hattuari" <susu...@setidava.kushan.aa> wrote in message
> John Carson wrote:
>
> > "Hattuari" <susu...@setidava.kushan.aa> wrote in message
> > news:ofWdnRioKOC...@speakeasy.net
> >> AFAIK, there is no way in C++ to close a namespace that has been made
> >> available through a using directive. Correct?
> >
> > Just enclose the directive in a block and it will cease to operate once
> > you exit the block.
>
> And if that using directive is in a library header?
Putting using directive in a header file is extremely bad design for the
reasons you've alluded to.
john
Rolf Magnus
> AFAIK, there is no way in C++ to close a namespace that has been made
> available through a using directive. Correct?
Right. Don't look at it as 'closing' the namespace. Basically, a using
directive copies all the symbols from that namespace to the current
namespace. So instead of 'close' you could call it 'uncopy'.
> I have basically the same question regarding a header file.
Once the header code has been parsed, it can't just be removed again.
> This answer is pretty obvious, so consider this question rhetorical.
> Is there no way to remove all the symbols (or whatever the best word
> is) that were added though an #include directive with a single
> directive?
No.
> Do people understand what I'm asking?
I guess I do.
> Do you understand /why/ I'm asking?
No.
> I can't imagine such things have never been proposed or
> considered for C/C++. Do you know the history of any attempts to
> implement such mechanisms?
No, but that doesn't mean much.
> Do you know where the bodies of the proponents of the design are
> buried?
You might want to ask that in comp.std.c++.
Hattuari
> Hattuari wrote:
>
>> AFAIK, there is no way in C++ to close a namespace that has been made
>> available through a using directive. Correct?
>
> Right. Don't look at it as 'closing' the namespace. Basically, a using
> directive copies all the symbols from that namespace to the current
> namespace. So instead of 'close' you could call it 'uncopy'.
That can't be the whole story because not all names in the namespace are
necessarily available in the current translation unit. For example if I do
this:
#include <string>
using namespace std;
I won't be able to access anything from std that <string> didn't piggyback
in the #include, correct?
>> Do people understand what I'm asking?
>
> I guess I do.
>
>> Do you understand /why/ I'm asking?
>
> No.
I believe the transitive nature of namespaces and headers is *potentially*
messy. I'm pretty sure most experienced C/C++ users would agree. When I do
a #include I have the sense I'm opening the door for not only what I want
to let in, but also for every stray dog that happens to be in the
neighborhood.
>> Do you know where the bodies of the proponents of the design are
>> buried?
>
> You might want to ask that in comp.std.c++.
And become yet another mysteriously missing programmer? I don't think
so. ;-)
Here is some code I spun up to play with namespaces. It gives one example of
the kind of thing I don't like. Take a look at the string instance in
main.cpp:
//namespace.hpp
#include <string>
namespace NS_1 {
using std::string;
class Class_1 {
public:
Class_1(const string& message);
void print();
private:
const string m_message;
};
}
namespace NS_2 {
using std::string;
class Class_1 {
public:
Class_1(const string& message);
void print();
private:
const string m_message;
};
}
//namespace.cpp
#include <iostream>
#include "namespaces.hpp"
namespace NS_1
{
using std::string;
Class_1::Class_1(const string& message): m_message(message){};
void Class_1::print(){ std::cout << this->m_message << std::endl; }
}
namespace NS_2
{
using std::string;
Class_1::Class_1(const string& message): m_message(message){};
void Class_1::print(){ std::cout << this->m_message << std::endl; }
}
//main.cpp
#include "namespaces.hpp"
#include <iostream>
int main(int argc, char **argv)
{
NS_1::Class_1* c1 = new NS_1::Class_1("NS_1::Class_1 instance.");
c1->print();
NS_2::Class_1* c2 = new NS_2::Class_1("NS_2::Class_1 instance.");
c2->print();
//string str = "This string is free-standing."; // can't compile here
using namespace NS_1;
c1 = new Class_1("NS_1::Class_1 second instance.");
c1->print();
//This string class snuck in with NS_1
string str = "This string is free-standing."; with
std::cout << str << std::endl;
C Johnson
[snip]
I am certain that this is not the answer you are looking for but the
question you asked, well, seems only fitting:
> pretty obvious, so consider this question rhetorical. Is there no way to
> remove all the symbols (or whatever the best word is) that were added
> though an #include directive with a single directive?
It's called a comment.
#include <foo.h>
changes to
//#incude <foo.h>
And as you persistently bring this particular issue up you can even do
that a different way, e.g. wrapping them in #ifdef && #ifndef, etc.
Joking aside I am guessing that you meant declarations by the use of
"symbols". The question is do you mean only certain types of
declarations? Does it only affect function declarations? global
variables? templates? #defines? etc?
The real problem with your "rhetoric" is that you appear to be stuck
in a Java world. There is nothing wrong with that in and of itself
from my opinion but the number of post that you make trying to
{change,convert,modify} C++ seems counter productive. Rather than
continuously post as you have been I suggest that you get more
proficient by doing. As a mere example, have a look at Qt by
TrollTech. They have a Meta Object Compiler, MOC, and being that it
is open source you can peruse this and perhaps get some ideas on how
to implement some of your "ideas" by means of extending the idea
behind MOC. By the way, you do read other code for the sole purpose
of {learning,finding,seeing} new ideas, right? (Sorry, rhetorical
question)
> Do people understand what I'm asking? Do you understand /why/ I'm asking? I
> can't imagine such things have never been proposed or considered for C/C++.
> Do you know the history of any attempts to implement such mechanisms? Do
> you know where the bodies of the proponents of the design are buried?
I suggest entertaining these possible scenarios:
A) Use a different language that doesn't need such fundamental
changes to it's core. (You seem to really like Java for example)
B) Use C++, learn it, embrace it. (And extend it as needed for
*your* purposes)
C) Design and implement your own language that solves a problem you
have to deal with. (As an aside *some* of the best languages were
created under this premise and the most widely used versus "The Next
Silver Bullet Language" for the masses)
C++ is a language that supports many different programming styles and
idioms. People are different and think differently. Programmers are
people. C++ is used by programmers that are people. Accept the fact
that "my brilliant idea" for my problem could just as easily translate
to "ridiculous or just plain silly" to you or the community at large.
Does that mean I should abandon it? Realizing that my previous
statement is indeed a two way street I am not being critical of you, I
just don't understand the reasoning. "Goodness" is achieved by my
standards when a problem gets solved and I'm not "married" to it for
eternity plus a few days extra for good measure. I'm aware of the
possibility that your definition is very different. Regardless this
is the playing field in which we all participate so the rules are
clear and your options open.
Respectfully,
Chris
--
"Knowledge is knowing the street is one way. Wisdom is still looking
both directions."
Hattuari
> Hattuari <susu...@setidava.kushan.aa> wrote in message
> news:<ofWdnRioKOC...@speakeasy.net>...
Please bear in mind that some of what I say about changing the language
results from discussions with others about changing, or not changing the
language.
> The real problem with your "rhetoric" is that you appear to be stuck
> in a Java world. There is nothing wrong with that in and of itself
> from my opinion but the number of post that you make trying to
> {change,convert,modify} C++ seems counter productive.
What I was seeking by asking if anybody had proposed an alternative to the
current mechanism was to try and understand why things are as they are.
I've know about header files for well over a decade, and I understand what
they do. (for the most part) See page 82 of K&R Ansi. Also look in the
grammar of K&R and note the page where the function main() is specified.
Tell me what else you see there.
> Rather than
> continuously post as you have been I suggest that you get more
> proficient by doing. As a mere example, have a look at Qt by
> TrollTech.
Yes, I've been working with it for years. Not much coding until recently,
but I started compiling with moc in 1997.
> They have a Meta Object Compiler, MOC, and being that it
> is open source you can peruse this and perhaps get some ideas on how
> to implement some of your "ideas" by means of extending the idea
> behind MOC. By the way, you do read other code for the sole purpose
> of {learning,finding,seeing} new ideas, right? (Sorry, rhetorical
> question)
There's only so much time in a day. But yes I do. And I have been wondering
what could be done with someting like moc. But, OTOH, I find macros to be
part of the overall problem with headers and related mechanisms. I am sure
I'm not alone in that assessment. Not to knock Qt at all, they work with
what they have. Nonetheless, I am very confident that alternatives have
been suggested, and even implemented. The first time I heard about the
idea used by javap was in my 'C' programming course about the time Java was
going into alpha.
> I suggest entertaining these possible scenarios:
> A) Use a different language that doesn't need such fundamental
> changes to it's core. (You seem to really like Java for example)
> B) Use C++, learn it, embrace it. (And extend it as needed for
> *your* purposes)
> C) Design and implement your own language that solves a problem you
> have to deal with. (As an aside *some* of the best languages were
> created under this premise and the most widely used versus "The Next
> Silver Bullet Language" for the masses)
The D language is interesting, but I don't think I'll find much work with
it. Java's OK, but the apps I want to work with are written in C/C++.
> I'm aware of the
> possibility that your definition is very different. Regardless this
> is the playing field in which we all participate so the rules are
> clear and your options open.
Mathematica has a package structure that seems very similar to C++'s.
Sometimes Mathematic's behavior is so bizarre I wonder why I ever mess with
it. But the things it can do are amazing. One of my objectives in learning
to code effectively in C++ is to modify the Mathematica frontend to my
liking. That's just the way I am.
As far as my suggestions go. What I wonder is why people don't stick to the
technical issues. Instead they seem to focus on the person making the
suggestion, and quite often are clearly, and intentionally insulting.
Julie
> As far as my suggestions go. What I wonder is why people don't stick to the
> technical issues. Instead they seem to focus on the person making the
> suggestion, and quite often are clearly, and intentionally insulting.
It is easier to make unsubstantiated personal attacks than to look objectively
at an issue.
There are a few posters out there that live in a very small box, and fear
looking at an issue from a different perspective.
Leor Zolman
wrote:
>AFAIK, there is no way in C++ to close a namespace that has been made
>available through a using directive. Correct?
>
>I have basically the same question regarding a header file. This answer is
>pretty obvious, so consider this question rhetorical. Is there no way to
>remove all the symbols (or whatever the best word is) that were added
>though an #include directive with a single directive?
I'd suggest that, when you reach the point where you wish to "unuse" a
namespace or "uninclude" a header file, you simply save your file, exit
your text editor, and begin coding in a fresh source file ;-)
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Nils Petter Vaskinn
> Here is some code I spun up to play with namespaces. It gives one
> example of the kind of thing I don't like.
I disagree, It gives an example of the kind of thing you don't understand.
It gives one example of how failure to understand a language feature can
lead to bad coding practice.
Before you critique something make sure you understand how it works, what
it was made to do, how you are supposed to use it, and what happens when
you use it in a different way.
> Take a look at the string instance in main.cpp:
>
> //namespace.hpp
> #include <string>
> namespace NS_1 {
> using std::string;
This is the reason that the people maintaining your program will want you
hung from the nearest tree. If you avoid using "using" in a header file
your problem will go away.
Rule of thumb: Don't use "using" in headers, write full classnames with
namespaces instead (unless you're inside the namespace in question).
/* It's kinda like the two tules of goto. 1. Don't use it. 2. Know when to
break rule 1 */
C++ is not a baby sitter, it will allow you to do things that may be a bad
idea. Sometimes you conciously make the decision to do that, knowing the
price and what you gain by breaking the rule, and C++ can't tell the
difference so at best a compiler may choose to warn you.
--
NPV
"the large print giveth, and the small print taketh away"
Tom Waits - Step right up