|
One way:
double d1 = 5.1;
double *p1 = &d1; Another:
double *p1 = new double;
*p1 = 1.8;
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Thx
I am using VC++, any easier class in MFC? The way you used seemed like C.
|
|
|
|
|
jw81 wrote:
any easier class in MFC?
What I provided was not easy?
Are you sure that you understand what you are asking? A pointer in C is the same pointer in C++. Encapsulating a simple pointer into a C++ class is unnecessary.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
My mistake, I was thinking abt linked list. Sorry abt the confusion. Does VC++ linked list same as C?
Thanks.
|
|
|
|
|
yes; all C constructs are C++ compatible.
but I would suggest using either MFC collections or STL collections
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Thanks Maximilien,
This is the actual question I am asking, could you suggest any MFC function that I can use for such case (linked list)? There are quite a lot of solution from MFC but I dont know which one is the best. If it is too difficult to show here could you post any url related to such case? Thanks.
|
|
|
|
|
jw81 wrote:
I can use for such case (linked list)?
Look for Collection Classes in MSDN. Some of them are
or In STL
"I Think this Will Help"
Alok Gupta visit me at http://www.thisisalok.tk
|
|
|
|
|
store where and how ?
double* d1;
double* d2;
d1 = new double;
*d1 = 0.4;
d2 = new double;
*d2 = 0.3;
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Here is the
Screen Shot
The problem is that background is not solid, it has gradient so I can't erase background of my controls with solid rectrangle as defauld controls do.
(The code you've posted before also seems to be filling only solid rectangle)
rrrado
|
|
|
|
|
Then the solution is to forward the WM_ERASEBKGND message of a control to the wnd proc of the parent dialog that is responsible for drawing a gradient background. Before passing a DC handle, set the viewport origin to match the control position in the dialog.
Another problem with group boxes is correct painting of contained sibling controls. If this problem will arise, try this :
void myGroupBox::PreSubclassWindow()
{
ASSERT(::GetWindowLong(::GetParent(m_hWnd), GWL_STYLE) & WS_CLIPCHILDREN);
ASSERT((::GetWindowLong(m_hWnd, GWL_STYLE) & BS_TYPEMASK) == BS_GROUPBOX);
ModifyStyle(0, WS_CLIPSIBLINGS);
SetWindowPos(&CWnd::wndBottom, 0,0,0,0, SWP_NOSIZE|SWP_NOMOVE);
CButton::PreSubclassWindow();
}
Group boxes are a common headache for all programmers. The simplest solution is to avoid gradient background and make it just lighter than common COLOR_BTNFACE , 75 percent - that will do and look neat.
One always gets the deserved.
http://www.silveragesoftware.com/hffr.html Update your source code with my tool HandyFile Find And Replace!
|
|
|
|
|
Thank you very much for your help, but finally I've found the easiest solution, without owner drawing nor any message handling, it seems that
all I need to use this function on my dialog in OnInitDialog():
EnableThemeDialogTexture()
rrrado
|
|
|
|
|
WOW !!!! in fact I have to thank You!!! I always used to invent a wheel for my dialogs in respect to they look, and never thought there's a function like this!!!
One always gets the deserved.
http://www.silveragesoftware.com/hffr.html Update your source code with my tool HandyFile Find And Replace!
|
|
|
|
|
I have a critical section that enables thread-safe reading from / writing to a CMapStringToString object.
The CMapStringToString could possibly grow in size to have around 200000 entries, where the 'key' is a string of <=6 characters, and the value will, on average, be around 300 characters.
Firstly, does anyone know how much memory a CMapStringToString object with 200000 entries with keys 6 characters long and values 300 characters long will actually use?
Secondly, when I call the Map's Lookup() function, will this start to take a long time to return if my map grows to this kind of size? Would this slowing down make it unsuitable to use inside a critical section which is probably being accessed by a different thread eg. 4 times per second?
Thanks for any thoughts anyone might have,
Matt
|
|
|
|
|
Firstly, you should set your initial block size to a large number to create more hash buckets, thereby separating your strings into smaller sets and decreasing the search time.
If you need to access this many elements so frequently via multiple threads, I would suggest that you create a higher level hash table (of smaller size) that would contain locks (critical sections) and pointers to individual sections (hash tables) of the entire data set. By doing this, you will get higher concurrency at the cost of more memory usage. This way, you would lock only a section of the set that you were interested in, rather than the entire set.
onwards and upwards...
|
|
|
|
|
I have a couple of questions about using the CCriticalSection class. Firstly, is there any difference between the way the critical section works by using it in the following two manners:
1)
CCriticalSection blocker;
blocker.Lock();
// Do something
blocker.Unlock();
2)
CCriticalSection blocker;
CSingleLock singleLock(&blocker);
singleLock.Lock();
// Do something
singleLock.Unlock();
Also, am I correct in saying that using either of these methods, no thread will time-out when waiting for the critical section to become free - they will just wait until it's they're turn to use the code?
Any comments would be much appreciated,
Thanks,
Matt
|
|
|
|
|
Hi Matt
The CCriticalSection class is the lock that is accessed from more than 1 thread and ensures that if 1 thread has called CCriticalSection::Lock (not having called CCriticalSection::Unlock yet), another thread's call to CCriticalSection::Lock will block - effectively suspending the second thread until the first calls CCriticalSection::Unlock.
The CSingleLock class is simply a smart-pointer style helper class that acts on the CSyncObject that is passed in with it's constructor - in essence, it just calls the CSyncObject::Lock in it's constructor and CSyncObject::Unlock in the destructor. That way you can have the SyncObject's Unlock method automatically called when the CSingleLock local variable goes out-of-scope....
but an example says a thousand words;
CCriticalSection csGlobal; // global variable, or such..
void Thread1()
{
CSingleLock lock(&csGlobal);
// do stuff
}
void Thread2()
{
CSingleLock lock(&csGlobal);
// do stuff
}
So you can see that the smart-pointer style local CSingleLock instances really just capitalise on the C++ destructor to help you remember to call csGlobal.Unlock. Without the CSingleLock, you could end up writing (faulty) code like this;
void Thread3()
{
csGlobal.Lock();
// do some stuff
if (bFailed)
return; // !!!! didn't call csGlobal.Unlock();
// do more stuff
csGlobal.Unlock();
}
Lastly, the explicit Lock/Unlock methods on CSingleLock is really if you can't wait for the destructor, and need to Unlock and possibly Lock again.
I hope this makes sense.
Martin
|
|
|
|
|
If I use a class which has 10 methods and 10 attributes, but I only access/use 5 methods and 5 attributes from that class in my program, will the resultant executable also include code/data for the other 5 methods and attributes ?
I suppose I'm asking if the linker is clever enough to discard unused functions and data.
PS. I'm using Visual C++ 6.
|
|
|
|
|
At one point in time very long ago, I seem to remember that the linker would remove unused code from EXEs but not from DLLs. How it works today is unknown to me. Is this causing an issue with you?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
It's not a big problem. I'm new to C++ having come from a C background. With the availablility of all the classes on CodeProject (and other sites), it's easy to just drop in classes to facilitate easier programming. However, if I only use a small fraction of the functions in the different classes, then I'm thinking that my application will end up being unnecessarily bloated with code that never gets executed and data members that never get accessed.
I suppose can test it easily enough by creating a test app and then seeing if the code size is larger or the same size when I access more class member functions/variables. I was just curious if anyone knew and had a bit more info on how it works.
|
|
|
|
|
With the exception of a few isolated cases (e.g., EPROM with KBytes of RAM), this exercise would be a complete waste of time with little to no benefit/payback. Most of the time, this "smaller is better" idea is fostered by incorrectly-interpreted information. What you should be concentrating on is how big the program's data is.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
|
HI!!!
i'm doing my Msc... and want to do a project.. develop any application in MFC/C++... can you please suggest some good topics.. for the project - THANKS! -V.G
|
|
|
|
|
any particular personal interest ?
does it have to be in any particual field ? graphics, database, computational, multimedia, web-related ?
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
hi!! sorry for being so late.. actually i'm just a beginer..but the project has to be good.. can u suggest any good project for beginners...we r a teamof five.
|
|
|
|
|
How can you be a beginner if you are doing your Msc (I assume this is a computer-related Master's degree)?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|