|
object of class1 is being created inside a function of class2 to set the value of a member of class1 thru' a parameterized constructor of class2 as
class1
{
public:
CString str1;
get();
{
//get str1
}
put()
{
class2 c2(str1);
}
}
class2
{
public:
CString str2;
class2(CString str)
{
str2 = str;
}
}
Thanks,
Kranti
|
|
|
|
|
Kranti1251984 wrote: put()
{
class2 c2(str1);
}
If you are using the same c2 object to access the member function, you will get the value of the variable str2. The object c2 is destroyed once you exit the put() function of class1.
Vini
|
|
|
|
|
In ur case lifetime of the object of class2 is within the class1::put().To check this u can define the destructor of class2 and check it
never say die
|
|
|
|
|
Within class1::put, c2.str2 will be equal to str1, what is the problem again?
|
|
|
|
|
i wanted to use str2 thruough out. It's ok now, solved it by using a member function to set the value in class1.
Thank you all!
Kranti
|
|
|
|
|
Hello,
I have an unmanaged document class in my code, that looks like this
class MyDocument
{
public:
MyDocument()
{
}
~MyDocument()
{
this->CleanUp();
}
bool CleanUp()
{
}
};
Then I have a pointer to it in my Form (that is a .NET managed class, a Form object).
MyDocument *document;
Inside the Constructor of the form, I initialize the document with
this->document = new MyDocument();
The Dispose() function of the Form has the code:
if(disposing && document)
delete document;
During the lifetime of the program, several time i need to free the resouces of the document class and allocated new ones, like this:
document->CleanUp();
However when I close the application (i.e. the destructor of the form runs), I get an error that CleanUp() can't access the memory (because it is not accessible, may be it has been cleaned already).
Could any one please explain why I can call CleanUp() anywhere in my program and I get no error (the memory gets cleaned as expected), and I get a 'Memory Not Accessible' error when I call it from the destrcutor. (I tried to comment out the code in the destructor, and the application gets cured i.e. It produces no errors/exceptions etc.
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
signbit wrote: bool CleanUp() { // Clean all the memory using 'delete' operator }
Make sure you set all pointers to NULL after deleting them.
For eg:
<font color=blue>delete</font> pointer;
pointer = NULL;
Nibu thomas
Software Developer
|
|
|
|
|
Yeah, I always set the pointer to NULL after it's been deleted to avoid confusion, my code looks like:
if(NULL != pointer)
{
delete pointer;
pointer = NULL;
}
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
signbit wrote: Yeah, I always set the pointer to NULL after it's been deleted to avoid confusion, my code looks like:
Try to debug and find out. You should find something interesting.
Set a breakpoint inside CleanUp , and step through.
Nibu thomas
Software Developer
|
|
|
|
|
Pointed Noted I'm trying it out...
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
Why do you need such a code? As far as I remember "delete NULL;" is a valid instruction, that is delete knows about NULL and know how to handle it. Basically, there is something similar to your "if(NULL != pointer)" within implementation of delete, so there is no need for extra one.
|
|
|
|
|
No need to check for NULL before deleting a pointer - it's a benign operation, as free(...) in C.
--
The Blog: Bits and Pieces
|
|
|
|
|
In C++ delete NULL is a NOP - It does nothing. You don't need the if statement in the code above, the following is equivalent:
delete pointer;
pointer = NULL;
If you put the if you're checking twice and the code is longer then need be (more chance of making a mistake).
Steve
|
|
|
|
|
Okay, Okay, but why the destructor can't cleanup?
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
I can't see anything wrong - Can you provide more detail?
Steve
|
|
|
|
|
Hello,
I am creating a Bitmap with the following code:
image = gcnew Bitmap(FreeImage_GetWidth(document->currentImage),
FreeImage_GetHeight(document->currentImage), FreeImage_GetLine(document->currentImage),
System::Drawing::Imaging::PixelFormat::Format24bppRgb,
(IntPtr)FreeImage_GetScanLine(document->currentImage, 0));
Image information (Height, Width, ScanLine0 and etc) is obtained from FreeImage (the open source library I am using for image handling).
When the image is displayed, it displays upside down, can any one tell me what might be the problem, how can I make it correct?
I'll be grateful.
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
If you're using C++/CLI, you have no need of FreeImage, .NET will load all the image formats you're likely to need, and save them too. Windows bitmaps are stored bottom line first. Perhaps FreeImage is inverting them ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Dear Sir,
May be it's inverting it, but is there any cure?
However I still have to use FreeImage, since I am working on an image processing application and all the code has to be in Standard C (so that it can be ported easily), I am using CLR/.NET only because I need a good looking interface.
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
signbit wrote: May be it's inverting it, but is there any cure?
Not short of inverting it back
signbit wrote: all the code has to be in Standard C (so that it can be ported easily),
What, for the 3 people in the world using Linux who pay for software, or the 50 odd who do the same for Mac ?
signbit wrote: ), I am using CLR/.NET only because I need a good looking interface.
That's just silly. You don't need CLR to make your UI look good, they had good looking UIs long before .NET existed.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
A couple of things:
One can make a good interface even in WIN32 API (I have worked on it, and I am sure I can). But we now longer make it, do we? why? we need the ease...
Yes, I am using CLR only because It supports Windows Forms and I can concentrate on core algorithms when I don't have to worry for the UI.
There is a lot of speed difference between Managed and Unmanaged code (MS may have made several gaint steps in improving it's CLR but still it's a layer between You and the processor). If I had luxeries on that, I would have used C# in first place, I am using VC++ because I can access/write the C code more easily here.
There is a chance that the application may have to be burned into some custome hardware (and only C can be burned into HW at this time).
Yes I need to care about those 3 people who use Linux because it doesn't harm me. doest it?
- A programmer's national anthem; "AAAAAHHHHH!!!!"
-- modified at 0:38 Tuesday 28th February, 2006
|
|
|
|
|
signbit wrote: Yes I need to care about those 3 people who use Linux because it doesn't harm me. doest it?
And yet, here you have an issue because you're using third party libraries. An issue that would go away if you were not concerned about cross platform code. So yes, it does hurt you. It costs you time and it costs you options.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
No It doesn't, since if using 3rd party libraries and portable code would have been an issue, we wouldn't have this forum full of messages that target the problems for pure CLR/.NET code. It's just any other problem that I would have been facing during my development.
and does it cost me options? Nah, I have the option of porting my library to any platform I choose, I don't need to stick to Windows, So I have more options...
Anyway, I think I am getting away from the original problem, won't be reply any such messages because It's not a debate.
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
Also, If I use the following code for image creation, it works just fine. But I don't like this code, it's a 4 step procedure and it should be liking the processor very much.
if(image)
delete image;
FIMEMORY *hMem;
hMem = FreeImage_OpenMemory();
FreeImage_SaveToMemory(FIF_BMP, document->currentImage, hMem);
BYTE *pBuffer;
DWORD size;
FreeImage_AcquireMemory(hMem, &pBuffer, &size);
UnmanagedMemoryStream^ memStream =
gcnew UnmanagedMemoryStream(pBuffer, size);
image = gcnew Bitmap(memStream);
FreeImage_CloseMemory(hMem);
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
Windows bitmaps are normally "upside down", but Windows understands normal (upside down) bitmaps as well as "right-way-up" bitmaps - check the MSDN documentation on bitmap headers. As far as I remember, "right-way-up" bitmaps have negative height, so in your code, try changing:
info.biHeight = height; to
info.biHeight = -height; (or whatever the equivalent is in C++.)
I use this technique with a StretchDIBits call, and it works there, but it may not work with all display APIs.
|
|
|
|
|
Dear Sir,
Yup! I know the structure, I tried to trick CLR with that (i.e. negative height), but It didn't work out.
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|