|
Ok, good, then i can write some cleaner code.
Things like this return value of insert( value_type(key, T())). make my head hurt. 
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
_Magnus_ wrote:
Things like this return value of insert( value_type(key, T())). make my head hurt
This behavior is by design 
Tomasz Sowinski -- http://www.shooltz.com
Free your mind and your ass will follow.
|
|
|
|
|
_Magnus_ wrote:
If it is undefined, what use is the [] operator really?
i have no idea. i always use the long form:
myMapIterator it = myMap.find(value);
if (it == myMap.end())
{
not in the map
}
no question about the meaning of the return code.
-c
Aiei i ea eio aoa i e eio e aigoa
|
|
|
|
|
I have always done it like that to since i was unsure of the [] operator, but i rather use the [] operator since the code will look cleaner.
/Magnus
- I don't necessarily agree with everything I say
|
|
|
|
|
Don't forget that the index has now been added to the map i.e. the map size has increased by one. In the case you outline this may not be significant but it can be significant in other cases as the map may grow in an uncontrolled manner.
|
|
|
|
|
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?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
