|
Hi
I need to exchange large Strings between my own dll and my programm.
Any Idears ??
THX
|
|
|
|
|
extern string mystring;
Or what do you mean with "exchange" ?
~RaGE();
|
|
|
|
|
If the DLL is loaded into your processes address space, you can already see each other's memory - no extra steps required. Just allocate space for the string, and pass it to a method in the DLL. Or pass the memory to a method in the DLL and have it return the string in it. Or have the DLL allocate the memory and return it to you. Etc.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: Or have the DLL allocate the memory and return it to you.
Don't forget the let the dll free the memory it has allocated. Every module exe/dll is resposible for its own allocated memory.
codito ergo sum
|
|
|
|
|
Actually, I abhor writing hand-off memory functions, where memory is allocated by the called function and returned from it with the understanding that the caller is now responsible for it. IME, there seems to be an "out of sight, out of mind" mentality where if the caller did not make an explicit call to a memory allocating function/operator that they are familiar with (new, malloc(...), SysAllocString(...), etc.), they tend not to realize that they are now responsible for deallocating it.
I tend to write functions that need memory such that they take a pointer to a previously-allocated block of memory and the size of that block. That way, it is clear that the caller manages the memory.
I was just detailing examples for the poster. Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free (as long as it was allocated while in the context of your process, and not another).
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free
It used to be no problem, on OS like Win9x and Win2000. We had writen our own Dll who encrypted some
data returning the BYTE* pointer to the encrypted data which was freed after use in our application. Without any problems what so ever.
We then moved to WinXP and our application crashed on the the delete[] of the memory returning in a access violation.
Found this on the net:
Potential Problems When Crossing DLL Boundaries
It is not possible to allocate memory in a DLL (either explicitly with malloc / new or
implicitly with aforementioned strdup) and pass the pointer across the DLL boundary into
the process space to free it, when the DLL and the application are using different copies
of the CRT (C-RunTime) libraries. This will cause a nasty memory access violation or worse:
corrupt the heap! When you bump into an assert in the CRT lib when it tries to execute free(),
you will know you have run into this very problem.
Memory is only valid for the copy of the CRT where they were allocated. This means that when
you are using two different CRT libraries (LIBCMT.LIB and MSVCRT.LIB for example) together,
you cannot expect one to correctly free something the other has allocated. Because they most
probably are using different heap managers, the heap runs the risk of becoming corrupted when
you run the application in release mode! Pity the programmer who has to track the bug that
crashes his application this way.
So its better safe the sorrow.
codito ergo sum
|
|
|
|
|
Hello,
I've developed an application for PocketPCs. I'm using Embedded Visual C++ so I released differents versions based on the PocketPC architecture (ARM/XSCALE, MIPS, SH3...)
However, most users don't know which architecture their PPC is based on. So I'd like to ship a single setup app that will install the right version according to the PocketPC connected (via ActieSync). But I don't know how to make such a setup app.
Can someone help me?
Regards,
Allad
----
Navigator - Your best alternative to Windows Explorer
|
|
|
|
|
I often find MFC projects - also here on Code Project - where the STL is used.
Everytime i wonder why someone do this, there are equivalent classes in the MFC.
If i don't want to use the MFC ok, but if i make a control which is derived from a MFC class, why shouldn't i use MFC containers too? MFC has CMap, CArray and CList, so there is no need to use STL.
Are there any reasons to use the STL in a MFC project?
|
|
|
|
|
first of all, STL is the Standard C++ library, which means it compiles on every plateform (windows, linux, mac, solaris, etc...) without changing the code, but only recompiling...
secondly, MFC are targetted for windows, and most of the classes provided there are wrappers, which means they provides some additionnal layers (which may result in more slow code).
and finnaly, MFC classes are generally usd for display purpose (GUI oriented at least), while STL are for background treatments (controler layer of MVC model).
any more questions ?
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: first of all, STL is the Standard C++ library, which means it compiles on every plateform (windows, linux, mac, solaris, etc...) without changing the code, but only recompiling...
secondly, MFC are targetted for windows, and most of the classes provided there are wrappers, which means they provides some additionnal layers (which may result in more slow code).
and finnaly, MFC classes are generally usd for display purpose (GUI oriented at least), while STL are for background treatments (controler layer of MVC model).
any more questions ?
Have you even read my post?
|
|
|
|
|
have you tried to understand mine ?
it is not because you create your own control (which is GUI part here, i conceed) that everything you do goes to that layer... maybe there are so internal treatment whih have nothing to do with rendering.
moreover, know that CMap and CArray are crap !
ps: thank you for the rate 
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: have you tried to understand mine ?
Yes, but the question was not STL or MFC for portability, the topic is STL in MFC projects.
If my project makes usage of MFC it's not portable anymore, no matter if my container classes are portable or not.
Therefore you whole post has nothing to do with the topic.
|
|
|
|
|
Good grief. Just because you're using MFC doesn't mean you have to its inferior container classes! I use STL containers in all my MFC projects because it gets the job done faster and with less code than the MFC equivalents.
|
|
|
|
|
ABuenger wrote: If my project makes usage of MFC it's not portable anymore
yes
ABuenger wrote: no matter if my container classes are portable or not.
no.
consider the case where you do a general treatment on datas in background... these treatments have nothing to know about the GUI, whether it is mfc, owl, etc...
if you don't care about what I say, let it down. if however, you still want to understand my reasons to answer so, have a look a my VisualCalc article. you will - i hope for you - understand that i can easily interchange the user interface depending on the plateform i target my project.
so, of course MFC is not portable further than windows, but in my case, ONLY the GUI is not portable, so, i don't have to rewrite my whole code. so, i believe that's why STL is used so much... portability is an important point in software development industry, especially when you have to code very fast...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: consider the case where you do a general treatment on datas in background... these treatments have nothing to know about the GUI, whether it is mfc, owl, etc...
if you don't care about what I say, let it down. if however, you still want to understand my reasons to answer so, have a look a my VisualCalc article. you will - i hope for you - understand that i can easily interchange the user interface depending on the plateform i target my project.
so, of course MFC is not portable further than windows, but in my case, ONLY the GUI is not portable, so, i don't have to rewrite my whole code. so, i believe that's why STL is used so much... portability is an important point in software development industry, especially when you have to code very fast...
Ok, in that case it makes sense to use STL. But i am talking about custom MFC controls which will never be ported and aree just standalone MFC extensions.
For example CPPTooltip and CTreePropSheetEx on Code Project. These controls will never be portable, and if i derive a control from a MFC class it doesn't make sense to have a STL map in my class.
|
|
|
|
|
can you be a little more polite? 
VuNic
|
|
|
|
|
VuNic wrote: can you be a little more polite?
Same Here!
"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
|
|
|
|
|
ABuenger wrote: Are there any reasons to use the STL in a MFC project?
Many folks are opposed to the container classes in MFC.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
DavidCrow wrote: Many folks are opposed to the container classes in MFC.
But why? The implementation is better than the STL in my eyes. And if i already use a framework which has container classes, why should i bloat my executable with an other library?
To me it seems like many C++ programmers don't know the MFC very well (see above post) and therefore use the STL.
|
|
|
|
|
ABuenger wrote: The implementation is better than the STL in my eyes
At this level, it is personal tastes, IMO. But I really prefer STL's.
ABuenger wrote: To me it seems like many C++ programmers don't know the MFC very well (see above post) and therefore use the STL.
I think you do not know the STL very well then, and therefor stick to the slow and not so practical MFC containers... 
~RaGE();
|
|
|
|
|
Rage wrote: At this level, it is personal tastes, IMO. But I really prefer STL's.
Ok, at the end both container classes makes the same. Also STL is not STL, there are many different implementations. IMO at least the STL that ships with VC6 isn't as good as the MFC container classes.
But that's personal taste.
I just don't like it if libraries are used mixed.
|
|
|
|
|
It is true that the STL that ships with VC6 is rubbish. However, you can rectify this by downloading STLPort - it's free and the implementation is very highly praised.
If you are sticking to one library because you don't want to "mix" code, then you are, in my opinion, shooting yourself in the foot. Really, what difference does it make? A few extra KB on your EXE? Big deal!
|
|
|
|
|
Robert Edward Caldecott wrote: It is true that the STL that ships with VC6 is rubbish. However, you can rectify this by downloading STLPort - it's free and the implementation is very highly praised.
There is an other reason not to use STL, it's not available for many CE devices.
Robert Edward Caldecott wrote: If you are sticking to one library because you don't want to "mix" code, then you are, in my opinion, shooting yourself in the foot. Really, what difference does it make? A few extra KB on your EXE? Big deal!
It makes the code more readable if i stick to one library. Also there is often a performance penality. std::string -> char* -> CString conversions are pretty common.
Please also read this post: http://www.codeproject.com/script/comments/forums.asp?forumid=1647&select=1369083&df=100&fr=13.5#xx1369083xx[^]
|
|
|
|
|
ABuenger wrote: There is an other reason not to use STL, it's not available for many CE devices.
True, but when I target CE, I wouldn't use bloated MFC either. My last PocketPC app was written in ATL/WTL. The less dependencies the better when it comes to CE.
|
|
|
|
|
Robert Edward Caldecott wrote: True, but when I target CE, I wouldn't use bloated MFC either.
But that bloated MFC dll is already pre-installed on the target 
The topic is also not "Should i use ATL/WTL or MFC for my CE project". I just don't understand why people use STL in MFC projects when there is no need to do so.
If i only want to map a string to an object, CMap handles this very well.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
