|
I have a CMap that does a mapping between <cstring ,="" cmyobj="" *="">
This map is populated by reading a file ( line by line ) and CMyObj is constructed from information in that line .
So the logic is something like
Map<string, cmyobj="" *=""> map ;
while eof
{
line = readline
string key = line.FirstToken
CMyObj *p= new CMyObj(line)
map[key] = p ;
}
Now I am modifying where p is going to be allocated from Virtual memory instead of heap
Unfortunately i will need to be able to reconstruct this object based on address
Hence when i do the lookup the map will only give me the address but the size is not available as
is there a mechanism that I can use to decide the size and transparently recreate the object from virtual memory ?
Engineering is the effort !
|
|
|
|
|
act_x wrote: Now I am modifying where p is going to be allocated from Virtual memory instead of heap
I don't understand why or what you want to do ?
|
|
|
|
|
act_x wrote: Now I am modifying where p is going to be allocated from Virtual memory instead of heap
and i'd be curious to know how you do that
|
|
|
|
|
All memory in user mode programs is virtualised. The heap is in virtual memory. The heap is build on top of virtual memory. You can only allocate virtual memory in 4k chunks (on x86 platforms): the heap is a data structure to minimise the waste by carving up a virtual memory chunk into pieces to serve requests smaller then the page size.
Steve
|
|
|
|
|
hi
i've an application that installs some files to application folder in program files.a user with limited rights are not able to access that files. but every user wants thats files for modification. it was working properly in xp as program files is not restricted to the administrator. but in vista program file is a restricted area.how can i solve this problem.
thanx in advance
|
|
|
|
|
is this a programming question related to VC++ ?
otherwise if you need some administration, ask the Operating System or Vista Forums...
|
|
|
|
|
I would redesign the way your application set up files.
if this is a single user application, and the "files" are will only be used and modified by one user ( and not shared betweeen other users) use the APPDATA folder ( Document And Settings\<user>\Application Data\ ... )
|
|
|
|
|
The answer is simple but you probably won't like it: Don't write to Program Files. You have a design flaw in the app which has been ignored (or at least was not evident) until now.
|
|
|
|
|
Consider the following code :
vector<int> *testVector = new vector<int>();
testVector->push_back(1);
int &testRef = (*testVector)[0];
cout << testRef << endl;
testVector->clear();
delete testVector;
cout << testRef << endl;
How can i detect that the reference has become invalid ?
|
|
|
|
|
best practices teach to NULL a pointer you just delete...
delete testVector;
testVector = NULL;
what i suspect you was to expecting the last cout to print 0x00000000.
but delete frees the memory pointed to by the pointer, nothing much.
|
|
|
|
|
That is not the problem. I don't even reference the pointer. I reference an element of the vector that has been destroyed. I could leave the delete on the vector and it would still print nonsense. The reference to the integer stored in the vector has become invalid. I have this problem because i need to implement a wrapper for a map on wich multiple threads can operate concurrently, inserting, reading and deleting. Now one thread could delete an element another thread is currently working on. Since the objects are managed by the map itself i cannot find out when that happened.
|
|
|
|
|
what do you mean by "print non-sense" ? what do you expect ?
[edit]
oh, my bad, i read your post incorrectly (i read that you were printing out the address in the testVector pointer).
AFAIK, a reference cannot be changed of address, so by clearing the vector, then deleting it, you invalidate the reference. the only way you have to know the reference may be invalid is not writing such code.
i don't think we can know otherwise
BTW, it seems that you need some synchronizing code around your vector... one should not read it until another thread finished to modify it, and such references being temporary shouldn't be stored
[/edit]
|
|
|
|
|
Synchronization is of course neccessary (bad seplling ?!), but i want to keep it minimal, since too much synchronization can make a multithreaded application almost sequential, this voiding the advantage of multithreading.
It is also correct that the reference should not be stored, but experience tells us, that users always do whatever it takes to crash a program, or the library in that case. So i try to keep my code bulletproof.
My approach now is to write a wrapper-class that behaves like a reference, but checks on every access weather the elemennt/vector actually still exists. I'm not sure though if that is the smartest way to do it, it seems like a waste of resources.
|
|
|
|
|
Mr.Brainley wrote: but i want to keep it minimal
don't keep it "minimal", keep it efficient. if you have too much synchronization, then there may have a design problem.
for your vector, the need of the mutex is pretty neat...
|
|
|
|
|
Mr.Brainley wrote: I reference an element of the vector that has been destroyed.
This would be impossible if you had assigned NULL to the pointer after deleting it.
It's a two-step process. Assign NULL to the pointer after deleting it, and check if the pointer is equal to NULL before referencing it.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
A try/catch around the dereference would do it, but it's cumbersome to have many of those throughout the app. In C++, it's your responsibility to not do that in the first place. 
|
|
|
|
|
Michael Dunn wrote: A try/catch around the dereference would do it, but it's cumbersome to have many of those throughout the app. In C++, it's your responsibility to not do that in the first place.
I don't think it would (do it). This approach is dangerous. The memory manager could have reused the address that used to contain the vector's contents after the vector has been destroyed. This technique can not be relied upon.
Steve
|
|
|
|
|
Mr.Brainley wrote: How can i detect that the reference has become invalid ?
You can not; a reference just refers to a memory block that is expected to contain data of a given type (the referenced data type). It is up to you, the programmer, to insure that the memory block is valid, as the language does not provide that for you.
If there is a chance that the memory block will become invalid without you knowing it, bad design, then you could try using one of Microsoft’s “IsBad…” functions to check the address referred to by the reference: IsBadWritePtr(&testRef,sizeof(int)). This method, of course, may not work if some other piece of code has allocated that same memory block between the time you freed it and the time you checked the address pointer; which will lead to very hard to find bugs.
Another thing I would like to point out is that just adding another item to the ‘vector’ can cause your reference to become invalid if the ‘vector’ had to reallocate memory in order to expand the memory block size.
Basically, any reference, of the type you provided, should be temporary and only exist in local scope. It should not be ‘static’ or ‘global’, unless the memory it refers to is not released until the application exits.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
The best solution would be not to get in this situation. There are other solutions however. For example you could construct a container based on a std::vector that uses something like Boost's Shared Container Iterator[^] and use iterators instread of usig ponters. Other smart pointer based techniques are also possible. A std::vector as it stands is not designed for this usage pattern (and doesn't pay the price that implementing it incurs).
Steve
|
|
|
|
|
Mr.Brainley wrote: How can i detect that the reference has become invalid ?
You can't.
BTW, vector objects are not meant to be created on the heap.
|
|
|
|
|
I'm porting an old app that was created in VC6 in C-code to VS2005 C++ code. This is an api app that hits a shared lib for interaction with the main app. As soon as I change from C to C++ and build, I have unresolved externals... change back and it builds fine... I've added the project dirs (include and lib), maybe missed something else?? Any ideas?
This seems to apply to functions from the shared lib, as well as other c-coded functions in the solution:
gen_geo.obj : error LNK2019: unresolved external symbol _rabs referenced in function _make_bbox
Thanks
|
|
|
|
|
Sometimes just stating a problem helps you fix it...
A good ole' extern "C" {} around the api #includes did the trick
Thanks for allowing me to waste your time
|
|
|
|
|
 A stated problem with a good solution is never a waste of our time, in my opinion. If they have not already, then one of the guys who likes compiling solution faqs will include this.
Good work!
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Hello,
I have an OCX that works on the PC built with VS6.0. It registers correctly and can be used to write more C++ applications with it.
The OCX has been ported to Embedded platforms(PPC 2003 SE). It builds via eVC++ 4.2 with 0 Error(s) 0 Warning(s) for PocketPC 2003 SE for the processor I'm using. The "build" output-window says it registers correctly. I'd love to say it works; however, I can't prove it.
Both IDE's say it registered correctly.
Here's the problem:
I open the eVC project I'm going to be using this OCX with. I go to Project->Add to Project->Components and Controls and attempt to add control - my shiney new OCX. (I imagine that eVC desires the embedded OCX vs the PC OCX - though, admittedly, I've tried them both.)
Every time I try to add the control I get the following message:
"Failed to find desktop version of control in registry. Please verify that this control has been successfully registered on the desktop."
So, I ask, what am I doing wrong here?
|
|
|
|
|
 ~!^)&*(^!@#)&*^~
I found several problems.
First problem was PEBKAC. I was navigating to the build output directory of the ActiveX control and not the registered components directory one would find their registered controls in. But, why would I do that, you ask? Well, every time I navigated to the registered controls directory, it was empty. Which leads me to the second problem.
eVC defaults the developer to the 'Registered ActiveX controls' for the embedded development directory:
C:\Program Files\Microsoft eMbedded C++ 4.0\Common\EVC\Gallery\Registered ActiveX Controls
It *wants* the PC's! 'Registered ActiveX Controls' directory.
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Gallery\Registered ActiveX Controls
Is it just me or is this counter-intuitive?
So, I navigate there. It too is empty....huh!?
Thirdly, eVC doesn't (or, isn't, on my PC) displaying the Visual Studio 'Registered ActiveX Controls' directory *unless* VS6 is open and is being 'fooled' into thinking someone is trying to 'add a Component or Control' for a VS6 project.
So, there you go. I'm totally disgusted.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
