|
Ok, but even in that case I still need to extract that actual name from source file somehow.
So, right now I am thinking about just having some general name for output file after building. Also I will have POST_BUILD action in project settings where some small self-made application will start, it will parse certain source file looking for that #define, extract desired name, and rename resulting output file according to that extracted value.
That seams to be the most straight forward approach 
Thanks for your replys guys,
Mike
|
|
|
|
|
Some topics bellow, i discover a way to pass a pointer to a function etc. That whas great.
But the code is in a DLL, and must be called from a VB6 application.
That's the code:
#######################################
#include <windows.h>
struct tpteste
{
int i;
};
void __stdcall test( tpteste **l )
{
tpteste *t = new tpteste[4];
t[0].i = 99;
t[1].i = 98;
t[2].i = 97;
t[3].i = 96;
*l = t;
}
void __stdcall doNothing( void )
{
tpteste *w = NULL;
test(&w);
}
#######################################
I need to discover how to call the test function from VB.
If someone can help... thanks in advance.
|
|
|
|
|
Sorry about the tags.
And about the place to ask, i had a problem: i looked at the "Message Boards" menu at the top right of the screen and couldn't find a VB6 forum, only VB.NET. But after i looked better and found a VB / VB.NET forum, and posted it there. So, sorry about that too. I'm a newbie here.
If anyone can answer i'd be glad to know, and in the future i will be more careful.
Thanks.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
