|
My pleasure 
It's seems you have some troubles with keys staying blocked on your keyboard, or a funny accent 
Angels banished from heaven have no choice but to become demons
Cowboy Bebop
|
|
|
|
|
but i think it's obvious that it's coz of my Bad English not Accent 
thanks any way 
|
|
|
|
|
|
so i wanted to use a dll for certain functions in my app so that i could update that part without changing the rest and at the same time not make the main app bigger than it had to be by not requiring the dll stuff unless someone wanted that functionality
now it seems if i want dialog boxes in the dll i have to link it with mfc and as im using a static linked mfc in the main app to make the install easier for the end users it would make sense to use a statis link in the dll for the same reason
errrrr then i get 2 copies of mfc and a huge download???
does this mean i have to dynamically link with mfc for both parts of the app to achieve what i want? kinda silly if u ask me or maybe im missing something here?
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
lauren wrote:
then i get 2 copies of mfc and a huge download???
Well, technically you're not gonna get 2 copies of all the MFC classes inside the app and dll. Each one is only get what it uses from MFC. So yes, there will be duplication of MFC code in each one but it won't be all the MFC code.
I'd recommend dynamically linking with MFC for the app and DLLs, so that the MFC stuff is shared. Just make sure to install the MFC DLLs in the same folder as the app and DLL, and you shouldn't have any versioning problems.
Another alternative is to dump the whole separate DLL idea and just make the app bigger. After all, who cares? It's either ship one bigger app or a slightly bigger app plus a DLL.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Alvaro Mendez wrote:
Another alternative is to dump the whole separate DLL idea
thats what i kinda figured too
sheesh i loved the days when u could do code overlays
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
Switch to .NET lauren, it's easier over here... 
I don't know whether it's just the light but I swear the database server gives me dirty looks everytime I wander past.
-Chris Maunder
Microsoft has reinvented the wheel, this time they made it round.
-Peterchen on VS.NET
|
|
|
|
|
Depending on what you're doing in the DLL, you might be able to avoid using MFC in it at all - this is more work for the GUI stuff, but if you don't have too much of that it might be a solution.
Or just dynamically link. This week's poll aside, it usually causes only minor support headaches and hair-pulling, especially if you're careful to use the latest versions of MFC and do *lots* of testing...
---
Shog9
The siren sings a lonely song - of all the wants and hungers
The lust of love a brute desire - the ledge of life goes under
|
|
|
|
|
Hi!
How can I write processor specific code, like SSE/SSE2??
--------
Dave
|
|
|
|
|
either use asm code
or get a compiler that supports it
afaik
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
any resoures?
--------
Dave
|
|
|
|
|
sheesh i havnt done asm coding in a while now so i dont have any sites off hand but there are loads of them
u can either do inline asm in vc++ i think or get masm (which is a free dnload from ms i think)
how to do chip specific stuff? get the data sheets from the chip makers and plow thru it
hope this helps
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
OK .. I have VC.NET,
I'm working on a CAS system and I'm writing a runtime compiler. It's working fine with standard routines, but I was thinking of implementing SSE routines. But I dunno how...
--------
Dave
|
|
|
|
|
I think that the new Visual C++ 2003 should support some options for allowing the SSE/SSE2 instruction set. But I have it only from marketing blabla on Microsoft's site...
|
|
|
|
|
I took over development of a project that is a client/server design. When an order is accepted on the server an exception is thrown. This exception only happens in a release build and unfortunately has a vague message box saying "The server through an exception". How does one nail down where this exception is happening?
The only information that I have when running the app through Visual C++ 6.0 is
"First-chance exception in Inforemer.exe (KERNEL32.DLL): 0x80010105: (no name)."
Can I use this information to deduct where the exception is thrown? Otherwise how else would I track it down?
Cheers,
Clint
|
|
|
|
|
try generating .pdb files. Usually there is Dr. Watson on the server if you have pdb it could be able to safe call stack. There is also debugging tools from Microsoft (not VC studio) with the small footprint, it is safe to put on the server. The major problem you have to overcome is to setup debugger to create dump when 0x80010105 happens. If you can debug the server on the local computer you can just use VC debugger, where you can actually step through the code (even release, with some limitations).
|
|
|
|
|
I discovered how to do it. Since I can debug the server from within VC I set it up to give me a PDB in release mode. I then ran the program and went to Debug->Exceptions in the VC menu. There I was able to add the address of where the exception happened and set it to "Stop always." After generating the exception the debugger kicked in. Fabulous! Now to actually debug the problem 
Cheers,
Clint
|
|
|
|
|
Hello,
I just wanted to know if the following piece of code is correct,
won't have any memory leak, will be portable, will always work, etc...
Or would you code it in another way?
static char (*g_szCMOSInfo)[MAX_CMOS_STRING];
g_szCMOSInfo = new char[NUM_CMOS_STRINGS][MAX_CMOS_STRING];
strcpy(g_szCMOSInfo[i++], "Time - Seconds");
strcpy(g_szCMOSInfo[i++], "Alarm - Seconds");
strcpy(g_szCMOSInfo[i++], "Time - Minutes");
strcpy(g_szCMOSInfo[i++], "Alarm - Minutes");
strcpy(g_szCMOSInfo[i++], "Time - Hours");
strcpy(g_szCMOSInfo[i++], "Alarm - Hours");
strcpy(g_szCMOSInfo[i++], "Date - Day Of The Week");
strcpy(g_szCMOSInfo[i++], "Date - Day");
strcpy(g_szCMOSInfo[i++], "Date - Month");
strcpy(g_szCMOSInfo[i++], "Date - Year");
SAFE_DELETE_ARRAY(g_szCMOSInfo); Where SAFE_DELETE_ARRAY is defined as:
#define SAFE_DELETE_ARRAY(p) { if((p) != NULL) { delete [] (p); (p) = NULL; } }
-Dominik
|
|
|
|
|
When are you calling SAFE_DELETE_ARRAY? if you do it as shown you will lose all those strings.
Just out of curiosity why do you need dynamic array?
|
|
|
|
|
I call SAFE_DELETE_ARRAY at the end, when I don't need the array any more... thought this would be clear 
I need dynamic arrays, because my program displays large amounts of data on numerous different pages. The data is retrieved shortly before I need it to display. If all the arrays would be allocated at program start, my program would explore in memory consumption!
But is the allocation of the strings ok like that?
Thanks for your help
-Dominik
|
|
|
|
|
I feel uneasy about static global nonconst array, but your reasons sound to be solid. You have new, you have matching delete, seems OK(make sure you call delete for each new).
|
|
|
|
|
Here's an easier way:
static char g_szCMOSInfo[][MAX_CMOS_STRING] =
{
{ "Time - Seconds" },
{ "Alarm - Seconds" },
{ "Time - Minutes" },
{ "Alarm - Minutes" },
{ "Time - Hours" },
{ "Alarm - Hours" },
{ "Date - Day Of The Week" },
{ "Date - Day" },
{ "Date - Month" },
{ "Date - Year" }
};
1. It's allocated at compile time so it's very fast,
2. There are no slow heap allocations, and
3. There's no memory to clean up so no leaks to worry about.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Ok, but what if the strings are not known at allocation time?
The code I posted was just thought as an example. I also have to allocate more complex structures, for example 200 DDDEVICEIDENTIFIER2 structs (a DirectX structure).
|
|
|
|
|
Yeah, I just read your reply to AlexO.
Your code looks fine, although the static qualifier does not appear to be needed.
The only thing you may want to consider is that if your string values are always going to be literal strings (ie, "abc", "whatever"), then you don't even need to allocate extra space for them:
char* g_szCMOSInfo[NUM_CMOS_STRINGS];
g_szCMOSInfo[i++] = "Time - Seconds";
g_szCMOSInfo[i++] = "Alarm - Seconds";
Since the compiler has already allocated space for literal strings, all you need to do is point to them.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Hi,
I complided my software in DEBUG and RELEASE mode all are OK.
But when I execute my RELEASE version, an error message appears " OUT OF MEMORY".
Anyone can help me for debbugging this error or how can I do for checking my memory when I execute my software.
youssef
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
