|
Yes, i am aware of that, but as you said it does not really matter in this case.
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
It may "look" cleaner, but I would agree with Chris, using the long is MUCH clearer as too what is actually going on.
For example if you have
map<int,fooobject*> fooMap
what will
FooObject* foundFoo = fooMap[3];
actually be ?
I would expect that foundFoo would be NULL if there is no entry for the value 3, but is that what will actually happen ?
If you use the long form, it is a couple more lines of code, but you KNOW exactly what will happen - no guessing.
|
|
|
|
|
In this case i have a map with rightbits and i think that
if(map[i] & bit)
is cleaner than
iterator it = map.find(i)
if(it != map.end())
{
if((*it).second & bit)
}
But it might depend on what is in the map.
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
But operator[] adds an element to the map if it's not there - it's not the exact equivalent of longer version.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Jim Crafton wrote:
would expect that foundFoo would be NULL if there is no entry for the value 3, but is that what will actually happen ?
Yes, it will happen. Check with the following function template:
template <class T>
void test(T t = T())
{
T t2 = t;
}
...
test<char *>();
test<int>();
test<int>(5);
And put the breakpoint inside test. T() where T is simple type like pointer or int results in value initialized to zero.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Cool, excellent ! This is a standard for how implementers must implement a map? So we can count on this behaviour?
|
|
|
|
|
You can count on proper behavior of T() when T is simple type. This applies to this map situation.
To have even more fun, check the following declarations - they'll work:
int i = int();
typedef char *pchar;
pchar pc = pchar();
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
So simple types (int, float?, double, char etc) are all initialized to 0 ? Very cool but I had always been told that C/C++ did not initialize primitive types, although I suppose this case is a bit different.
Good to know anyways ! Thanks
Do you know if this works on GCC ? I take it that it is part of the C++ standard right ?
|
|
|
|
|
Jim Crafton wrote:
So simple types (int, float?, double, char etc) are all initialized to 0 ?
Not exactly. When you're declaring an int without initializer, you'll get random bits:
int x;
However, you can initialize variable with constant, or with this pseudo-constructor syntax:
int x = 5;
int y = int();
int z = int(3);
Jim Crafton wrote:
I take it that it is part of the C++ standard right ?
I guess it is. Otherwise standard containers would have hard time working with ints and doubles. In the STL sources there are many T t = T() constructs which have to work OK with simple types.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
My company has a code library (dll) we release to customers. We'd like to only release the RELEASE version and not the DEBUG version to the customer. The problem is that one of the classes in the library automatically deletes some classes that can be allocated by the customer using the library with new.
When the customer links to our RELEASE builds within his DEBUG build it causes exceptions like "Invalid Address specified to RtlFreeHeap".
I assume that it's because the customer allocated an object with new in his DEBUG code and we free'd it with delete in our RELEASE code.
I know there has to be a way to handle this as I'm sure alot of companies sell RELEASE ONLY dlls to customers. How is this accomplished to allow the user to build DEBUG versions against your release DLLs?
Another note is that the DLL is a non-MFC dll which is linking to an MFC app usually.
Thanks for any help.
|
|
|
|
|
If your design requires freeing things allocated in customers code, you have to provide both debug and release build. And - your customers are forced to use DLL version of C runtime.
You may consider exposing some allocator object or allocating objects at the .dll side.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
You could get your users to build in release mode but use debugging info in their app so its almost the same as regular debugging.
Roger Allen
Sonork 100.10016
I think I need a new quote, I am on the prowl, so look out for a soft cute furry looking animal, which is really a Hippo in disguise. Its probably me.
|
|
|
|
|
i'd never use a library that made me do that.
-c
Aiei i ea eio aoa i e eio e aigoa
|
|
|
|
|
Well, its only a suggestion.
Roger Allen
Sonork 100.10016
I think I need a new quote, I am on the prowl, so look out for a soft cute furry looking animal, which is really a Hippo in disguise. Its probably me.
|
|
|
|
|
do your customers have to use the objects allocated inside your DLL? some of my DLLs allocate objects and pass them back to the caller, but the caller never has to do anything with the object, except pass it back into the DLL. also, i always pass the objects back as "void *" so there's never even any temptation by the caller to do anything with the object. any manipulation and clean-up of these objects is handled by functions inside the DLL, so there's no chance of mixing debug/release code.
-c
Aiei i ea eio aoa i e eio e aigoa
|
|
|
|
|
Yes, they do.
The problem area is a custom linked list we've implemented that holds pointers to custom objects. The users allocate the custome objects then add them to the custom linked list. This custom linked list automatically cleans up the objects they allocated when the list goes out of scope.
So, they may or may not use the object that they allocate.
|
|
|
|
|
Are custom objects derived from common base class defined in your .dll? If this is the case, just add abstract Delete() method. Trivial implementation in users's code just calls 'delete this'.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
That's the problem. The user can't delete the object as the list does it for them. The user allocates the object, but NEVER deletes it. The list does.
|
|
|
|
|
The trick I've described in previous post would work. The only prerequisite is that objects in the list are derived from class defined in .dll.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Ahh, I think I get it.
Yes, all the custom objects are derived from a base class that's in the DLL.
So, You're saying that I can just override the ::delete operator in the base class. That way the object is always deleted from the DLL?
Is that correct?
|
|
|
|
|
SchmoBoy wrote:
You're saying that I can just override the ::delete operator in the base class
Actually, I wasn't referring to this solution. I'm not sure if you can achieve your goal with overriding delete operator (note that you'd have to override new as well). Give it a try, if it's not possible, consider the following:
I'd add special abstract method in base class:
class BaseClassInDll
{
public:
...
virtual void DeleteMe() = 0;
};
Your list would call obj->DeleteMe() instead of delete obj. Users of your .dll would have to provide the implementation of DeleteMe. Implementation is trivial, it's just 'delete this' statement:
class DerivedInExe : public BaseClassInDll.
{
public:
...
virtual void DeleteMe() { delete this; }
};
Basically, this provides sort of callback into EXE available from DLL.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Well, Tomasz headed me in the right direction...
The solution is to overload the ::new and ::delete operators so ALL memory allocation and deallocation are routed through the DLL. In the base class I simply added the following functions. Note the three parameter new and delete are required as MFC uses these calls for tracing, etc. So I just included both to work with and without MFC/Win32.
<br />
void * CMPI_Obj::operator new(size_t sizeofRow)<br />
{<br />
void* p = new char[sizeofRow];<br />
<br />
return memset(p, 0, sizeofRow * sizeof(char));<br />
} <br />
<br />
void * CMPI_Obj::operator new(size_t sizeofRow, LPCSTR lpszFileName, int nLine)<br />
{<br />
void* p = new char[sizeofRow];<br />
<br />
return memset(p, 0, sizeofRow * sizeof(char));<br />
} <br />
<br />
void CMPI_Obj::operator delete(void *ptr)<br />
{<br />
::delete ptr; <br />
}<br />
<br />
void CMPI_Obj::operator delete(void* ptr, LPCSTR lpszFileName, int nLine)<br />
{<br />
::delete ptr; <br />
}<br />
<br />
Thanks for everyone's help and suggestions. I think I've found the most elegant solution where we can still JUST ship RELEASE and the customer can still build DEBUG against it.
|
|
|
|
|
I don't have any reference book at hand right now, but make sure you have operator new for arrays as well.
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
Yes, you are correct. new[] and delete[] are needed. I forgot those in the code snippet above.
|
|
|
|
|
could you make them provide a callback function for your DLL to use that would handle de-allocation?
ie. they write a function that like this:
BOOL CALLBACK MyFree(Object *p)
{
delete p;
return TRUE;
}
and your code would do:
// time to delete this
(*CallerFree)(pObject);
that way, the delete used will always be the correct one.
-c
Aiei i ea eio aoa i e eio e aigoa
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
