|
Why am i doing this...?
Cuz I am not a professional programmer I'm someone who simply enjoys the challenges computers give me. Over the years i've self studied many langs, like basic,pascal,assembly,c++,JScript,perl(and other c derivitives...?) and even once had a quick fix for cobol and lisp. I dropped outta<grins> high school in Gr. 10 and found myself pumping gas and soon realized it sucked. basically i'm a VERY un-convetional programmer and somes times like to do things the hard way, just for experience. Money or time is not an issue for my projects, efficiency in code is everything. Sometimes this means re-inventing the wheel and making it better like BASF<smiles> I'm not saying existing controls aren't great, but they don't do what i want.
I'm no expert, but i've looked for ways of using existing windows edit control(CEdit) but couldn't quickly figure out how to increase it's buffer size so i gave up and decided to write my own.
Sorry for the verbose life story, but i'm often asked why re-invent the wheel or don't fix it if it ain't broke...my answer. What fun is that.
Ciao
"An expert is someone who has made all the mistakes in thier field" - Niels Bohr
|
|
|
|
|
I am seeking information regarding memory allocation. Specifically, about the default C++ memory allocation (that comes with the compiler), how well it works in a multithreaded environment -- or on a server.
I expect that this memory allocation was written 'more for' a client application, where huge numbers of allocations are not necessarily done.
Does anyone out there have good experience with this? What good alternatives are there? I am looking at an advertisement for "SmartHeap from MicroQuill", and their ad says that the compiler-supplied memory management is SLOW SLOW SLOW, and even slower in a multi-processor and multi-threaded environment....
I've had this feeling for a long time that 'just using' the default compiler libraries for memory management is not a good long-term solution. And do any of these have good tools for debugging memory problems?
Any comments out there?
|
|
|
|
|
Hi Peter Weyzen,
Simply put, the default malloc that "new" uses <<sucks>> for multhreading, you could use Hoard alllocator that is appropriate for multithreading/multiprocessing. It has released as LGPL , so you could use the source or the binaries freely , In the web site there are plenty of graphics and reports that demonstrates the gains that this allocator provides.
So here is the link http://www.hoard.org
Hope this helps , regards
Joao Vaz
Joao Vaz
|
|
|
|
|
dear all,
i am using MS Acess database with ODBC in my MFC project.I am creating DSN name through control panel.But i want to create DSN name through programmetically.
please help me.
thanks in advance
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
anju
|
|
|
|
|
Anju,
I think what you are looking for is how to create a "DSNLess Connection." Click here and search on "DSNLess" to find your answer.
Hth,
~Cliff
P.S. I did a little more checking and here is a link to MSKB article Q167294
Also you will find a lot more reference in MSKB if you search on DSN-Less with the hyphen.
|
|
|
|
|
Have a look at SQLConfigDataSource() in the MSDN library. It worked fine for me.
Alternatively, OLEDB (specifically IDBDataSourceAdmin::CreateDataSource()) looks like it provides similar functionality, but I haven't used it before.
J
|
|
|
|
|
Thanks i got the solution with SQLConfigDataSource.![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
anju
|
|
|
|
|
Hey!
Some background first: I've written an app that has a plugin system.
Each plugin contains a CDialog. I enumerate all the plugin dll's in a
certain folder and init each one, storing their HMODULE handles and
other information in an array. Each plugin has an item in
the "plugin" menu and a check marks weather the a certain plugin is
activated. All of this works great and I have no problems with it.
The problem comes from when I want to shutdown one of the plugins.
Depending on the order the plugins were loaded, if I shut down
one plugin, it does so properly, but all the others dissapear. The
other plugins don't get shutdown, their HWND becomes NULL and
consequently, their windows vanish.
I've traced the code to the point where this all happens, and
a FreeLibrary() call seems to be the culprit. As soon as that
function is called with the HMODULE of the plugin I want to free,
all the others dissapear. Now I do have functions in each plugin
that free memory and things like that, but as a rule plugins don't
know anything about each other. They should be self-contained ie
one plugin shouldn't be able to affect another. That's why I think
that there might be some weird stuff happening deep down in MFC or
Windows, but I have no idea what.
Any suggestions?
Steve The Plant
|
|
|
|
|
I have a similar type system for one of my apps although I do not dynamically unload them until the app ends.
I would check to see whether its a particular DLL which always causes the problem. Try renaming them so they get loaded in a different order in your app. If the same DLL always causes the problem check to see whether its corrupting memory somehow in your main app.
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
|
|
|
|
|
I've done what you suggested, and It doesn't look like its a
particular DLL. I've had them loaded in a different order and the
problem persists.
Here's another explanation of the problem. Let's say my app
loaded four dlls, plugin01 to plugin04. Plugin01 being
the first one loaded, plugin02 the second and so on. If I
shutdown plugin01, then the other three dissapear. But
if I shutdown plugin02, 3 and 4 dissapear but not 1. If I
shutdown plugin03, plugin04 dissapears, but not 1 or 2.
It doesn't matter which plugins get loaded, a loaded plugin
always knocks out the ones loaded after it when shutdown.
It's weird.
I'm only doing one call to FreeLibrary and I'm passing the HMODULE
of the plugin I want to shutdown.
But, if all the plugins are loaded, and I shutdown and restart the
plugins in the reverse order (4, then 3, etc.) the problem dissapears
and I can shutdown and activate plugins at will properly without
affecting others.
Putting breakpoints in the exit functions (DestroyWindow,
ExitInstance, etc.) of the other plugins doesn't work. It
doesn't seem that those functions are called when they accidentally
dissapear.
Steve The Plant
|
|
|
|
|
Do those DLLs do something weird at DLL_PROCESS_ATTACH or DLL_PROCESS_ATTACH time, like loading another libraries?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I'm not sure. They could very well be. I created those DLLs through
the MFC DLL Wizard. DllMain is hidden from me, so I don't know
exactly what it's doing.
Steve The Plant
|
|
|
|
|
If you used the MFC Wizard, that part should be OK.
(Wild guessing) Try statically linking MFC (if your DLLs and app used it as a shared DLL).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Would you be able to post your code for loading and releasing the DLL's. What you are describing sounds weird. The only other things I can think off that would possibly affect you are that because they are extension DLL's they get loaded/released together, or the base address's of the dlls (set in the linker tab of settings) are clashing somehow.
Roger Allen
Sonork 100.10016
If I'm not breathing, I'm either dead or holding my breath.
|
|
|
|
|
Hi,
I'm trying to convert a line of code that calls the API CreateThread function to the _beginthreadex function, but I get the compile error:
"cannot convert parameter 3 from 'unsigned long (__stdcall *)(void *)' to 'unsigned int (__stdcall *)(void *)"
Parameter 3 is declared as type LPTHREAD_START_ROUTINE. What type should I use to avoid this compile error?
Thanks
Paul Jahans
|
|
|
|
|
Try using this sort of thread proc function :-
DWORD ThreadFunc(DWORD data)
{
//thread stuff in here
}
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
The thread function is in the calling program and is declared like this:
DWORD WINAPI CGUITermDoc::CommReader(void *pvData)
From calling program, I call the DLL function:
StartCommThread(LPTHREAD_START_ROUTINE CommProc, void *pvData)
In this function, I try to pass CommProc to the _beginthreadex function, but this is where I get the compile error.
Paul Jahans
|
|
|
|
|
|
Yes, that's it!
you are missing the static in your function definition.
(Just in case it was not clear yet!)
static UINT WINAPI CommReader(void *pvData);
|
|
|
|
|
Funny how almost 30% of questions asked here are already in the FAQ
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Seems like _beginthreadex does not accept functions of type LPTHREAD_START_ROUTINE but rather functions with the signature (unsigned int (__stdcall *)(void *)) (i.e., returning unsigned int instead of DWORD).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
You cannot use a non-static member function of a class as your thread proc.
Nish
p.s. make it static, or make it a global function not part of any class
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
This doesn't answer your question, but might be of interest
From the docs for CWinThread:
"The CWinThread class is necessary to make your code and MFC fully thread-safe. Thread-local data used by the framework to maintain thread-specific information is managed by CWinThread objects. Because of this dependence on CWinThread to handle thread-local data, any thread that uses MFC must be created by MFC. For example, a thread created by the run-time function _beginthreadex cannot use any MFC APIs."
|
|
|
|
|
Tim
This is serious stuff.
This means we cannot use MFC functions and CRT functions together in any thread.
I mean to use CRT functions safely it is always advised to use _beginthreadex. Now you say MFC wont go along with that.
This is a bad situation
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Nish [BusterBoy] wrote:
This means we cannot use MFC functions and CRT functions together in any thread.
No, that's incorrect. Look at the source for CWinThread::CreateThread() and you'll see that it calls _beginthreadex().
The restriction on how you create the thread ensures that MFC is correctly initialized. Since MFC uses the CRT, MFC handles initializing the CRT itself.
--Mike--
My really out-of-date homepage
"Hey, you wanna go to the Espresso Pump and get sugared up on mochas?"
-- Willow Rosenberg
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
