|
scrib wrote:
I use different file names to prevent problems in trying to overwrite a currently running exe.
MoveFileEx(..., MOVEFILE_DELAY_UNTIL_REBOOT) will help here.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
An alternative would be a separate app that performs the updating and terminates the 'parent' app prior to performing the update. Many games use this tactic.
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
Hi,
Can anyone tell me if the VC++ Memory debug window displays memory LSB->MSB?
I have a buffer that should be :
80 00 00 00 40 00 00 00 00 00 00 00 80 00 00 00 20 00 00 00
but is displaying as
00 00 00 80 00 00 00 40 00 00 00 00 00 00 00 80 00 00 00 20
If I change the view to long hex format, it looks better but still isnt correct.
It also seem that if I write two consecutive U16s, then the first is in the lower 2 bytes and the second is in the uppoer to bytes for a 4 byte sequence.
I simply need to confirm that my memory buffer contains the correct order of bytes. If the VC++ memory window displays is LSB-MSB, I just want to confirm that.
Thanks.
-C
PS - Can anyone tell me why I'm getting a memory access violation for the last line of the following statement
msgBuffer = new char [100] ;
memset (&msgBuffer,0, 100);
memcpy (&msgBuffer,(char *) &ui , sizeof (ui));
msgBuffer [99] = '\0';
|
|
|
|
|
The memory window displays data sequentially. On Intel-style machines that would mean that it is LSB first.
On your memset calls, lose the the & on msgBuffer. It should be :
memset( msgBuffer, 0, sizeof( msgBuffer ) );
This is because the & means use the address of the pointer. You want just the pointer.
The point of all of this is to remove usage of literal constants. The reason is that if you need to bump that size to 200 then you would have to make changes in three places to accomodate that. That is a bad thing.
Also note that this is not ready for Unicode. That requires a different set of macros that calculate the size in characters, not bytes.
[edited - all wet]
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
Rick York wrote:
memset( msgBuffer, 0, sizeof( msgBuffer ) );
I guess you made a small unknown mistake, msgBuffer is a pointer so sizeof(pointer) will return 4 .
God is Real, unless declared Integer.
|
|
|
|
|
Quite right ! That'll teach me to answer questions on a Monday morning.
Never mind. 
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
So my buffer will be displayed LSB first in the memory window, if I print it out, it should show how I want it to be right?
But when I try to do
for (int i=0, i< 100; i++)
printf ("%X", msgBuffer[i]);
I keep getting memory access errors.
If I cant look in the memory window or print it out, how can I verify my buffer.  Any ideas?
-C
|
|
|
|
|
msgBuffer = new char [100] ;
Sets msgBuffer to the address of a an array of 100 characters. Fine.
memset (&msgBuffer,0, 100);
Overwrites the value of msgBuffer from the address of the array to 0, and then overwrites another 96 bytes with 0. Very wrong.
After that almost everything will fail sooner or later.
If you display in 'bytes' then the memory window will show a value of 0x04030201 as
01 02 03 04
IOW LSB first.
Paul
|
|
|
|
|
why are you bothering to allocate a new msgBuffer ?
Why not use a stack variable for this ?
or a declared member variable ?
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
Regardless if I use a stack variable or a member variable, I have to create it, initialize it, and copy my data into it. I'm at the beginning stages of writing a device driver sending msgs back/forth serially. So I'd like to verify now, early in the development, that I"m creating my buffers correctly.
I've realized that I need to byte swap my shorts and longs so that the buffer is properly sent.
Thanks for all the assistance and corrections.
-C
|
|
|
|
|
Hello. When I write something like:
---
class test{
public:
CBrush f;
};
int main()
{
test t;
vector<test> hej;
hej.push_back(t);
}
---
I get an error in <vector>: ...\include\vector(575): error C2440: 'initializing' : cannot convert from 'const test' to 'test'
But if I replace CBrush with one of my own classes, i everything works fine! What is it with those MFC classes?
|
|
|
|
|
I would say the copy constructor
anyway its better to store a pointer to your class
try:
vector<test*> hej;
hej.push_back(&t);
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
How smart is it to store a pointer if the object you added to the vector goes out of scope?
I know that isn't the case right here, but generally speaking...
|
|
|
|
|
if it will goes out of scope just new it first
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
Why did you want to use a pointer in the first place? What is the advantage?
|
|
|
|
|
For various reasons:
Parameter passing to a function of objects is always better by pointer or by reference, the copy time is smaller and faster.
and the allocator of your vector is faster too because you wouldn't reallocate data or allocate chunks often.
and much more too like copy modifications ...
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
But i'm not looking for speed-improvements. I just want to know why the code i posted doesn't work. MUST I use pointers to make it work ?
|
|
|
|
|
Using pointer will settle this for you.
if you dont want to having a copy constructor will do
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
pie wrote:
How smart is it to store a pointer if the object you added to the vector goes out of scope?
If the object was allocated on the heap, it won't go out of scope per se. It will still exist until delete is called. In other words:
void MyClass::SomeFunction( void )
{
SomePtr *ptr = new SomePtr;
m_vector.Add(ptr);
}Even though ptr goes out of scope, the memory that it points to is still alive and well.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Do you have all the necessary #includes in place?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I have:
#include <afxwin.h>
#include <vector>
using namespace std;
|
|
|
|
|
No compiler errors with this:
class test
{
public:
CBrush f;
test();
test(const test& t);
~test();
const test& operator=(const test& t);
};
void main( void )
{
test t;
vector<test> hej;
hej.push_back(t);
}
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Yeah, that seems to work.. Thank you(and Navin) 
|
|
|
|
|
You probably need to define a copy constructor for your class.
E.g.,
class test
{
public:
test(const test &src);
CBrush f;
};
test::test(const test &src)
:f(src.f)
{
}
Then try it and see what happens. (Note, just a guess, I didn't actually try to compile this.)
Sometimes I feel like I'm a USB printer in a parallel universe.
|
|
|
|
|
Objects that can be stored in std:: containers must be copyable, and copies must be equivalent. This isn't the case with CBrush. Even if you arrange a copy constructor such that the object being copied to takes ownership,
test ( const test& t)
{
f.Attach ( t.f.Detach ()) ;
}
you haven't met the 'equivalent' condition since the new object owns the Windows Brush and the old one no longer does. In your example if 't' was initialised with a valid brush after the push_back would no longer own it.
The copy constructor above won't compile because the argument 't' is const and we're trying to modify it with 'Detach', sound familiar?
In these circumstances it is appropriate to store a container of pointers and manage the destruction of the contained pointers manually.
Paul
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
