|
Then it won't compile.
Maxwell Chen
|
|
|
|
|
It won't compile if somebody that uses your class tries to use the copy constructor. So, that was the purpose of his question no ? Preventing people to copy the class. Maybe I misunderstood the question 
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
Maybe your suggestion is what he needed.
I was thinking if he was trying to seek a method which redirects copy ctor to other methods ...
Maxwell Chen
|
|
|
|
|
Maxwell Chen wrote: I was thinking if he was trying to seek a method which redirects copy ctor to other methods ...
In Other Method! 
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Cedric Moonen wrote: Maybe I misunderstood the question
I think not.
The same guy asked about the Singleton pattern a few threads down and the correct way to implement the Singleton pattern is to declare constructors, copy constructor and the assignment operator as protected or private.
A compile time error is expected if the class implemented as a singleton is used in a way it shouldn't.
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Hi !!!
If you don't define copy constructor in your class, the compiler creates one automatically. YOu cannot prevent that the compiler creates one, but you can implement one with aan empty body.
By !!!
-:KNOX:-
|
|
|
|
|
Is it mandatory to use KillTimer() if a SetTimer is used?
For example, i use
SetTimer(ID1,100,NULL). After 100milliseconds the timer expires and it is handled in the OnTimer() function. Now if i have to start a timer again with the same ID do i have to use KillTimer(ID1)?
|
|
|
|
|
It wont get expired untill you "kill" it. It keeps ticking.
Now if i have to start a timer again with the same ID do i have to use KillTimer(ID1)?
It'll overwrite the existing timer. For example, if you had set the interval as 2000, now the new SetTimer with the same ID but the interval set as 1000, it will start ticking everysecond (1000).
<marquee scrollamount="1" scrolldelay="1" direction="up" height="10" step="1">--[V]--
[My Current Status]
|
|
|
|
|
you don't have to use killtimer function to kill the timer.The statement for that function in the msdn shows that if you use an id that is existed,the old timer will be replaced.
|
|
|
|
|
|
Sure thing it is good practice, how else would you make the system free the resources allocated for this timer?
Chances are that when you replace the timer the whole thing deallocates correctly in the SetTimer API. Still better to be absolutely sure and kill the timer by hand.
The name of the function (KillTimer) sounds terrifying, but it's safe to use unlike other functions with frightening names (e.g. TerminateThread). 
|
|
|
|
|
|
Nibu thomas wrote: t's the UnderTaker...Run
What about Great Khali
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
From the docs for ::SetTimer. Holds true for CWnd::SetTimer too...
If the <code>hWnd </code>parameter is not <code>NULL </code>and the
window specified by <code>hWnd </code>already has a timer with the value
<code>nIDEvent</code>, then the existing timer is replaced by the new timer.
When <code>SetTimer </code>replaces a timer, the timer is reset. Therefore, a
message will be sent after the current time-out value elapses, but the
previously set time-out value is ignored.
Nibu thomas
Software Developer
Faqs by Michael dunn
|
|
|
|
|
nripun wrote: SetTimer(ID1,100,NULL). After 100milliseconds the timer expires and it is handled in the OnTimer() function. Now if i have to start a timer again with the same ID do i have to use KillTimer(ID1)?
iT will Good Practice if you Call KillTimer(..) before setting the TImer on same ID... but as far as any Impact on Code concern, its Negligible !
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
wil the socket created here accept only a single request,n not process the subsequent ones listened to?found an error in the accept fxn(INVALID SOCKET)...
void CCsDlg::OnAccept()
{
CString strIP;
UINT port;
port=2000;
strIP="10.1.46.36";
if(m_sListener.Accept(m_sConnected))
{
m_sConnected.GetSockName(strIP,port);
UpdateData(TRUE);
}
else
{
AfxMessageBox("Cannot Accept Connection");
}
}
****************************************************************
m_sListener.Create(2000);
if(m_sListener.Listen()==FALSE)
{
AfxMessageBox("Unable to Listen on that port,please try another port");
m_sListener.Close();
return;
}
|
|
|
|
|
Yup, your "accept" can accept only one at a time.
please see here ..
^
<marquee scrollamount="1" scrolldelay="1" direction="up" height="10" step="1">--[V]--
[My Current Status]
|
|
|
|
|
Is there any way that i can keep handling subsequent requests..coz OnAccept() does notify a listening socket that it can accept pending connection requests by calling Accept.
Not multithreading!!
|
|
|
|
|
1. Derive a Socket class from CSocket.
2. Override the OnAccept function. On Accepting the connection, call the any other function or handle it inside that function. normally we do this outside the class.
other connections will wait in the queue and will notify u again after accpetpting the first connection.
-Sarath
|
|
|
|
|
so u mean..CAsyncSocket wont work here??coz dats wat i hav used!
|
|
|
|
|
how do i make a class as singleton class.
|
|
|
|
|
class CSingleton
{
public:
static CSingleton* GetInstance();
private:
void CSingleton();
CSingleton ~CSingleton();
static CSingleton* m_pInstance;
};
In the cpp file:
CSingleton* CSingleton::m_pInstance = NULL;
.....
CSingleton* CSingleton::GetInstance()
{
if (!m_pInstance)
m_pInstance = new CSingleton;
return m_pInstance;
}
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
A simpler way:
--------------
// Console.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
using namespace std;
class Single
{
public:
static Single& GetInstance()
{
static Single s;
return s;
}
void Method() const
{
cout << "Method called : this = 0x" << hex << this << endl;
}
private:
Single()
{
cout << "Instance created!" << endl;
};
};
int main(int argc, char* argv[])
{
Single::GetInstance().Method();
Single::GetInstance().Method();
Single::GetInstance().Method();
return 0;
}
--------------
This technique leverages the langauges rules: A static member is created the first time it's encountered. This way we don't need the "new" or the "if" or to remember to "delete" it.
Steve
|
|
|
|
|
Yes, that another way of doing it. Both techniques have their pro and cons. I remember having read an article that was discussing several singleton implementations but I don't remember the link.
Yours is great when it has to be used 'alone' because as you said you don't have to worry about releasing the instance.
But in some cases, this can lead to problems: if you have a singleton that is member of another singleton, then you get into trouble because you have no control over the timings of the destruction of the instances. In such case, you need to control yourself the scope of the instances.
Cédric Moonen
Software developer
Charting control
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
