|
thank you John,
bathList->Apply(SimpleThread) actually works !!
I did what I did to try to follow the signature and didn't even notice that the argument (Thread *) itself is illegal at all. I think template instantiation takes care of that by induction, and since "SimpleThread" is already a void function, so no need to re-cast (void) again ?
Am I heading the right direction ?
Thanks again.
James
|
|
|
|
|
Your welcome and yes.
void (*Func)() // is a user defined function pointer type named 'Func'
The only difference between it and a biult in type like 'double' is that it is user defined. If you can not pass 'double' as an argument, then you can not pass 'void (*Func)()' as an argument; besides it makes no since (once you realize it is a variable type and not a variable).
That was just some food for thought!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Does that mean you have tried
void<br />
SynchList::Apply(void (_cdecl *func)(T))
and it does not work!?
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
No, did not need to, but I have now:
int foo(int n)
{
return n + 1;
}
int foo2(int (*Func)(int))
{
return Func(1);
}
int foo3()
{
return foo2(foo);
}
int foo4()
{
return foo2(int (__cdecl *foo)(int));
}
int WINAPI foo5()
{
return 1;
}
int foo6(int (*Func)())
{
return Func();
}
int foo7()
{
return foo6(foo5);
}
int foo8(int (WINAPI *Func)())
{
return Func();
}
int foo9()
{
return foo8(foo5);
}
Sorry about that, the compiler assumes __cdecl calling convension.
Got to go! Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
This is John again, visiting from customer sight.
Sorry misslead you a little bit:
// Errors: Argument is a TYPE not a function pointer
return foo2(int (__cdecl *foo)(int));
Example:
int fun1(int n) { return n+1; }
int fun2()
{
return func1(int);
}
|
|
|
|
|
caption font of dialog on XP is larger than font on other OS (i.e. win98).
caption text can be displayed properly on win98 but only part of text can be displayed on XP (too long).
can we change caption font for XP so it becomes the same as on win98?
thx
includeh10
|
|
|
|
|
if you want a 2k looks you can do it somewhere in display properties.
-prakash
|
|
|
|
|
I think
you can change Theames
-----------------------------
"I Think this Will Help"
-----------------------------
Alok Gupta
visit me at http://www.thisisalok.tk
|
|
|
|
|
just like in subject... i need some method for determining full path of application. what i want to achieve is to create ini file in the same folder as application but method which creates file requires full path.
thx in advance
|
|
|
|
|
Take a look at
GetModuleFileName()
Hope that helps
Karl - WK5M
PP-ASEL-IA (N43CS)
<kmedcalf@ev1.net>
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
Remember to strip-off the filename from the end of the string returned from GetModuleFileName()
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
perhaps i should have added a word "simple" to word "method" .
GetModuleFileName returns DWORD, requires some strange parameters . i'll try to figure something out but i was looking for something analogical to AfxGetAppName() which returns LPCTSTR and is easy in use (doesn't need any parameters)
|
|
|
|
|
OK, just to help you out as it is my last day at work for the year!
Here is a function that will do the job for you. Yea, I know it is global but you can take the contents and wrap them in a class function if you like!
inline CString GetModuleLoadPath()
{
int Idx;
TCHAR ModName[_MAX_PATH];
if( !::GetModuleFileName(NULL,ModName,sizeof(ModName)) )
{
ASSERT(false);
return CString(_T(""));
}
CString LoadPath(ModName);
Idx = LoadPath.ReverseFind(_T('\\'));
if( Idx == -1 )
{
ASSERT(false);
return CString(_T(""));
}
LoadPath = LoadPath.Mid(0,Idx+1);
return LoadPath;
}
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
thanks a lot. it'd take me 2 hours to figure it out :].
if it's your last day... merry christmas and a happy new year
|
|
|
|
|
You could also use PathRemoveFileSpec() after a call to GetModuleFileName() . This will remove the filename from the path.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
can anyone cite me the differnces between a dll and a lib file??
|
|
|
|
|
The code inside the lib file is loaded during compile time and is 'added' inside your executable so, after compilation, you don't need to send the lib file with your executable.
With a dll, the code is loaded at run-time from the dll so you need to send the dll also with your executable.
[edit] Sorry: lib files are loaded at linkage, not at compile time of course... (writing too fast ) [\edit]
|
|
|
|
|
DLL can be loaded and used in program at run time ....
LIB is used while linking; linker will add used parts of LIB into your exe file statically
rrrado
|
|
|
|
|
Every one is correct!
What they did not say is important:
In the passed if you linked in a normal .LIB file, then you had linked in every function that was contained in that file, whether you used them are not. I do not know if that is still the case, but it resulted in programs that where much larger than required to do the job, since most of the function linked in where not used. Plus the fact that every program had there own version of the same function code.
If the same functions from the same library are used in several programs, then you should use a .DLL. That way all the programs can share the same code: This reduce the size of the individule programs and reduces the amount of disk space require to store the programs and libraries they depend on. It also reduces the amount of memory required to load your program.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
John R. Shaw wrote:
In the passed if you linked in a normal .LIB file, then you had linked in every function that was contained in that file, whether you used them are not. I do not know if that is still the case, but it resulted in programs that where much larger than required
you know, if you have a good compiler, it conserves only the functions that are actually called. that is the same case when you make much #include s, with many functions included that you will never use...
TOXCCT >>> GEII power [toxcct][VisualCalc]
|
|
|
|
|
Note: "In the passed..."
Note: "I do not know if that is still the case...", because I have not checked.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Visual C++ 6.0 seems to have the boundary at the OBJ level.
One OBJ is made for each C or C++ file.
If you make a LIB file from one source file and it has dozens of functions in it, anything linking with the LIB gets all the functions. If you put all those functions into separate source files, you end up with many OBJ files, and link them into a single LIB. Only the functions directly called and their dependcencies are embedded within the resulting EXE file.
A classic 'library' will be designed so that functional dependencies are grouped by source file so your EXE size would be reduced. With the larger memory (virtual or not) footprints available on PC today, this does not seem to be such an issue any more.
I am not sure what the consequence of inlined functions in a header file are, probably only included as used, but EVERY one of them is repeated each time it is used, such is the reasoning for 'inline' - you are avoiding the function call!
|
|
|
|
|
My VC++6.0 project can be compiled in debug mode (MFC in shared DLL) without problems. But I have a problem to compile in Release mode (MFC linked statically). When I build the project after the Clean, there is no problem. But when I hit compile or execute button again, it shows the dialog with all the project's files saying they were changed and it must be rebuilt again.
When I confirm this, all files will show me this error:
fatal error C1852: 'Release/aaa.pch' is not a valid precompiled header file
in the #include "stdafx.h" line.
I've added some files to project manually, but I've turned off precompiled headers for these files individually.
What can be the problem ? Again debug build is running without problems ...
Thank you !
rrrado
|
|
|
|
|
Have you tried a clean release build, i.e. clean the project and rebuild all.
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
Yes, when I clean the project, first build is done without problems.
But the next build is giving me the errors.
I must always clean whole project when I want to build it and it takes a long time since it's quite big project
rrrado
|
|
|
|