|
DAILY_DATA * TempNewData=new DAILY_DATA;
TempNewData=InitialList.GetAt(nStuctPos);
PriorityList.AddTail(TempNewData);
// This one is fine, because it gets put into the list, but it must be deleted in your destructor if not before (unless the MFC container does it for you ).
///+++==I am doing mistake here.Before your suggestion i am deleting the TempNewData here also.
Now i got the solution i am deleting these objects in Destructor.Once again lot of thanks you
InitialList.RemoveAt(nStuctPos);
suma k
|
|
|
|
|
Can someone tell me how to get Visual Source Safe to put header comments in my source files? Like $Revision, etc like rcs does. Thanks.
|
|
|
|
|
From the Source Safe helpfile:
Keyword expansion refers to VSS's ability to place certain information directly into your file to create a file header for you. To use this feature, you place certain keywords into the text of your file in comments so that it does not affect your code. When you add or check in the file, VSS looks for these keywords, and places the relevant information after them.
Because keyword expansion requires VSS to scan each file for keywords, it can considerably slow the Check In and Add Files commands.
Note Keyword expansion is by default disabled for all files. As VSS administrator, after you have enabled keyword expansion (from the VSS Administrator program), you must tell VSS which files to scan for keywords.
To enable keyword expansion:
On the VSS Administrator Tools menu, click Options.
Click the General tab if it isn't already selected.
In the Expand Keywords in Files of Type box, enter the types of files in which you want keyword expansion to occur; for example, *.txt.
If you use more than one extension, you must separate them with commas; for example, *.txt, *.c, *.bas.
Click OK.
Note You can also enable keyword expansion by adding Keyword_Masks = *.txt to the SRCSAFE.INI file on the server. Place it before the first occurrence of a section header, for example, [$/MyProj]. Again, if you use more than one extension, separate them with commas.
The keywords that you can expand:
$Archive: $ VSS archive file location
$Author: $ User who last changed the file
$Date: $ Date and time of last checkin
$Header: $ Logfile, Revision, Date, Author
$History: $ File history, VSS format
$JustDate: $ Date, without the time addendum.
$Log: $ File history, RCS format
$Logfile: $ Same as Archive
$Modtime: $ Date and time of last modification
$Revision: $ VSS version number
$Workfile: $ File name
$NoKeywords: $ No keyword expansion for all keywords that follow
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
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).
|
|
|
|
|