|
I have some code that I want to split off into it's own dll. Can I have the following method in the DLL and call it from a Client, like this?
void DllFunction (std::vector<int> &B)
{
B.push_back(1);
}
----------------------
void SomeFunction ()
{
std::vector<int> A;
DllFunction(A);
}
This works fine when all the code is in the same project but when I split off the DllFunction into it's own Dll, I get errors. I get a runtime error in _CrtIsValidHeapPointer (dbgheap.c) when SomeFunction returns. I suppose the problem is that the DLL allocates the memory and the Client is trying to free it and that's bad.
So, what do people do when they want to pass an STL vector as a reference parameter to a DLL? Cannot such a basic thing as this be done? Do I have to redesign things now that the code is in a Dll? I've looked at MS Knowledge Base Q168958 but it doesn't seem to help me.
I've made sure my runtime libraries are the same for the dll and the client (/MTd), but that didn't fix the problem.
|
|
|
|
|
You should never count on being able to alloc memory in one module, and free it in another module, using the CRT. You can use a process-wide allocator like CoTaskMemAlloc().
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Hi, I'm not an expert, but I recently ran across a similar problem. Try switching your projects to use the DLL version of the run-time libraries and see if that resolves the issue.
--
jthomps
|
|
|
|
|
Another solution (from Jeff's) would be to make an allocator that uses, say, CoTaskMemAlloc. Then you would create all your colloections using this allocator.
Steve
|
|
|
|
|
Try to do vector:reserve in *.exe before any push_back in *.dll to ensure all memory allocation activities are done in the executable.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Assume the following code:
#CODEBEGINS
int main( void )
{
CCPU CPU; // For CPU querys
HLint64 Begin, End; // To keep CPU times
int i, j; // Counters
tVar<int> *tvTest; // Test material
for ( i=1 ; i<500 ; i++ ) {
for ( j=0 ; j<i ; j++ ) {
// Begin counting
Begin = CPU.rdtsc();
tvTest = new tVar<int>;
delete tvTest;
// Stop counting
End = CPU.rdtsc();
// Calculations & output
printf( "[%d:%d]:(delta)TSC: %ld\n", i, j, ( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) );
}
putchar( '\n' );
}
return 0;
}
#CODEENDS
This is suppose to test how fast the computer allocs and frees a class (note: this class has no constructor). I got the following results:
[1 ]:(delta)TSC: 3234
[2 ]:(delta)TSC: 1385
[2:1]:(delta)TSC: 1212
[3:1]:(delta)TSC: 1189
[45:10]:(delta)TSC: 1230
[48:37]:(delta)TSC: 1240
[52:4]:(delta)TSC: 1571
[53:6]:(delta)TSC: 409762 // WOW!
[53:7]:(delta)TSC: 1375
[55:10]:(delta)TSC: 1296
[58:7]:(delta)TSC: 1239
[448:338]:(delta)TSC: 1177 // Almost all not shown so far are 1177
[448:339]:(delta)TSC: 10015
[448:340]:(delta)TSC: 1263
[448:341]:(delta)TSC: 1157
[448:342]:(delta)TSC: 1194 // Almost all from now on are 1194 (this only happned in one of the tests, all the others still had a HUGE majority of 1177)
Can anyone explain these small (sometimes not that small!) variations?
regards
hint_54
-- modified at 14:27 Tuesday 14th February, 2006
Oh.. I forgot, assume this is the CPU.rdtsc() function:
HLint64 CCPU::rdtsc( void )
{
HLint64 i64StampRead;
// Read time stamp counter
__asm {
rdtsc; // ReaD Time Stamp Counter
mov [i64StampRead.Lo], eax // Copy the low DWORD
mov [i64StampRead.Hi], edx // Copy the high DWORD
}
return i64StampRead;
}
regards, once again 
|
|
|
|
|
hint_54 wrote: Can anyone explain these small (sometimes not that small!) variations?
Read here.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
"QueryPerformanceCounter returns a reasonably accurate rendering of time, at least on Intel platforms. This is because on Intel platforms it returns the contents of a "cycle counter", converted to timing units based on the processor frequency. Because the cycle counter actually counts the number of CPU cycles, it gives a reasonable approximation of real time. However, executing the same loop twice may give different results because the presence or absence of data in the cache will change the number of cycles required to execute the program. So it is at best an approximation, and you have to do some more careful statistical analysis to figure out what is really going on."
This was quoted from the link that you have provided earlier.
Does this mean it is all about cache? If so, please assume the following code then:
int main( void )
{
int *ptr, i;
for ( i=0 ; i<100 ; i++ ) {
ptr = new int;
delete ptr;
}
return 0;
}
So, after "i=0", "i" gets in the cache. After the first time it executs "ptr = new int" "ptr" gets in cache too. From now on, all the 100 cicles will use "i" and "ptr" and these are supposed to be already cached, right? The only thing that I can see that is not cached is "*i", but I never access it directly (or do I?  ). So, I understand why the first values show a small variation (after the first 4 or 5 cicles it stabilizes), but I still don't understand why those variations keep showing up along the whole test (unless I'm really accessing "*i").
Anyone? 
regards
hint_54
|
|
|
|
|
That's a big variation, I don't think this can be written off to the fact that Windows is not a real time OS. I'd put timing around ever line in the loop so I've got a breakdown and try to narrow down the problem.
Steve
|
|
|
|
|
Aside from the issues about getting any sort of solid timings under Windows (pointed out ably by earlier responders), there is a subtle error in the time calculation that should be noted.
hint_54 wrote:
// Calculations & output
printf( "[%d:%d]:(delta)TSC: %ld\n", i, j, ( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) );
The calculation of '( Hi - Hi ) + ( Lo - Lo )' is not the correct implementation of a 64-bit difference. This code calculates two independent 32-bit differences and then sums them together, ignoring the difference in the order of magnitude represent by the 'Hi' values compared to the 'Lo' values.
Now, for this particular exercise, most of the time, in fact nearly all of the time, the answer will be still be correct because 'End.Hi' will equal 'Begin.Hi' giving a difference of 0. Indeed in this particular snippet of code, we may very well be lucky and never run into trouble.
But once in a great while things will go wrong. When you sample the timer for Begin just before the 'Lo' word rolls over and then sample the timer for End just after the rollover occurs, then the resulting calculation will be off because 'Hi - Hi' will no longer be 0, it will be 1. But in truth it's not really 1, it really represents 0x100000000.
Consider the following simple examples using 2 digit hexadecimal numbers. (The low order nibble will represent our be our 'lo' word and the high order nibble will represent our 'hi' word.)
Ex 1: Usual Case - no 'rollover'
<br />
Begin = 0x95
End = 0x98
<br />
End - Begin = 0x98 - 0x95 = 0x03<br />
<br />
( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) =<br />
( 0x9 - 0x9 ) + ( 0x8 - 0x5 ) = <br />
( 0x0 ) + ( 0x3 ) = 0x03<br />
<br />
Ex 2: Rare Case - 'rollover' bites us
<br />
Begin = 0x9E
End = 0xA1
<br />
End - Begin = 0xA1 - 0x98 = 0x03<br />
<br />
( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) =<br />
( 0xA - 0x9 ) + ( 0x1 - 0xE ) = <br />
( 0x0 ) + ( -0xD ) = -0x0C<br />
<br />
( End.Hi - Begin.Hi ) + ( End.Lo - Begin.Lo ) =<br />
( 0xA - 0x9 ) + ( 0x1 - 0xE ) = <br />
( 0x0 ) + ( 0x3 ) = 0x04<br />
In either case for the 'rollover' example we get the wrong value (potentially very wrong). To correct the issue use true 64-bit arithmetic on these 64-bit values.
Dan
|
|
|
|
|
You mean this?
( ( End.Hi - Begin.Hi ) << 32 ) + ( End.Lo - Begin.Lo )
regards
hint_54
|
|
|
|
|
hint_54 wrote: You mean this?
( ( End.Hi - Begin.Hi ) << 32 ) + ( End.Lo - Begin.Lo )
regards
hint_54
Well, not really... If ( End.Lo - Begin.Lo ) generates a 'borrow' condition, that condition is not propagated up to the ( End.Hi - Begin.Hi ).
The shift by 32 also won't work since you are shifting a 32-bit value by 32-bits. The compiler does not automatically promote this expression to 64-bits. The shift results in either 0 because all of the bits get shifted out of our 32-bit value or, if you are on an intel processor or intel clone (and aren't we all), it remains unchanged because the hardware performs a ( modulo 32 ) on the shift count and you end up shifting by 0 bits.
A fully general solution would be to use something like ULARGE_INTEGER[^]
<br />
ULARGE_INTEGER largeBegin;<br />
ULARGE_INTEGER largeEnd;<br />
ULARGE_INTEGER largeResult;<br />
<br />
largeBegin.LowPart = Begin.Lo;<br />
largeBegin.HighPart = Begin.Hi;<br />
<br />
largeEnd.LowPart = End.Lo;<br />
largeEnd.HighPart = End.Hi;<br />
<br />
largeResult.QuadPart = largeEnd.QuadPart - largeBegin.QuadPart;<br />
<br />
printf( "Delta = %u\n", largeResult.LowPart );<br />
Because we are computing time deltas that we know are much, much less than 232, we can safely ignore largeResult.HighPart - it will always be 0. We just had to perform 64-bit math to handle those occasional 'borrow' conditions. If we were doing general math on arbitary values, then we couldn't just throw that value away.
Later,
Dan
Remember kids, we're trained professionals. Don't try this at home!
|
|
|
|
|
HI,
I am using the code below for writing in the file, that file opening on windows XP using WordPad , and the data is in new line for every \n but in win2k and XP 2003 server \n does not works and a box appears and all the data is written in one line.
Why it is so ?
CString write = res+",\t\t\t"+res1+"\n";
percentFile.Open( strFormulaPath , CFile::modeCreate|CFile::modeNoTruncate|CFile::modeReadWrite|CFile::typeBinary);
percentFile.Seek(0L,CFile::end);
percentFile.Write(write , write.GetLength ());
percentFile.Close ();
Regards.
|
|
|
|
|
Use "\r\n" instead of just "\n"
|
|
|
|
|
am a novice in working with VC++,actually am working on sensor interfacing, could anybody help me with Port configuration of the serail port interfacing. After configuring the port by default parameters like baudrate,etc, i should send telegram code in HEX to sensor, but am getting an error message. I couldnt proceed further. I would appreciate, if anybody helps me out.
srija
|
|
|
|
|
be more specific, then it will be easy to suggest a solution.
Which API call failed? whats the error code returned?
Use ::GetLastError() API to see the error code.
rgds...mil10
|
|
|
|
|
What function (or method) is returning an error code to you and what is the error code?
Dan
|
|
|
|
|
I am trying to do this:
char szHostName[MAX_PATH];
gethostname(szHostName, MAX_PATH);
I have included winsock2.h yet am getting:
error LNK2019: unresolved external symbol __imp__gethostname@8
Anybody know what I am missing? VS2002
thanks, -mutty
|
|
|
|
|
Sounds like you are not linking with the Winsock2 library (Ws2_32.lib).
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!)
|
|
|
|
|
thank you - how do I link WS2_32.lib?
Stupid - never mind this. I was trying to open the property pages for the SOLUTION, not the Project. No wonder there was no linker folder!
-mutty
-- modified at 13:42 Tuesday 14th February, 2006
|
|
|
|
|
Mutty wrote: thank you - how do I link WS2_32.lib?
#pragma comment(lib,"WS2_32.lib")
"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
|
|
|
|
|
Mutty wrote: I have included winsock2.h yet am getting:
error LNK2019: unresolved external symbol __imp__gethostname@8
Linker errors and header files (usually) have nothing to do with each other. Had it been a header-related issue, you would have most likely seen a compiler error.
"The greatest good you can do for another is not just to share your riches but to reveal to him his own." - Benjamin Disraeli
|
|
|
|
|
I've tryed the following code.
// somefile.h
class MyClass {
public:
inline void MemberFunction( void );
};
// somefile.cpp
#include "somefile.h"
void MyClass::MemberFunction( void ) // Also tryed "inline void MyClass::Memb..."
{
// Blá, blá, blá...
}
// Launcher.cpp
#include "somefile.h"
int main( void )
{
MyClass Example;
Example.MemberFunction();
return 0;
}
#ENDCODE
But I get
launcher.obj : error LNK2001: unresolved external symbol "public: void __thiscall CCPU::SomeFunction(void)" (?SomeFunction@CCPU@@QAEXXZ)
Debug/LOAC.exe : fatal error LNK1120: 1 unresolved externals
Any suggestions?
regards
hint_54
|
|
|
|
|
|
Yes, the file is part of the project and functions are the same (my mistake on that one  )
regards
hint_54
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
