|
when u use the MapViewOfFile API and set the 'dwNumberOfBytesToMap' to a particular value say "x" and then when u get the return pointer value(say "y") of the buffer that MapViewOfFile API returns,
What happens when we try to write to the "y+x+1"th memory location.....will an error occour?
cheerz!
|
|
|
|
|
namaskaaram wrote: What happens when we try to write to the "y+x+1"th memory location.....will an error occour?
Yes. You'll get an access violation exception and your program will be terminated by Windows unless you handle the exception.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Or unless you happen to already own that memory, which is more unfortunate - harder to find bugs in your program. I would rather see an access violation any day than to try to figure out 'who' overwrote some of my own memory.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Yes. That would be a rare occurrence though because MapViewOfFile() returns addresses in a different address range to the addresses returned by allocating memory "normally". So unless you've called MapViewOfFile() twice, this probably won't happen.
But you're right
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I wanna use Linkage C in my code in visual Studio 2003 ,
when i add library file in Tools/Options in Lib section (in these case
my library is C:\WINDDK\3790\lib\wxp\i386)
I get linker error ! that can not resolve some things.
test error LNK2019: unresolved external symbol @_RTC_CheckStackVars@8 referenced in function "unsigned int __stdcall ATL::_AtlGetThreadACPThunk(void)" (?_AtlGetThreadACPThunk@ATL@@YGIXZ)
test error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8
test error LNK2001: unresolved external symbol @_RTC_CheckStackVars@8
test error LNK2019: unresolved external symbol __RTC_CheckEsp referenced in function "unsigned int __stdcall ATL::_AtlGetThreadACPThunk(void)" (?_AtlGetThreadACPThunk@ATL@@YGIXZ)
test error LNK2001: unresolved external symbol __RTC_CheckEsp
test error LNK2001: unresolved external symbol __RTC_CheckEsp
test error LNK2001: unresolved external symbol __RTC_Shutdown
test error LNK2001: unresolved external symbol __RTC_Shutdown
test error LNK2001: unresolved external symbol __RTC_Shutdown
test error LNK2001: unresolved external symbol __RTC_InitBase
test error LNK2001: unresolved external symbol __RTC_InitBase
test error LNK2001: unresolved external symbol __RTC_InitBase
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2019: unresolved external symbol @__security_check_cookie@4 referenced in function "unsigned int __stdcall ATL::_AtlGetThreadACPThunk(void)" (?_AtlGetThreadACPThunk@ATL@@YGIXZ)
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2001: unresolved external symbol @__security_check_cookie@4
test error LNK2001: unresolved external symbol @__security_check_cookie@4
But i have not any problems in Visual Studio 6.0.
can anyone help me?
Best Regards.
M.J.M.
|
|
|
|
|
I have a c++ progeam calling a subroutine. The variables are passed correctly, But just step into the subroutine at the first line under the subroutine header by break point, I got error message: "debug assertion failed"
.......
.......
complexFFT(sd_l,np_seed,np_seed1,isign);
.......
.......
void CData_vib_procDlg::complexFFT(float data[],unsigned int &number_of_samples,unsigned int &sample_rate,int &sign)
{
|
|
|
|
|
An assertion has failed. Check the parameters you are passing to the function. Sorry about the vague answer but with the information you give I don't think it can be narrowed down much further. Give us more details/source code if you want us to give you a more detailed response.
eg where are sd_l, np_seed, np_seed1, isign defined, and what types are they? What values do they have? What is the exact assertion?
The assertions are there for debugging usually to tell you that something you you sent the function is invalid.
When I die I'd like to go peacefully in my sleep like my father, not screaming in terror like his passengers!!!
|
|
|
|
|
sd_l is a float type array - sd_l[i], i=0,1,...np_seed-1, np_seed and np_seed1 are unsigned int,
np_seed1 = 4096
void CData_vib_procDlg::complexFFT(float data[],unsigned int &number_of_samples,unsigned int &sample_rate,int &sign)
{ ........
-- modified at 0:04 Tuesday 11th April, 2006
|
|
|
|
|
How to store a Binary value in a variable?
as we do for hexadecimal value as x=00XF88.how do we
store binary value like this?
Fly Like An Eagle With MIGHTY POWER.
|
|
|
|
|
You can't specify a binary literal directly. Specify it as octal or hex instead.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
hey, trying to send a DLL written in C with VC6, an integer from a VB6 app. I send it as an integer, it arrives as a u_int and is always 0. I accept the integer using a function, not a callback. I tried sending the value as a string and atoi()ing it, same results. I sprintfed the value and MessageBoxed it, which is how I know it is always 0 before usage.
How do I make the value keep its value when sent from VB6 app to VC6 DLL?
If you need more info, code or something, let me know. Thanks in advance.
|
|
|
|
|
Here's a tip.
In VB6, Integers are 16 bit and Longs are 32 bit.
You'll need to map a VB6 Long to a C/C++ int.
-- modified at 23:22 Monday 10th April, 2006
|
|
|
|
|
Should I do that on the C side? I assume you mean to send the long value to the DLL function and do the conversion there. Can't find any info on how to make that conversion on the VB side, which I guess wouldn't make sense and would be redundant to do so. Let me know if I am headed in the right direction. I will continue to research it and check back here periodically. thanks in advance.
|
|
|
|
|
This isn't really a conversion issue. This is an issue with correctly defining the C function on VB6's side.
I suggest that you leave your C library alone (assuming it has worked fine before). Instead, you should fix the Declares in your VB6 code.
If the C function has a short , use an Integer type in VB6.
If the C function has an int , use a Long in VB6.
For example, if a C function is defined like this...
int Sum(short x, short y);
Then in VB6, it would be declared like this...
Private Declare Function Sum Lib "YourLib.dll" (ByVal x As Integer, ByVal y As Integer) As Long
|
|
|
|
|
hey, sorry for the late reply. I did what you suggested and it is now returning the proper integer on the C DLL side, but when it goes into my processing function, the value becomes 0 still. I should probably have told you that the processing function is created in its own thread --maybe that is why I am having trouble.
Basically the VB6 app sends the integer as long, it is recieved by a function and stored as u_int. The function calls the threaded function and the value should then be used in a for loop to determine how many times the for loop should loop.
Theo:
u_int *My_Var;
<Threaded_Function>
<for 0 to My_Var>
</for>
</Threaded_Funtion>
<function u_int *Sent_Variable>
myVar = Sent_Variable;
return 0;
</function>
So, that is pretty much it. Let me know if you need more info. Thanks in advance.
|
|
|
|
|
This sounds like an issue in your C library.
For starters, you might just want to comment out your C function's code and just have it return a constant. This will prove whether or not a call to your C library is working.
Next, I think you need to debug your C function's code because I suspect that's where the issue is. If you're using threads, then you could be running into race conditions.
If your C function makes a call to a threaded function, are you blocking the current thread while it's being processed? Otherwise the current thread will just fall through before the process completes (or even begins). Or are you making a separate call to your C library for the process result?
|
|
|
|
|
Is it possible to have a tree control with some items having checkboxes and others not?
ie) the root items to not have checkboxes, but the child items to have a checkbox.
|
|
|
|
|
Hello,
a question around the error C2666, under vc80 (RTM-8.0.50727.4200)
Is it compliant to the C++ standard ?
class CondParams
{
...
static bool getVariableState( const string& s, int& idx, string::size_type* p = NULL;
static bool getVariableState( string& rs, int& idxVar, const bool& trim );
);
bool CondParams::getVariableState( string& rs, int& idx, const bool& trim )
{
...
VCF::String::size_type p = 0;
bool ok = getVariableState( rs, idx, &p );
if ( ok ) rs = rs.substr( p );
...
}
I get the error message:
1>d:\projs\condparams.cpp(66) : error C2666: 'vcfex::CondParams::getVariableState' : 2 overloads have similar conversions
1> d:\projs\code\condparams.h(130): could be 'bool vcfex::CondParams::getVariableState(string &,int &,const bool &)'
1> d:\projs\code\condparams.h(129): or 'bool vcfex::CondParams::getVariableState(const string &,int &,string::size_type *)'
1> while trying to match the argument list '(string, int, size_type *)'
1> note: qualification adjustment (const/volatile) may be causing the ambiguity
I could fix the problem by doing:
1) static bool getVariableState( string& s, int& idx, string::size_type* p = NULL; // A
or by doing:
2) bool ok = getVariableState( const_cast<const string="">(rs), idx, &p );
so I guess that the compiler is confused because it doesn't find any perfect match.
The solution 1 is usually not acceptable.
So I have to apply 2).
But this situation is *very* common: why should I need to specify that a variable
is constant each time I am using it as argument for a function that declared that is not
going to modify it ?
Also it doesn't logically seem necessary.
It is like the Standard C++ ( or Microsoft? ) is forcing me to put a const_cast<const ...=""> everywhere.
This was not a problem with vc70.
Similar issue, but not identical, with an example given in vc80 RTM help about the C2666 error.
enum E
{
E_A, E_B
};
class A
{
int h(const E e) const {return 0; }
int h(const int i) { return 1; }
void Test()
{
h(E_A);
h((const int) E_A);
h((int) E_A);
}
};
Why the compiler shouldn't be smart enough to understand that
int h(const E e)
is a better match than
int h(const int i)
?
Why in earth
int h(const E e)
solves the problem, while
int h(const E e) const
does not ?
Thank you very much for any answer before I start to *fix* my code !
Marcello
|
|
|
|
|
For the first situation...
VCF::String::size_type and string::size_type are not the same type, so neither of the function calls match perfectly. However, both could match using implicit casting rules, hence the ambiguity. If you intend to call the first one, make sure the parameter is string::size_type rather than VCF::String::size_type
For the second situation...
Again, neither overload matches perfectly. You're calling a function called h from a non-const this pointer. The compiler can either implicitly convert this to a const pointer and call the first one, or it can implicitly convert E to an int and call the second one. Neither conversion has preference over the other, so there is an ambiguity. The reason uncommenting the other definition of h works is because it is a perfect match to the function call - there is no conversion required.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thank you very much for the reply.
Please forget about the VCF::String thing. It was a typo on my side.
Here is a code I made for this question ( it compiles
class Cond
{
public:
typedef std::basic_string<wchar_t> MyString;
Cond() { };
virtual ~Cond(void) { };
Cond( const Cond& other ) {
*this = other;
};
Cond& operator= ( const Cond& other ) {
return *this;
};
bool split( const MyString& s, MyString::size_type* p = NULL );
bool split( MyString& s, const bool& trim );
};
inline
bool Cond::split( const MyString& s, MyString::size_type* p )
{
return true;
}
inline
bool Cond::split( MyString& s, const bool& trim )
{
MyString::size_type p;
if ( split( s, &p ) )
{
s = s.substr( p + 1 );
return true;
}
return false;
}
I get the error message:
1>d:\projs\libraries\vcfex\src\conditions\test.h(51) : error C2666: 'vcfex::Cond::split' : 2 overloads have similar conversions
1> d:\projs\libraries\vcfex\src\conditions\test.h(37): could be 'bool vcfex::Cond::split(vcfex::Cond::MyString &,const bool &)'
1> d:\projs\libraries\vcfex\src\conditions\test.h(36): or 'bool vcfex::Cond::split(const vcfex::Cond::MyString &,stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type *)'
1> with
1> [
1> _CharT=wchar_t,
1> _Traits=stlp_std::char_traits<wchar_t>,
1> _Alloc=stlp_std::allocator<wchar_t>
1> ]
1> while trying to match the argument list '(vcfex::Cond::MyString, stlp_std::basic_string<_CharT,_Traits,_Alloc>::size_type *)'
1> with
1> [
1> _CharT=wchar_t,
1> _Traits=stlp_std::char_traits<wchar_t>,
1> _Alloc=stlp_std::allocator<wchar_t>
1> ]
1> note: qualification adjustment (const/volatile) may be causing the ambiguity
It puzzles me that the C++ standard ( or is just vc80 ? ) is asking
me to specify const_cast when intuitively the compiler should
resolve the two overloads 'without effort'.
A comment on this after the next point.
I understand what you say at the second point.
I agree but I am really surprised at the same time.
I always considered a const function just as a way to tell the compler that that function is not going to change the 'this' pointer. So I can certainly use it from a non-const function.
This is true. And what you say seems probably true too.
Now I know that this 'const' specifier may affect the overload resolution too.
So at the end it seems that the standard C++ is treating a difference between
const and non-const at the same level as a difference between types completely
unrelated. This, even when the the const specifier is just there to tell that
what is specified as const will not be changed by the function using that instance
( the 'this' or the MyString instance )
At this point I wonder if this is one limit of the C++ ( IMHO of course ),
or if it really necessary to have it like that.
Cheers,
Marcello
|
|
|
|
|
Marcello wrote: So at the end it seems that the standard C++ is treating a difference betweenconst and non-const at the same level as a difference between types completelyunrelated. This, even when the the const specifier is just there to tell thatwhat is specified as const will not be changed by the function using that instance
const isn't just there to portray information to the compiler, it actually changes the type. So char* and const char* are as different (to the compiler) as char* and float . The difference between the two examples is that the compiler has rules for implicity converting between the first pair, but not the second.
So const on a function definition doesn't just tell the compiler that the function doesn't modify any of the class members, it also changes the way the compiler handles ambiguity resolution, as you've found out - because the type of the function is different. Incidentally, this is also why you can have two identical function signatures that differ only in their "constness" - they are different types.
As for your first point, neither of the functions is an exact match, but both of them can be satisfied by implicit conversion rules, so the call is ambiguous. In this case, the first parameter is a MyString& , which matches the second function but not the first, and the second parameter is a MyString::size_type* which matches the first function, but not the second. However, MyString& can be implicitly converted to const MyString& , and also MyString::size_type* can be implicitly converted to const bool& , and the compiler really has no way of knowing which you intended. It has no choice but to flag the ambiguity. Casting either parameter explicitly should remove the ambiguity.
As you have hinted, the VS2005 compiler is much more strict than previous compilers, but it is behaving according to the standard.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
When transmitting these types of values across networks, do I have to consider endianess, or is the IEEE standard defined identically for every platform?
|
|
|
|
|
You need to consider endianess for float/double as well.
I believe the IEEE standard just applies to the break down of bits for mantessa/exponent, bias, ... for a value in raw byte format.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
I have a dialog application and would like to include a logo bitmap...
Anyone know an easy way to accomplish this?
|
|
|
|
|
LCI wrote: ...a logo bitmap...
Are you referring to a splash screen?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|