|
I don't consider the typing to be a problem - good editors will reduce the extra typing to a minimum, and even in Notepad there's nothing preventing you from copy-pasting the extra std:: repeatedly. I do it all the time. (the copy-pasting, not using Notepad  )
P.S.: You could also use typedefs to improve readability and reduce typing effort. This can be especially helpful for containers and iterators.
modified 3-Oct-11 4:23am.
|
|
|
|
|
Stefan_Lang wrote: I don't consider the typing to be a problem
So dont use 'using' then. 
==============================
Nothing to say.
|
|
|
|
|
I personally almost never use it, simply because it clutters the global namespace. The worst abuse is to put it in a header file, and thus, polluting the global namespace in all files including that header.
I imagine though it can be useful in some situations, like when dealing with streams and manipulators. The code tends to get quite verbose if it's fully qualified. A local using namespace could be acceptable in my oppinion.
Good topic by the way.
|
|
|
|
|
Niklas Lindquist wrote: when dealing with streams and manipulators
Yes, I do find myself writing std::cout and std::endl quite a lot, but so far I've resisted the urge to add a using statement. However, you could insert a using declaration instead of a using directive for the most commonly used symbols, as pointed out at C++ FAQ.
Niklas Lindquist wrote: The code tends to get quite verbose
Are you implying this is a bad thing? I actually find that helpful. Besides, the extra typing is not actually an issue, thanks to intelligent editor tools.
|
|
|
|
|
Stefan_Lang wrote: The code tends to get quite verbose
Are you implying this is a bad thing?
In most cases, no. In some cases, yes. It does affect readability if it's too frequent. However, I have not experienced this in any other situation than when working with std streams.
|
|
|
|
|
I agree... it can affect readability...
|
|
|
|
|
Stefan_Lang wrote: Are you implying this is a bad thing?
I think it clutters the code.
Anyone puzzled by (for instance) STL error messages could share my opinion.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Ummm, I've never checked, but do error messages look different depending on whether or not you have a using directive? 
|
|
|
|
|
There's no relation, of course.
My point of view is: using std:: everywhere simply makes code look more cluttered and 'cluttered-looking' code is bad (as you may see in the 'really messy' STL error messages).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I've always thought that it's mostly the stuff that isn't also visible in the code, that makes compiler errors so hard to read, whereas the namespace symbols help separate the mangled symbols into managable bits that can be easier to understand.
Personally, when I look at unfamiliar code and try to locate a problem, seeing std:: or the like helps me exclude parts that I know I don't need to bother about. Similarly, when I try to understand what a particular piece of code does, I often start with the bits that call out 'STL' to me, because that is what I have the least trouble to grasp. In short, to me the namespace qualifiers within the code are more helpful than obstructive.
Of course, it might depend on the code you're looking at. If you're faced with types like
std::list<std::pair<MyClassA, MyClassB>, MyAllocator<std::pair<MyClassA, MyClassB> >::const_iterator
then you're in need of a typedef or two 
|
|
|
|
|
i'll use it in a .cpp unless i'm feeling particularly masochistic that day and want to type "std::" a hundred times.
|
|
|
|
|
It's worth noting that it can be used in any scope, not just globally. For example, you could use it in a function like this:
void DoStuff()
{
using namespace std;
cout << "Yeah!" << endl;
}
You can also selectively "lift" something into a namespace with a using declaration:
void DoStufff()
{
using std::cout;
using std::endl;
cout << "Yeah!" << endl;
}
Steve
modified 1-Oct-11 2:46am.
|
|
|
|
|
Hey, thanks, I actually never thought of that!
Yes, I suppose if you have some dedicated IO functions it would be quite reasonable to add a using directive in there. Good idea! 
|
|
|
|
|
There is a great article here:
Printing Class Library[^]
on how to print. I have read the article since 1999 and am hoping there are others out there
that use this class. There is this function:
pPage->PrintRotatedText(2.30,0.72,0.50,0.85,TEXT_NORMAL|TEXT_NOCLIP,9,"some text",90*10);
which will rotate the text 90 degrees. My problem is, the text is rotated and left justified
and I need it to be rotated and right justified. If I try changing the flags to TEXT_RIGHT
or TEXT_CENTER, the text still is left justified.
Any chance, any one knows how to rotate text and make it right justified. Im trying to rotate
these numbers and it looks silly having them left justified.
Please, any response any one can give me will be greatly appreciated.
Sincerely,
Danielle Brina
|
|
|
|
|
I haven't tested this, but a quick look through the source suggests that the line
m_PrtDesc.uTextFlags = flags;
is missing in the PrintRotatedText function.
If you vote me down, my score will only get lower
|
|
|
|
|
I just tried adding that code and recompiled and it still is left justified.
Any other ideas and I'll try them. Please any response any one can give me will
be greatly appreciated.
|
|
|
|
|
Good evening to all;
I have a small problem that I can not solve:
from a C program must call weka classes and accurately Apriori algorithm,
I use this syntax
system ("\" C: \ \ Program Files \ \ Weka-3-6 \ \ weka.jar \ "weka.associations.Apriori");
In this way I can just start the program and I have to do everything manually.
you tell me where the mistake?
Thank you all for the help.
|
|
|
|
|
salv03 wrote: In this way I can just start the program and I have to do everything manually.
As opposed to what?
salv03 wrote: you tell me where the mistake?
What's the problem?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
|
|
I have an application that is based on TabControl (CFormView), but for now, it appears as the dialog box that did, and I would like that it occupy the window into the framework.
How can I do it?
|
|
|
|
|
You'd call the SetWindowPos[^] member function.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
Yes I know. This is the method that resize the tabControl
[code]
void CMyTabCtrl::SetRectangle()
{
CRect tabRect, itemRect;
int nX, nY, nXc, nYc;
GetClientRect(&tabRect);
GetItemRect(0, &itemRect);
nX=itemRect.left;
nY=itemRect.bottom+1;
nXc=tabRect.right-itemRect.left-1;
nYc=tabRect.bottom-nY-1;
m_tabPages[0]->SetWindowPos(&wndTop, nX, nY, nXc, nYc, SWP_SHOWWINDOW);
for(int nCount=1; nCount < m_nNumberOfPages; nCount++){
m_tabPages[nCount]->SetWindowPos(&wndTop, nX, nY, nXc, nYc, SWP_HIDEWINDOW);
}
}
[/code]
But I dont know how to get the size of the framework. What parameter I have to change?
|
|
|
|
|
What do you mean "the size of the framework"?
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
