|
I've heard many people say that using "using namespace std" in your programs is a bad idea. I see it in all the books I read through though .. I assume it's just because they're examples though.
I'm going to assume the reasoning is that you don't want to include anything your not going to be using .. and possible conflictions with other functions???
I've started to change all my code from:
using namespace std;
to:
using std::vector;
using std::deque;
using std::cout;
...
I am finding that the list of using ... get's quite long, hehe. But is this the right way to go? Or is it simply better to just use "using namespace std"
Travis D. Mathison ---
--- After three days without programming, life becomes meaningless ...
|
|
|
|
|
I don't use using at all. That way you know where each and every function comes from. Otherwise they're just global functions.
Consider when you use a C++ object it's usually object.method() or object->method() and not "declare some global and then call method()".
Todd Smith
CPUA 0x007 ... shaken not stirred
|
|
|
|
|
If you want to use them, go right ahead.
However, there are some cases where I wouldn't use them at ALL. Never ever ever ever ever. (Atleast in the global scope)
If you are creating a library to be used by others, NEVER expect that there has been a using issued. Never issue one yourself (excluding the rare case where you are adding namespaces to an existing library where you don't want to break existing code). Always reference the classes fully (i.e. std::vector).
The idea is that your library should never have any side effects during compilation. Issuing a using might cause other strange problems not expected by the user of your class library.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Ok, thank you both for the insight.. perhaps I shall consider using the full std::<whatever> in my code instead of "using blah".
Travis D. Mathison ---
--- After three days without programming, life becomes meaningless ...
|
|
|
|
|
That's why we use typedef's a lot (to save some keystrokes I guess?). For example:
typedef std::list<MyItem> CMyList;
Is this also an evil then?
|
|
|
|
|
This is also evil, because it makes your code illegible to people who don't have your typedefs commited to memory.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
That is why I name my typedefs consistently and 99% of the time inside a class.
typedef std::vector <CSomeClass> _vSomeClass;
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive.
My personal opinion is that it is better for people to become accustomed to reading the only syntax that is never ambiguous. Most typedefs I've seen have used the vec/lst/map type prefixes, but created types like this
mpi2v
mpsz2w
veci1
veci2
This stuff is just a nightmare. I agree that poor use of a language feature does not dismiss the feature entirely, and in writing STL docs for work I put forward typedef as an issue for personal preference, but also explained why my preference is to avoid it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
This is fine as far as it goes, although IMO it adds a level of abstraction that is unnecessary (i.e. I still need to translate this on the fly as I read the document, although what you've shown is quite intuitive.
Which is the exact reasons I don't some of the more basic STL functions such as for_each. Let's just say I disagree with Scott Meyers on every point. Even he admits functions such as for_each can obscure code.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Tim Smith wrote:
Let's just say I disagree with Scott Meyers on every point.
On *every* point ? I believe he advocates the typedef's we are discussing, actually.
Tim Smith wrote:
Which is the exact reasons I don't some of the more basic STL functions such as for_each.
I don't think for_each obscures code to the degree that typedefs do, and in both cases it obscures it for people other than the author.
Personally I don't use for_each that much either, I think the main reason I've used it is to delete pointers in my destructor. It is also true that my use of STL has not needed too many algorithms.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
That's why I always believe that if a programmer cannot write a decent for loop him/herself s/he shouldn't be programming at all...
|
|
|
|
|
execuseme, I'm not good speak english.
I have one problem in WinCE..
I don't send document or text to printer in Embedded MFC .
I want send japan's and arabic character to IrDA printer..
please help me..
my mail adress: mgencer99@hotmail.com
MFC
MFC
|
|
|
|
|
does anyone know why this linking error is happening:
error LNK2005: "public: __thiscall CMove::CMove(int &,int &)" (??0CMove@@QAE@AAH0@Z) already defined in Computer.obj
i have define my inclusion guards and everything but this error still keeps coming up. can anyone tell me wats the cause of this linking error...  well, anyways, thank for you help 
john
|
|
|
|
|
Make it inline
inline CMove::CMove(int&, int& )
{
}
|
|
|
|
|
CMove::CMove must be defined in your code twice. The error suggests that it is in Computer.cpp and and in another file.
Where is the CMove constructor body, is it in Computer.cpp?
If you are certain it isn't defined twice, try doing a rebuild all.
Michael
|
|
|
|
|
Guys
As a few of you might be aware of, I am trying ATL out.
Say I have a function like this :-
STDMETHODIMP CIniEdit::TestMethod(BSTR *pbstr)
{
OLECHAR tmpString[512];
wcscpy(tmpString,L"Nish is learning ATL");
*pbstr=SysAllocString(tmpString);
return S_OK;
}
and from ASP or VB say, I do this :-
Dim x
Set x = CreateObject("SIMPLE.SimpleStuff")
MsgBox x.TestMethod()
Set x = Nothing
You'd think, all was fine. But to my utmost horror I suddenly realized that I had happily allocated a string using SysAllocString, but I am not calling SysFreeString.
Horror of horrors!!!!
What is the work-around to this, dear friends?
Am I doomed to be stuck among the ultimate dangers of memory leaks?
Writing another function just to free the string seems pathetic. And I am sure that from ASP/VB this function might be called several times, thus resulting in a memory leak, each single time
Nish 
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
An out parameter should not be assumed to contain anything valid and should be initialised before use ( for exmaple, set pointers to NULL). Responsiblity for freeing the memory belongs to the calling function. All of this is laid out in COM, and I believe there are special functions for allocating the memory and freeing it as well, but I forget them ( I'm a beginner at this, too ).
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
Nish [BusterBoy] wrote:
Am I doomed to be stuck among the ultimate dangers of memory leaks?
No,It's ok Nish.
In COM, it is the client's responsibility to free resources allocated by a server at a client's request.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Mazdak wrote:
In COM, it is the client's responsibility to free resources allocated by a server at a client's request.
oh?
But how can I free resources using VB or ASP???
They dont have a delete operator/function
Nish
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
Nish [BusterBoy] wrote:
how can I free resources using VB or ASP???
I don't know about VB or ASP,but when I use C++ or MFC as clients I use SysFreeStrnig() for those BSTR.
And After all I use Release() for my component before CoUninitialize() so if those things exist in VB or ASP,I think the operation of FREEDOM happend in Release().
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Just another hint Nish:
If you use _bstr_t you'll get rid of those allocated and deallocated hell,but you don't have BSTR* .It isn't provided in _bstr_t.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
You don't need to free it, the scripting engine automatically frees it for you by calling SysFreeString (actually it calls VariantFree. That's why you use SysAllocString and not the operator new in C++.
Here is what happens from scripting engine point of view
1. Gets IDispatch interface to your object
2. Calls GetIDsOfNames to get ID of "TestMethod"
3. Calls Invoke method with that ID
4. The return value comes in pvarResult
5. Calls VariantFree to pvarResult after MsgBox function is called
6. VariantFree checks for the type of the Variant and sess that it is a BSTR and calls SysFreeString
That's the reason why you use BSTR because you have standard functions for allocating and deallocating which are known by both you and the consumer (script engine).
|
|
|
|
|
Thanks 
Nish
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
|
OLE automation uses only VARIANT data types. So any parameters, which are passed between your server and VB, ASP, scripting engines, or any client, which use ole automation should be VARIANT compatible. The VB runtime will simply free the resources by calling VariantClear or some similar mechanism when the resource will go out of scope.
|
|
|
|
|
solon wrote:
The VB runtime will simply free the resources by calling VariantClear or some similar mechanism when the resource will go out of scope.
Cool
And thanks too
Nish
It's seven o'clock
On the dot
I'm in my drop top
Cruisin' the streets - Oh yeah
I got a real pretty, pretty little thing that's waiting for me
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
