Try std::multimap. It does exactly what you want. Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.

Amrit Agr wrote: Please help me with the solution. Exactly what help are you asking for? If you are expecting someone else to write the code for you, I am afraid you have come to the wrong place. And if you have no expertise in this area, why are you being interviewed for such a role? Incidentally, your question has nothing to do with C++/CLI, it is should have gone to C / C++ / MFC Discussion Boards[^].

You may get better help in a product specific forum: Forums | Klocwork Developer Network[^].

Explicit and volatile you need to know, if you are seen using mutable in C++ we put you up against the wall and shoot :-) There are a couple of places you need volatile the two main ones are in multitasking code and interfacing to physical hardware. What volatile tells the compiler the result at that address can change between uses of it ... so it stops the optimizer assuming the value hasn't changed between uses of that address. Imagine the situation you have code that reads the port of a timer at an address. Then you do some other stuff not touching the port address and then you go an read the port again. Now if you are dealing with memory the two reads will have the same value as the code between the two reads didn't touch the port. So an optimizer might well conclude it can remove the second read and just hold the first read value. Only in reality the timer values ticks because it's hardware and so we need the second read to occur it can't be optimized. The same situation occurs in multitasking, memory that our own code didn't touch can change. So volatile is about making sure the optimizer doesn't shortcut stuff assuming just because the code hasn't touched it, that it hasn't changed. So any variable marked with volatile will have any action on that variable not subject to optimization. Explicit is when you want the compiler to stop being smart and convert types for you and pretending it's GWBASIC :-) It used to happen mostly on class/object code that a constructor for example would take a string as a parameter. If you gave it an integer it would automatically know to convert the integer to a string, which is pretty cool sometimes. Other times it leads to a complete and utter bug because you didn't allow for it. So if you tell the compiler you want explicit it turns off the GWBASIC parser and stops the conversion it will throw an error instead. Mutable is one you will rarely if ever need and if you do need it most of us will argue your code is badly organized or you are super lazy and dangerous. The better name for it would be cached or stencil playtime. So you have a constant or someone passes you in a constant, but you just want to change it I mean string "Drive A" is so close to "Drive B". You declare it mutable you can now play around with the constant it wont change the real constant just your local play copy. It's not something to encourage in that usage. The only real valid use of the directive is when you really are dealing with a real cache such as synchronization objects like mutexes &

You could just intercept the DrawItem call and for any empty string simply clear the lpDrawItemStruct->rcRect manually and then pass all the calls thru to the normal drawitem. lpDrawItemStruct has everything you need to know what to draw lpDrawItemStruct->itemID it the string number lpDrawItemStruct->itemState & ODS_SELECTED will tell give you if it is selected or not. lpDrawItemStruct->rcRect is the area to draw in In vino veritas

Thanks David :)

Amrit Agr wrote: Sometimes its getting crash Then you need to use your debugger to try and identify where the crash occurs, and why.

You may want to try this in the C / C++ / MFC forum. This is C++ / CLI.

Hi Amrit, I'll try to explain it with some diagrams. First, the simple case - you probably know this, but I'll show it for completeness. The class Foo has a single member of type int (int32), so it has a size of 4 bytes. # 3 instances of Foo in memory with a Foo* pointer pointing to it: Foo myFoo[3]; // in _tmain(..) Foo* ptr = myFoo; // calling display(..) (I renamed *obj to *ptr here) ptr ptr+1 ptr+2 // the loop in display(..) (100) (100+4) (100+8) | | | v v v Memory address: 100..103 104..107 108..111 // (artificially chosen address) Instance: --Foo1-- --Foo2-- --Foo3-- Members: ---i---- ---i---- ---i---- Now with the class Bar (8 bytes) and your original approach: # 3 instances of Bar in memory with a Foo* pointer pointing to it: Bar myBar[3]; // in _tmain(..) Foo* ptr = myBar; // calling display(..) ptr ptr+1 ptr+2 // the loop in display(..) (100) (100+4) (100+8) // here's why it doesn't work: | | | // ptr is Foo* so ptr+1 still means adding the size of Foo (4) ! v v v Memory address: 100........107 108........115 116........123 Instance: -----Bar1----- -----Bar2----- -----Bar3----- Members: ---i---___j___ ---i---___j___ ---i---___j___ Value: 0 1 0 // and there's your strange output! ;-) And now with pointers to pointers. Let's say we're on a 32bit-system here, then a pointer has the size of 4 bytes (32 bit). So, when doing pointer arithmetic with pointers to pointers, adding 1 means always increasing its pointed-to-address by 4 bytes. It doesn't have anything to do with the size of the class that's being pointed to by the pointer that's being pointed to :-D # 3 instances of Bar in memory with a Foo** pointer pointing to Bar* pointers: Bar myBar[3]; // in _tmain(..) Foo *myBaz[3] = { &myBar[0], &myBar[1], &myBar[2] }; Value: 100 108 116 Foo** pptr = myBaz; // calling display2(..) (for clarity, I named it pptr here) pptr pptr+1 pptr+2 (200) (200+4) (200+8) // see explanati

XOR swap algorithm[^] X := X XOR Y Y := X XOR Y X := X XOR Y But you cannot do this with pointers as compiler does not allow XOR operation on pointers, you have to cast pointer to integer(32bit ptr to 32bit integer and 64bit ptr to 64bit integer) beforehand. This is a favourite interview question among some interviewers (who apparently read the same interview book).

here, p is a pointer to int*.that means p can point to an int pointer and that pointer will point an int type of data. when you do this , (int**) new int (5) ; you are actually forcing (casting) p to point to an int pointer (memory address) with value 5 ..(It actually should not be done because you don't know anything about memory address 0x5 )... however and as you made p to store something(a memory address with value 5) you also allocated memory for that purpose ...... and the typecasting was necessary as first case is very different than the second case.... in the second case --- ap is an int pointer and with new command you allocated 4 bytes of memory for ap .. and ap is now pointing to that memory location and as you passed 20 in the constructor so now that memory address is storing 20.... But, p is not an int pointer ..it's a pointer to int pointer ...so it should be passed a valid memory address in the constructor call .. not an int(what you did -- by passing 5)..that's why you had to cast... and the answer to your last question is ... p is just a pointer (it maybe a pointer to another pointer but it still is a pointer)..and when we want to know what value a pointer is pointing to we put * (deference op.) before that pointer (only once)! Hope,you got that :-D

Thank you! :)

I just tried without including math.h and it works fine. Try seeing what the actual definition of sqrt is when you have not included the header. Use the best guess

Thanks a lot Rechard.. for the clarification

Hi, This is possible, when the file mentioned is not present in the corresponding path or the file name is wrong you get the file handle as -1. And its crashing because, you are trying to close a invalid file handle in close() api.

void main() { int Var = 90; if(Var += (((Var == (++Var)) == 89))) printf(" %d ",Var); } Operator precedence: 1. Increment operator (++) 2. Relational operator (==), and its Associativity is Left to Right 3. Assignment operator (+=) Hope it helps...:thumbsup:

Use Spy++ to see what styles that control has. "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous

Hi, Amrit, It's working because it's legal to overload functions based on whether the argument refers to a const or non-const type. So, void display(const char*) //pointer pointing to a const type is overloading void display(char*) // plain pointer And you're correct. The following couldn't be overloaded. It won't compile because of const conversion used by compiler. It can't figure out which one is the best match. void display(char); void display(const char); void display(char const); (Technically, the above are redeclaration. It's fine to just define the third one by adding function body. But it won't compile if all of these three functions have function bodies or definitions.) By the way, to be clearer, the following won't compiler neither because of the same reason. void display(char*){...} //plain pointer pointing to a regular type void display(char* const){...} //const pointer pointing to a regular type

Try it[^] in your own control's rendering... :) They sought it with thimbles, they sought it with care; They pursued it with forks and hope; They threatened its life with a railway-share; They charmed it with smiles and soap. :)