|
Yeah, I remember now. This buffer overrun detection is new in VS.NET isn't it?
I don't do buffer overruns... 
--
They're out get me, I can't escape cos' they won't let me
They won't forget me, they'll get me in their grip and sweat me
They'll wait me out, and then move in under my skin
They'll make me doubt, they're out to make me let them in
|
|
|
|
|
|
Ah yes. 0xfefefefe, 0xcdcdcdcd IIRC correctly. I use this values every time when I debug but I never reflected on that the compiler adds padding information. Thanks for the info 
--
Here we come, reach for your gun
And you better listen my friend, you see
It's been slow down below,
Aimed at you, we're the cowboys from hell
|
|
|
|
|
Jörgen Sigvardsson wrote:
I don't do buffer overruns...
Yeah yeah yeah, riiiight! 
Rickard Andersson
Here is my card, contact me later!
UIN: 50302279
Sonork: 37318
|
|
|
|
|
Actually it's been quite a while since I had such problems. Mostly because I'm a) vigilant, and b) I use proven classes which handle all low level operations such as memory allocation and stuff.
Most of the troubles I've had recently have been reference counting on COM-interfaces. Actually, the last such a problem was not introduced by me, but by a colleague. I guess I'll fix that tomorrow, so that the damn out-of-proc server may terminate properly
--
Here we come, reach for your gun
And you better listen my friend, you see
It's been slow down below,
Aimed at you, we're the cowboys from hell
|
|
|
|
|
Cool! Thank you so much for that information!
Rickard Andersson
Here is my card, contact me later!
UIN: 50302279
Sonork: 37318
|
|
|
|
|
Michael Dunn wrote:
Ericahist [updated Oct 26]
The new red-shirt pics look very similar to the bright blue pics.. Especially the "surprised!" look ones... Is that intentional?
And now I've got to add 2 more pics to my collage... 
The kindest thing you can do for a stupid person, and for the gene pool, is to let him expire of his own dumb choices.
[Roger Wright on stupid people]
We're like private member functions
[John Theal on R&D]
We're figuring out the parent thing as we go though. Kinda like setting up Linux for the first time ya' know...
[Nitron]
|
|
|
|
|
No, not intentional. I just take some screen caps as the show plays, then I go back after the show's done and pick out the nicest-looking ones.
--Mike--
Ericahist [updated Oct 26] | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer.
-- Michael P. Butler in the Lounge
|
|
|
|
|
Michael Dunn wrote:
No, not intentional. I just take some screen caps as the show plays
Ok... so I gotta get in on this. When, Where? So I don't have to be a beggar to your screencaps. ;P
The kindest thing you can do for a stupid person, and for the gene pool, is to let him expire of his own dumb choices.
[Roger Wright on stupid people]
We're like private member functions
[John Theal on R&D]
We're figuring out the parent thing as we go though. Kinda like setting up Linux for the first time ya' know...
[Nitron]
|
|
|
|
|
It's not magic or anything. I use WMP 9 and turn off video acceleration (otherwise a screen cap wouldn't capture the video window). Then I set up Paint Shop Pro to do multiple screen captures with a hotkey (F11 or something like that). Then I watch the show 
--Mike--
Ericahist [updated Oct 26] | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
Pinky, are you pondering what I'm pondering?
I think so Brain, but if we shaved our heads, we'd look like weasels!
|
|
|
|
|
You could use _stricmp() instead. That way you don't have to allocate a new string.
for(int i = 0; i < m_nCount; ++i) {
if(_stricmp(keyword, m_pStack[i]) == 0) {
ret = i;
break;
}
}
--
They're out get me, I can't escape cos' they won't let me
They won't forget me, they'll get me in their grip and sweat me
They'll wait me out, and then move in under my skin
They'll make me doubt, they're out to make me let them in
|
|
|
|
|
You made my Find() method much more sexy now, you know that?
Rickard Andersson
Here is my card, contact me later!
UIN: 50302279
Sonork: 37318
|
|
|
|
|
Screenshots! Screenshots! 
--
The coolest game in the world: NHL Hockey[^]
|
|
|
|
|
While applying SP5 to Visual Studio 6 I repeatedly received an error, to the effect of "C:\Windows\System32\MSVCP60.dll could not be opened" yet when the installation was complete it reported that SP5 had been successfully installed. Since this is the updated (for VS6) C++ Runtime Library, should I be concerned? Searching shows that there are 4 copies of this dll on the C: drive, all of the same version, but none exists in ...\System32\. Should I ignore it, or make a copy and drop it in the System32 folder? Or is this just an error on the part of the installer program, looking for a file on C: even though I specified a different installation location? The correct version does exist in ...\vc98\redist. Thoughts, anyone?
"Your village called -
They're missing their idiot."
|
|
|
|
|
Sounds like some other application had the file locked. I'd be tempted to go ahead and try replacing it manually, probably with a reboot beforehand. Good luck.
Software Zen: delete this;
|
|
|
|
|
Why can't I remove the window style WS_CLIPSIBLINGS? If I remove this style using ModifyStyle, it will be there again afterwards. Why?
|
|
|
|
|
According to the MSDN, WS_CLIPSIBLINGS can be specified when the window is created, but not modified.
Software Zen: delete this;
|
|
|
|
|
So, if I want to create a WS_CLIPSIBLINGS-less dialog, I must use CDialog::Create or something like that.
But Create is not called in the sourcecode generated by VC++, or is it?
|
|
|
|
|
You can specify WS_CLIPSIBLINGS in the resource for the dialog; it should be one of the options in the dialog's properties.
My point was that you can't turn WS_CLIPSIBLINGS on and off dynamically.
Software Zen: delete this;
|
|
|
|
|
The resource editor indicates that WS_CLIPSIBLINGS is NOT activated (Properties, Tab Styles, Check button "Clip Siblings" is not checked).
Then why does Spy++ (my code too) indicate that the dialog has WS_CLIPSIBLINGS?
The only way to set/reset that style is the resource editor, or I should create it using Create(...) with or without that style. Is that correct?
|
|
|
|
|
If I have an array of pointers to objects (class objects created using "new"), are the state of those objects preserved? IOW, if certain values existed in an object at the time it was placed in the array, will those values still exist when next the object is accessed from the array?
Several of those objects are created at various times and places in the program, and are subsequently accessed at various times and places as well.
Some of the items in the objects include STL container objects, pointers and other arrays with data in them.
In case someone might think that the array of objects to which I'm referring is an array of objects of the same type, that is not the case. I am referring to an array of pointers to objects (i.e. pointers to various objects of different types which inhabit the array). This, however, is besides the topic of my question which seeks to determine if object state persist.
Thanks for any insight in this matter.
William
Fortes in fide et opere!
|
|
|
|
|
WREY wrote:
If I have an array of pointers to objects (class objects created using "new"), are the state of those objects preserved?
So long as the array hasn't gone out of scope, then yes your objects have been preserved. If they have gone out of scope you have a memory leak, and the memory you are writing / reading to or from may or may not contain your objects - you should assume it doesn't! Sometimes running in debug mode can hide things like that.
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
Scope shouldn't be an issue, because the objects were created using "new", which means you are responsible for deleting them in the end.
Memory leaks are more what I fear.
William
Fortes in fide et opere!
|
|
|
|
|
Since the individual objects pointed to by the array elements are allocated from the heap, they persist until they are deleted. If the array destructor doesn't delete the objects pointed to by its entries, then the objects will survive the array's destruction. (Sounds dramatic, doesn't it  ).
Software Zen: delete this;
|
|
|
|
|
The question is not whether the objects themselves persist, it is whether the "state" of the objects persist.
I know it's my responsibility to call the destructor of each object in the end. So I know the objects are going to persist until I delete them individually. My real concerns are with the state of the objects with regards to the values they contain.
IOW, it is pointless to think every member variable of an object will be "const", or created on the heap, or of 'static' storage type. But when you're dealing with other aspects of C++ like STL, they have their own modus operandi.
William
Fortes in fide et opere!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
