Re: [hlcoders] CUtlVector<*>... Memory management?
http://www.valvesoftware.com/publications/2008/GDC2008_CrossPlatformDevelopment.pdf Explains it really well. On Mon, Jun 2, 2008 at 5:40 PM, Mike Blaszczak <[EMAIL PROTECTED]> wrote: > It's not that the OS isn't capable of memory management. It's that the > application can do better than the OS in many cases. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, May 31, 2008 17:32 > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > There are only a few sections where the gains were at all significant. > Rather than a divergent library they probably could've realized a few > optimization patches and gotten the same benefit. The thing I don't > understand though is why so many software companies to this day still > try to do so much low-level memory management themselves, as if the OS > was incapable of it. It's not just gaming software either: case in > point, Firefox and its insane memory management that bloats to using > hundreds of megabytes over time. > > Paul Peloski wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > In the algorithms they made some significant gains on Windows and > Xbox, but > > not so much on Mac and Linux. I guess libstdc++ is faster than > Microsoft's > > STL implementation. Since a lot of games will target Microsoft > platforms I > > guess it was a good move to rewrite their STL implementation. > > > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > > equivalent operations using STL. > > > > Regards, > > > > Paul > > > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> > wrote: > > > > > >> That is a really interesting article. How did you find it? > >> > >> Also, they do have some performance benchmarks buried at the bottom: > >> > >> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appen > dix_20<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_20> > >> > >> Nate > >> > >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> > >> wrote: > >> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] > >>> Interesting, thanks for finding that. > >>> > >>> I wonder if eastl is actually faster, more portable, etc. I'm sure > it > >>> satisfies their desire for a simpler std::allocator. But, I would > have > >>> > >> liked > >> > >>> to see some performance comparisons in this paper. There's nothing > like > >>> > >> hard > >> > >>> numbers to justify the time they spent rewriting/redesigning the > STL. > >>> > >>> Regards, > >>> > >>> Paul > >>> > >>> > >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> > wrote: > >>> > >>> > >>> > >>> > >>>> I found a good site that details EA's own version of STL and why > game > >>>> > >>> > companies don't use STL. > >>> > > >>> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html > >>> > > >>> > Paul Peloski wrote: > >>> > > -- > >>> > > [ Picked text/plain from multipart/alternative ] > >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I > >>> > >> really > >> > >>> > like > >>> > > the STL (and Boost). Is there some important consideration I > missed > >>> > about > >>> > > their usage with the Source SDK? > >>> > > > >>> > > Regards, > >>> > > > >>> > > Paul > >>> > > > >>> > > >>> > ___ > >>> > To unsubscribe, edit your list preferences, or view the list > >>> > >> archives, > >> > >>> > please visit: > >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >>> > > >>> > > >>> -- > >>> > >>> > >>> > >>>
Re: [hlcoders] CUtlVector<*>... Memory management?
It's not that the OS isn't capable of memory management. It's that the application can do better than the OS in many cases. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, May 31, 2008 17:32 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? There are only a few sections where the gains were at all significant. Rather than a divergent library they probably could've realized a few optimization patches and gotten the same benefit. The thing I don't understand though is why so many software companies to this day still try to do so much low-level memory management themselves, as if the OS was incapable of it. It's not just gaming software either: case in point, Firefox and its insane memory management that bloats to using hundreds of megabytes over time. Paul Peloski wrote: > -- > [ Picked text/plain from multipart/alternative ] > In the algorithms they made some significant gains on Windows and Xbox, but > not so much on Mac and Linux. I guess libstdc++ is faster than Microsoft's > STL implementation. Since a lot of games will target Microsoft platforms I > guess it was a good move to rewrite their STL implementation. > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > equivalent operations using STL. > > Regards, > > Paul > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> wrote: > > >> That is a really interesting article. How did you find it? >> >> Also, they do have some performance benchmarks buried at the bottom: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appen dix_20 >> >> Nate >> >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> >> wrote: >> >>> -- >>> [ Picked text/plain from multipart/alternative ] >>> Interesting, thanks for finding that. >>> >>> I wonder if eastl is actually faster, more portable, etc. I'm sure it >>> satisfies their desire for a simpler std::allocator. But, I would have >>> >> liked >> >>> to see some performance comparisons in this paper. There's nothing like >>> >> hard >> >>> numbers to justify the time they spent rewriting/redesigning the STL. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>>> I found a good site that details EA's own version of STL and why game >>>> >>> > companies don't use STL. >>> > >>> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html >>> > >>> > Paul Peloski wrote: >>> > > -- >>> > > [ Picked text/plain from multipart/alternative ] >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I >>> >> really >> >>> > like >>> > > the STL (and Boost). Is there some important consideration I missed >>> > about >>> > > their usage with the Source SDK? >>> > > >>> > > Regards, >>> > > >>> > > Paul >>> > > >>> > >>> > ___ >>> > To unsubscribe, edit your list preferences, or view the list >>> >> archives, >> >>> > please visit: >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> > >>> > >>> -- >>> >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> >> please visit: >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
True it has. I can't find the site at the moment, but yes, Firefox has been improved vastly. On Sat, May 31, 2008 at 6:47 PM, Jorge Rodriguez <[EMAIL PROTECTED]> wrote: > On Sat, May 31, 2008 at 9:22 PM, Stephen Gigante <[EMAIL PROTECTED]> > wrote: > > > It doesn't. Firefox manages it's memory exactly the way it wants to; by > > caching the back button. > > > > No, no, that's not true. It does consume a huge amount of memory caching > the > user history, but it also has many memory leaks and wastes a whole lot of > duplicated memory. > > But the good news is, a whole lot of that was fixed in FF3, which I believe > has already been released. > > -- > Jorge "Vino" Rodriguez > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- Gear Dev ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
On Sat, May 31, 2008 at 9:22 PM, Stephen Gigante <[EMAIL PROTECTED]> wrote: > It doesn't. Firefox manages it's memory exactly the way it wants to; by > caching the back button. > No, no, that's not true. It does consume a huge amount of memory caching the user history, but it also has many memory leaks and wastes a whole lot of duplicated memory. But the good news is, a whole lot of that was fixed in FF3, which I believe has already been released. -- Jorge "Vino" Rodriguez ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
It doesn't. Firefox manages it's memory exactly the way it wants to; by caching the back button. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Spencer 'voogru' MacDonald Sent: Sunday, 1 June 2008 11:12 AM To: 'Discussion of Half-Life Programming' Subject: Re: [hlcoders] CUtlVector<*>... Memory management? I thought FireFox could do no wrong? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, May 31, 2008 8:32 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? There are only a few sections where the gains were at all significant. Rather than a divergent library they probably could've realized a few optimization patches and gotten the same benefit. The thing I don't understand though is why so many software companies to this day still try to do so much low-level memory management themselves, as if the OS was incapable of it. It's not just gaming software either: case in point, Firefox and its insane memory management that bloats to using hundreds of megabytes over time. Paul Peloski wrote: > -- > [ Picked text/plain from multipart/alternative ] > In the algorithms they made some significant gains on Windows and Xbox, but > not so much on Mac and Linux. I guess libstdc++ is faster than Microsoft's > STL implementation. Since a lot of games will target Microsoft platforms I > guess it was a good move to rewrite their STL implementation. > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > equivalent operations using STL. > > Regards, > > Paul > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> wrote: > > >> That is a really interesting article. How did you find it? >> >> Also, they do have some performance benchmarks buried at the bottom: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_ 20 >> >> Nate >> >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> >> wrote: >> >>> -- >>> [ Picked text/plain from multipart/alternative ] >>> Interesting, thanks for finding that. >>> >>> I wonder if eastl is actually faster, more portable, etc. I'm sure it >>> satisfies their desire for a simpler std::allocator. But, I would have >>> >> liked >> >>> to see some performance comparisons in this paper. There's nothing like >>> >> hard >> >>> numbers to justify the time they spent rewriting/redesigning the STL. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>>> I found a good site that details EA's own version of STL and why game >>>> >>> > companies don't use STL. >>> > >>> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html >>> > >>> > Paul Peloski wrote: >>> > > -- >>> > > [ Picked text/plain from multipart/alternative ] >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I >>> >> really >> >>> > like >>> > > the STL (and Boost). Is there some important consideration I missed >>> > about >>> > > their usage with the Source SDK? >>> > > >>> > > Regards, >>> > > >>> > > Paul >>> > > >>> > >>> > ___ >>> > To unsubscribe, edit your list preferences, or view the list >>> >> archives, >> >>> > please visit: >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> > >>> > >>> -- >>> >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> >> please visit: >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
I thought FireFox could do no wrong? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, May 31, 2008 8:32 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? There are only a few sections where the gains were at all significant. Rather than a divergent library they probably could've realized a few optimization patches and gotten the same benefit. The thing I don't understand though is why so many software companies to this day still try to do so much low-level memory management themselves, as if the OS was incapable of it. It's not just gaming software either: case in point, Firefox and its insane memory management that bloats to using hundreds of megabytes over time. Paul Peloski wrote: > -- > [ Picked text/plain from multipart/alternative ] > In the algorithms they made some significant gains on Windows and Xbox, but > not so much on Mac and Linux. I guess libstdc++ is faster than Microsoft's > STL implementation. Since a lot of games will target Microsoft platforms I > guess it was a good move to rewrite their STL implementation. > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > equivalent operations using STL. > > Regards, > > Paul > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> wrote: > > >> That is a really interesting article. How did you find it? >> >> Also, they do have some performance benchmarks buried at the bottom: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_ 20 >> >> Nate >> >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> >> wrote: >> >>> -- >>> [ Picked text/plain from multipart/alternative ] >>> Interesting, thanks for finding that. >>> >>> I wonder if eastl is actually faster, more portable, etc. I'm sure it >>> satisfies their desire for a simpler std::allocator. But, I would have >>> >> liked >> >>> to see some performance comparisons in this paper. There's nothing like >>> >> hard >> >>> numbers to justify the time they spent rewriting/redesigning the STL. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>>> I found a good site that details EA's own version of STL and why game >>>> >>> > companies don't use STL. >>> > >>> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html >>> > >>> > Paul Peloski wrote: >>> > > -- >>> > > [ Picked text/plain from multipart/alternative ] >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I >>> >> really >> >>> > like >>> > > the STL (and Boost). Is there some important consideration I missed >>> > about >>> > > their usage with the Source SDK? >>> > > >>> > > Regards, >>> > > >>> > > Paul >>> > > >>> > >>> > ___ >>> > To unsubscribe, edit your list preferences, or view the list >>> >> archives, >> >>> > please visit: >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> > >>> > >>> -- >>> >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> >> please visit: >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
There are only a few sections where the gains were at all significant. Rather than a divergent library they probably could've realized a few optimization patches and gotten the same benefit. The thing I don't understand though is why so many software companies to this day still try to do so much low-level memory management themselves, as if the OS was incapable of it. It's not just gaming software either: case in point, Firefox and its insane memory management that bloats to using hundreds of megabytes over time. Paul Peloski wrote: > -- > [ Picked text/plain from multipart/alternative ] > In the algorithms they made some significant gains on Windows and Xbox, but > not so much on Mac and Linux. I guess libstdc++ is faster than Microsoft's > STL implementation. Since a lot of games will target Microsoft platforms I > guess it was a good move to rewrite their STL implementation. > > I wonder if Valve has a similar benchmark comparison for CUtl* and the > equivalent operations using STL. > > Regards, > > Paul > > On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> wrote: > > >> That is a really interesting article. How did you find it? >> >> Also, they do have some performance benchmarks buried at the bottom: >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_20 >> >> Nate >> >> On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> >> wrote: >> >>> -- >>> [ Picked text/plain from multipart/alternative ] >>> Interesting, thanks for finding that. >>> >>> I wonder if eastl is actually faster, more portable, etc. I'm sure it >>> satisfies their desire for a simpler std::allocator. But, I would have >>> >> liked >> >>> to see some performance comparisons in this paper. There's nothing like >>> >> hard >> >>> numbers to justify the time they spent rewriting/redesigning the STL. >>> >>> Regards, >>> >>> Paul >>> >>> >>> On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> I found a good site that details EA's own version of STL and why game >>> > companies don't use STL. >>> > >>> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html >>> > >>> > Paul Peloski wrote: >>> > > -- >>> > > [ Picked text/plain from multipart/alternative ] >>> > > Why doesn't Valve use the STL, anyways? I've always wondered. I >>> >> really >> >>> > like >>> > > the STL (and Boost). Is there some important consideration I missed >>> > about >>> > > their usage with the Source SDK? >>> > > >>> > > Regards, >>> > > >>> > > Paul >>> > > >>> > >>> > ___ >>> > To unsubscribe, edit your list preferences, or view the list >>> >> archives, >> >>> > please visit: >>> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> > >>> > >>> -- >>> >>> >>> >>> ___ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> >> please visit: >> >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >>> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
An EA employee posted it on another forum in reply to a similar question about game companies not using STL. Nate Nichols wrote: That is a really interesting article. How did you find it? Also, they do have some performance benchmarks buried at the bottom: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_20 Nate ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] In the algorithms they made some significant gains on Windows and Xbox, but not so much on Mac and Linux. I guess libstdc++ is faster than Microsoft's STL implementation. Since a lot of games will target Microsoft platforms I guess it was a good move to rewrite their STL implementation. I wonder if Valve has a similar benchmark comparison for CUtl* and the equivalent operations using STL. Regards, Paul On Fri, Feb 15, 2008 at 11:23 AM, Nate Nichols <[EMAIL PROTECTED]> wrote: > That is a really interesting article. How did you find it? > > Also, they do have some performance benchmarks buried at the bottom: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_20 > > Nate > > On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> > wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > Interesting, thanks for finding that. > > > > I wonder if eastl is actually faster, more portable, etc. I'm sure it > > satisfies their desire for a simpler std::allocator. But, I would have > liked > > to see some performance comparisons in this paper. There's nothing like > hard > > numbers to justify the time they spent rewriting/redesigning the STL. > > > > Regards, > > > > Paul > > > > > > On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: > > > > > > > > > I found a good site that details EA's own version of STL and why game > > > companies don't use STL. > > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html > > > > > > Paul Peloski wrote: > > > > -- > > > > [ Picked text/plain from multipart/alternative ] > > > > Why doesn't Valve use the STL, anyways? I've always wondered. I > really > > > like > > > > the STL (and Boost). Is there some important consideration I missed > > > about > > > > their usage with the Source SDK? > > > > > > > > Regards, > > > > > > > > Paul > > > > > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list > archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > -- > > > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
That is a really interesting article. How did you find it? Also, they do have some performance benchmarks buried at the bottom: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_20 Nate On Fri, Feb 15, 2008 at 9:55 AM, Paul Peloski <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Interesting, thanks for finding that. > > I wonder if eastl is actually faster, more portable, etc. I'm sure it > satisfies their desire for a simpler std::allocator. But, I would have liked > to see some performance comparisons in this paper. There's nothing like hard > numbers to justify the time they spent rewriting/redesigning the STL. > > Regards, > > Paul > > > On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: > > > > > I found a good site that details EA's own version of STL and why game > > companies don't use STL. > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html > > > > Paul Peloski wrote: > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Why doesn't Valve use the STL, anyways? I've always wondered. I really > > like > > > the STL (and Boost). Is there some important consideration I missed > > about > > > their usage with the Source SDK? > > > > > > Regards, > > > > > > Paul > > > > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Interesting, thanks for finding that. I wonder if eastl is actually faster, more portable, etc. I'm sure it satisfies their desire for a simpler std::allocator. But, I would have liked to see some performance comparisons in this paper. There's nothing like hard numbers to justify the time they spent rewriting/redesigning the STL. Regards, Paul On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: > I found a good site that details EA's own version of STL and why game > companies don't use STL. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html > > Paul Peloski wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > Why doesn't Valve use the STL, anyways? I've always wondered. I really > like > > the STL (and Boost). Is there some important consideration I missed > about > > their usage with the Source SDK? > > > > Regards, > > > > Paul > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] That's pretty cool, I agree with them on the reasoning and whatnot, but after reading that, I wouldn't touch their implementation, imho it has some sound ideas, and a lot of things that sound good on paper, but would probably explain the instability in a lot of their games - unless this is just an entirely new thing that has only been used in one or two things. -Tony On Fri, Feb 15, 2008 at 4:56 AM, Justin Krenz <[EMAIL PROTECTED]> wrote: > I found a good site that details EA's own version of STL and why game > companies don't use STL. > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
I found a good site that details EA's own version of STL and why game companies don't use STL. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html Paul Peloski wrote: -- [ Picked text/plain from multipart/alternative ] Why doesn't Valve use the STL, anyways? I've always wondered. I really like the STL (and Boost). Is there some important consideration I missed about their usage with the Source SDK? Regards, Paul ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Oh my god. I'm such a fool! How did I not notice that?! I should NOT be a C++ programmer with schoolboy errors like that. Thank you, you have just opened my eyes :D haha. Seriously though, good catch, that really didn't occur to me! On Jan 11, 2008 10:33 PM, Jeremy <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > I could be reading this wrong, but with this > > *The pointers for this constructor are retrieved > from a class called CItemData which loads all items from a data file into > a > CUtlVector before the call to new CInvItem. The CInventory > destructor calls delete on all m_vItems elements, before emptying the > > *are you saying that 2 vectors both share pointers to the same objects? > > J > * > vector. The CItemData destructor does the same for its vector of CItem*.* > > On Jan 11, 2008 1:55 PM, Minh <[EMAIL PROTECTED]> wrote: > > > ooh.. someone just got ownucted. > > > > just kidding :) > > > > - Original Message - > > From: "Yahn Bernier" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, January 11, 2008 1:26 PM > > Subject: RE: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > Well, when talking about a "destructor" the colloquial term is > > > "destructed". > > > > > > YMMV. > > > > > > Yahn > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Jed > > > Sent: Friday, January 11, 2008 1:03 PM > > > To: hlcoders@list.valvesoftware.com > > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > [pendantic englishman] > > > > > > *eye twitch* - its "destroyed" not "destructed". > > > > > > [/pendantic englishman] > > > > > > On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > > >> If the element type is a pointer: > > >> > > >> CUtlVector< CMyClass * > vecStuff; > > >> > > >> Then the underlying object will not be destructed, just the slot > > > holding > > >> the ptr. > > >> > > >> If you do: > > >> > > >> CUtlVector< CMyClass > vecStuff; > > >> > > >> Then the object gets desctructed (but you also have to worry about > > >> implementing a copy constructor or operator =, etc. etc.) > > >> > > >> Safest thing in the CUtlVector< CMyClass * > case is to loop through > > > the > > >> objects and call delete on each entry, and then call Purge/RemoveAll > > > to > > >> free the memory used for the raw pointers. > > >> > > >> ~CUtlVector will automatically clean up the ptrs, but if you don't > > >> delete the objects in the CUtlVector< CMyClass * > case then you'll > > > have > > >> a leak. > > >> > > >> Yahn > > >> > > >> -Original Message- > > >> From: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > > >> Schedel > > >> Sent: Friday, January 11, 2008 11:50 AM > > >> To: hlcoders@list.valvesoftware.com > > >> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > >> > > >> Why you don't look at the code itself? In "Remove" you can see the > > >> element > > >> will be destroyed by the Destruct function. The Destruct function > > > calls > > >> the > > >> Destructor of the element. > > >> > > >> Best regards > > >> > > >> Ronny Schedel > > >> > > >> > > >> > -- > > >> > [ Picked text/plain from multipart/alternative ] > > >> > Am I right in assuming that if you have a vector of pointers, that > > >> point > > >> > to > > >> > things you create with "new", you have to either call delete on > each > > >> > element > > >> > or use PurgeAndDeleteElements()? Because that's what I've been > using > > >> up > > >> > until recently, where it seems that trying to delete elements from > a > > >> > pointer > > >> > vector on destruction of whatever they are members of just cau
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Why doesn't Valve use the STL, anyways? I've always wondered. I really like the STL (and Boost). Is there some important consideration I missed about their usage with the Source SDK? Regards, Paul On Jan 11, 2008 3:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] I could be reading this wrong, but with this *The pointers for this constructor are retrieved from a class called CItemData which loads all items from a data file into a CUtlVector before the call to new CInvItem. The CInventory destructor calls delete on all m_vItems elements, before emptying the *are you saying that 2 vectors both share pointers to the same objects? J * vector. The CItemData destructor does the same for its vector of CItem*.* On Jan 11, 2008 1:55 PM, Minh <[EMAIL PROTECTED]> wrote: > ooh.. someone just got ownucted. > > just kidding :) > > - Original Message - > From: "Yahn Bernier" <[EMAIL PROTECTED]> > To: > Sent: Friday, January 11, 2008 1:26 PM > Subject: RE: [hlcoders] CUtlVector<*>... Memory management? > > > > Well, when talking about a "destructor" the colloquial term is > > "destructed". > > > > YMMV. > > > > Yahn > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Jed > > Sent: Friday, January 11, 2008 1:03 PM > > To: hlcoders@list.valvesoftware.com > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > [pendantic englishman] > > > > *eye twitch* - its "destroyed" not "destructed". > > > > [/pendantic englishman] > > > > On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > >> If the element type is a pointer: > >> > >> CUtlVector< CMyClass * > vecStuff; > >> > >> Then the underlying object will not be destructed, just the slot > > holding > >> the ptr. > >> > >> If you do: > >> > >> CUtlVector< CMyClass > vecStuff; > >> > >> Then the object gets desctructed (but you also have to worry about > >> implementing a copy constructor or operator =, etc. etc.) > >> > >> Safest thing in the CUtlVector< CMyClass * > case is to loop through > > the > >> objects and call delete on each entry, and then call Purge/RemoveAll > > to > >> free the memory used for the raw pointers. > >> > >> ~CUtlVector will automatically clean up the ptrs, but if you don't > >> delete the objects in the CUtlVector< CMyClass * > case then you'll > > have > >> a leak. > >> > >> Yahn > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > >> Schedel > >> Sent: Friday, January 11, 2008 11:50 AM > >> To: hlcoders@list.valvesoftware.com > >> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >> > >> Why you don't look at the code itself? In "Remove" you can see the > >> element > >> will be destroyed by the Destruct function. The Destruct function > > calls > >> the > >> Destructor of the element. > >> > >> Best regards > >> > >> Ronny Schedel > >> > >> > >> > -- > >> > [ Picked text/plain from multipart/alternative ] > >> > Am I right in assuming that if you have a vector of pointers, that > >> point > >> > to > >> > things you create with "new", you have to either call delete on each > >> > element > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > >> up > >> > until recently, where it seems that trying to delete elements from a > >> > pointer > >> > vector on destruction of whatever they are members of just causes > > the > >> game > >> > to crash with a memory error. Removing the calls to delete stop the > >> crash, > >> > but unless CUtlVector automatically cleans up your memory for you, > >> won't > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >> > didn't > >> > magically look after your memory for you... was I wrong? > >> > > >> > J > >> > -- > >> > > >> > ___ > >> > To unsubscribe, edit your list preferences, or view the list > > archives, > >> > please visit: > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > >> > >> > >> ___ > >>
Re: [hlcoders] CUtlVector<*>... Memory management?
Hi, The problem could be, that you are copying the vector directly with the pointers . e.g. *) you are copying the vector -> the pointers will be copied and not the object of your class. *) you are deleting one of the 2 vector instances -> memory will be freed -> everything is fine... atleast for now *) you are deleting the 2nd vector -> the pointers are pointing to an address that is not available anymore -> big MessageBox with errors/CRASH Heimo Jamie Femia schrieb: -- [ Picked text/plain from multipart/alternative ] That's what I thought... in that case I need to figure out why calling delete vector[element] crashes my mod! On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
ooh.. someone just got ownucted. just kidding :) - Original Message - From: "Yahn Bernier" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 1:26 PM Subject: RE: [hlcoders] CUtlVector<*>... Memory management? Well, when talking about a "destructor" the colloquial term is "destructed". YMMV. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Friday, January 11, 2008 1:03 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? [pendantic englishman] *eye twitch* - its "destroyed" not "destructed". [/pendantic englishman] On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] CUtlVector<*>... Memory management?
Well, when talking about a "destructor" the colloquial term is "destructed". YMMV. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Friday, January 11, 2008 1:03 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? [pendantic englishman] *eye twitch* - its "destroyed" not "destructed". [/pendantic englishman] On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] I can't really give a code snippet because for it to be in any kind of context you would need to see quite a bit of it. I will try and simplify it: I have a class, CItem. This class contains char arrays, integers, etc, etc holding data about a specific item.. the contents aren't that important - at no point anywhere in this class do i create any memory with new or malloc. I then have another class, CInvItem, which consists of three CItem pointers (because in this system items are combined with others randomly to generate a large armount of different items). Three CItem pointers are passed on construction, and copied to the member pointer variables. In the destructor I have delete calls for all three pointers. Then I have my CInventory class. Among other things, this contains a CUtlVector m_vItems. In the CInventory constructor I add a specific number of "slots" to the vector using AddToTail( NULL ). Any items added to the inventory by other functions use m_vItems[slot] = new CInvItem( CItem*, CItem*, CItem* ). The pointers for this constructor are retrieved from a class called CItemData which loads all items from a data file into a CUtlVector before the call to new CInvItem. The CInventory destructor calls delete on all m_vItems elements, before emptying the vector. The CItemData destructor does the same for its vector of CItem*. Now this crash only occurs when I have an item in the inventory.. and only when I load a new map using "map mapname". Using engine->ChangeLevel from within the code (related to a logical entity I have created) does not crash the game. I'm quite puzzled as to why it only crashes when I manually change the map in the console, but when I do it gives me the nice memory error popup saying that location "x" could not be "read". On 1/11/08, Ronny Schedel <[EMAIL PROTECTED]> wrote: > > > Give me some code snippet to understand clearly your problem. Don't forget > declarations, etc. Just some short code which will crash (create one > element, add to vector, remove element from vector). > > > > > -- > > [ Picked text/plain from multipart/alternative ] > > That's what I thought... in that case I need to figure out why calling > > delete vector[element] crashes my mod! > > > > On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> > > wrote: > > > >> If the element type is a pointer: > >> > >> CUtlVector< CMyClass * > vecStuff; > >> > >> Then the underlying object will not be destructed, just the slot > holding > >> the ptr. > >> > >> If you do: > >> > >> CUtlVector< CMyClass > vecStuff; > >> > >> Then the object gets desctructed (but you also have to worry about > >> implementing a copy constructor or operator =, etc. etc.) > >> > >> Safest thing in the CUtlVector< CMyClass * > case is to loop through > the > >> objects and call delete on each entry, and then call Purge/RemoveAll to > >> free the memory used for the raw pointers. > >> > >> ~CUtlVector will automatically clean up the ptrs, but if you don't > >> delete the objects in the CUtlVector< CMyClass * > case then you'll > have > >> a leak. > >> > >> Yahn > >> > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > >> Schedel > >> Sent: Friday, January 11, 2008 11:50 AM > >> To: hlcoders@list.valvesoftware.com > >> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >> > >> Why you don't look at the code itself? In "Remove" you can see the > >> element > >> will be destroyed by the Destruct function. The Destruct function calls > >> the > >> Destructor of the element. > >> > >> Best regards > >> > >> Ronny Schedel > >> > >> > >> > -- > >> > [ Picked text/plain from multipart/alternative ] > >> > Am I right in assuming that if you have a vector of pointers, that > >> point > >> > to > >> > things you create with "new", you have to either call delete on each > >> > element > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > >> up > >> > until recently, where it seems that trying to delete elements from a > >> > pointer > >> > vector on destruction of whatever they are members of just causes the > >> game > >> &
Re: [hlcoders] CUtlVector<*>... Memory management?
[pendantic englishman] *eye twitch* - its "destroyed" not "destructed". [/pendantic englishman] On 11/01/2008, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Give me some code snippet to understand clearly your problem. Don't forget declarations, etc. Just some short code which will crash (create one element, add to vector, remove element from vector). -- [ Picked text/plain from multipart/alternative ] That's what I thought... in that case I need to figure out why calling delete vector[element] crashes my mod! On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
The murderous Memory Man is officially called STATUS_NO_MEMORY (cf. ntstatus.h), but other than that, I guess Counter-Strike taught you a lot about the internals of Windows. ;-) When a process is terminated, the Windows kernel, at least since NT 3.51, frees any and all memory belonging to the process. (Unix does that too.) However, this is often too late -- depending on how long the game runs. Suppose I load a map. My ultra-awesome constructor for some sort of in-game class creates a pointer to an overly large class for optimized resource management. During the course of this map, these special resources get loaded by this resource manager, taking up memory. Now, suppose I change maps. My stupid destructor for that in-game class forgets to free the resource manager, which, in turn, doesn't free all the resources (because it was never told to do so). If my special resources are something akin to id's MegaTextures, the application will eventually -- third map the latest -- run out of memory and the Memory Man will ring my doorbell and try to rape me with a crowbar. There is a big philosophical difference between the heap and the stack: when a stack variable goes out of scope, it is destroyed (and the memory it occupied is freed), whilst a heap variable never goes out of scope. This is pretty sweet for global objects, externally serialized objects and the victims of pointer arithmetic fetishists, but it is always considered good practice to, when the item is not needed anymore, bolt the variable -- new'd variables with delete, malloc'd variables with free. If I do this right, I never waste memory. In practice, with all the pointer passing in a game engine, it is much more troublesome, but anytime memory can be freed, it should be freed. ... unless you want the server admins to do what the Memory Man is said to do. That's a group of people aiming for lots of uptime. (D'oh! In the mean time, Jed has given a shorter description of memory handling and Yahn chimed in to inform everybody of the engine's behavior. I guess I'll send this anyway as a dire warning.) ~~ Ondra P.S. In case you're wondering, yes, this post is 99% hyperbole. Oh, there it is again. On 11.01.08 20:08 Uhr, Minh wrote: -- [ Picked text/plain from multipart/alternative ] What happens if you don't properly release the memory? Will the Memory Man come to your house and beat you to death? If the app is running under Windows and windows knows how much memory is being allocated, then couldn't we just rely on windows to take care of the memory deallocation process? Or perhaps, we don't trust Windows - Original Message - From: "Jed" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 10:58 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Well its C++ so I always thought it was a case that you *have* to properly release any memory you allocate. I usually stick a debug header at the top of all my code files so if theres any memory leaks it'll tell me where they are when the program exits. - Jed On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] That's what I'd like to know.. I'm not totally convinced that it's safe to just leave stuff in the memory.. perhaps a member of Valve staff can confirm? On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] hmm.. I've gotten way with just calling RemoveAll() on my CUTLVectors. Then when I add new elements, I believe it just overtakes the existing memory addresses of these previous elements that were in the vector. Mind you, my utlvectors typically never grow to be more than 20 elements. When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? ----- Original Message - From: "Jamie Femia" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 9:55 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? -- [ Picked text/plain from multipart/alternative ] Then why is it that when I try and delete the elements it crashes the game? lol... On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] you have to delete what you add. purging just removes the elements. On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer v
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] That's what I thought... in that case I need to figure out why calling delete vector[element] crashes my mod! On Jan 11, 2008 8:07 PM, Yahn Bernier <[EMAIL PROTECTED]> wrote: > If the element type is a pointer: > > CUtlVector< CMyClass * > vecStuff; > > Then the underlying object will not be destructed, just the slot holding > the ptr. > > If you do: > > CUtlVector< CMyClass > vecStuff; > > Then the object gets desctructed (but you also have to worry about > implementing a copy constructor or operator =, etc. etc.) > > Safest thing in the CUtlVector< CMyClass * > case is to loop through the > objects and call delete on each entry, and then call Purge/RemoveAll to > free the memory used for the raw pointers. > > ~CUtlVector will automatically clean up the ptrs, but if you don't > delete the objects in the CUtlVector< CMyClass * > case then you'll have > a leak. > > Yahn > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ronny > Schedel > Sent: Friday, January 11, 2008 11:50 AM > To: hlcoders@list.valvesoftware.com > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > Why you don't look at the code itself? In "Remove" you can see the > element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that > point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using > up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, > won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] CUtlVector<*>... Memory management?
If the element type is a pointer: CUtlVector< CMyClass * > vecStuff; Then the underlying object will not be destructed, just the slot holding the ptr. If you do: CUtlVector< CMyClass > vecStuff; Then the object gets desctructed (but you also have to worry about implementing a copy constructor or operator =, etc. etc.) Safest thing in the CUtlVector< CMyClass * > case is to loop through the objects and call delete on each entry, and then call Purge/RemoveAll to free the memory used for the raw pointers. ~CUtlVector will automatically clean up the ptrs, but if you don't delete the objects in the CUtlVector< CMyClass * > case then you'll have a leak. Yahn -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronny Schedel Sent: Friday, January 11, 2008 11:50 AM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] CUtlVector<*>... Memory management? Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Thanks for the input everyone, very helpful :) On 1/11/08, Ronny Schedel <[EMAIL PROTECTED]> wrote: > > Why you don't look at the code itself? In "Remove" you can see the element > will be destroyed by the Destruct function. The Destruct function calls > the > Destructor of the element. > > Best regards > > Ronny Schedel > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Which is especially true for the server side of your game/mod. It's likely to be running constantly for days/weeks/months even a year and if you allocate and never release your memory your going to end up slowing and eventually crashing the server. The "let windows deal with it approach" is just plain bad programming practice. - Jed On 11/01/2008, Tom Leighton <[EMAIL PROTECTED]> wrote: > Newer versions of windows do, im sure that Windows 9x had memory issues > where it was ESSENTIAL you free'd memory you allocated. However, now > windows manages each apps memory (Virtual Memory Addressing), and it > will free any memory you allocated but didn't delete. > > The reason you should still use delete is that your program will start > to become slow/sluggish, etc. Performance reasons. > > Jed wrote: > > Well its C++ so I always thought it was a case that you *have* to > > properly release any memory you allocate. I usually stick a debug > > header at the top of all my code files so if theres any memory leaks > > it'll tell me where they are when the program exits. > > > > - Jed > > > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> That's what I'd like to know.. I'm not totally convinced that it's safe to > >> just leave stuff in the memory.. perhaps a member of Valve staff can > >> confirm? > >> > >> On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > >> > >> > >>> -- > >>> [ Picked text/plain from multipart/alternative ] > >>> hmm.. I've gotten way with just calling > >>> RemoveAll() on my CUTLVectors. > >>> Then when I add new elements, I believe it just overtakes the existing > >>> memory addresses of these previous elements that were in the vector. Mind > >>> you, my utlvectors typically never grow to be more than 20 elements. > >>> > >>> When Half-Life2 shuts down, does all of the memory allocations that were > >>> created during the game get deallocated automatically, so other programs > >>> can > >>> use them? > >>> > >>> > >>> - Original Message - > >>> From: "Jamie Femia" <[EMAIL PROTECTED]> > >>> To: > >>> Sent: Friday, January 11, 2008 9:55 AM > >>> Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > >>> > >>> > >>> > >>>> -- > >>>> [ Picked text/plain from multipart/alternative ] > >>>> Then why is it that when I try and delete the elements it crashes the > >>>> game? > >>>> lol... > >>>> > >>>> On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> -- > >>>>> [ Picked text/plain from multipart/alternative ] > >>>>> you have to delete what you add. purging just removes the elements. > >>>>> > >>>>> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > >>>>> > >>>>> > >>>>>> -- > >>>>>> [ Picked text/plain from multipart/alternative ] > >>>>>> Am I right in assuming that if you have a vector of pointers, that > >>>>>> point > >>>>>> to > >>>>>> things you create with "new", you have to either call delete on each > >>>>>> element > >>>>>> or use PurgeAndDeleteElements()? Because that's what I've been using > >>>>>> > >>> up > >>> > >>>>>> until recently, where it seems that trying to delete elements from a > >>>>>> pointer > >>>>>> vector on destruction of whatever they are members of just causes the > >>>>>> > >>>>> game > >>>>> > >>>>>> to crash with a memory error. Removing the calls to delete stop the > >>>>>> > >>>>> crash, > >>>>> > >>>>>> but unless CUtlVector automatically cleans up your memory for you, > >>>>>> won't > >>>>>> this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >>>>>> didn't > >>>
Re: [hlcoders] CUtlVector<*>... Memory management?
Why you don't look at the code itself? In "Remove" you can see the element will be destroyed by the Destruct function. The Destruct function calls the Destructor of the element. Best regards Ronny Schedel -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] woowwah weee-weee. Thanks.. this looks very convenient. - Original Message - From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 11:35 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > Minh wrote: >> -- >> [ Picked text/plain from multipart/alternative ] >> If you want a real quick and dirty method, I usually just open up Task >> Manager and watch the memory usage of the HL2 process.. > > Process Explorer... > > http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx > > ...beats Task Manager by a metric buttload. > > -- > Jeffrey "botman" Broome > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Minh wrote: -- [ Picked text/plain from multipart/alternative ] If you want a real quick and dirty method, I usually just open up Task Manager and watch the memory usage of the HL2 process.. Process Explorer... http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx ...beats Task Manager by a metric buttload. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Newer versions of windows do, im sure that Windows 9x had memory issues where it was ESSENTIAL you free'd memory you allocated. However, now windows manages each apps memory (Virtual Memory Addressing), and it will free any memory you allocated but didn't delete. The reason you should still use delete is that your program will start to become slow/sluggish, etc. Performance reasons. Jed wrote: Well its C++ so I always thought it was a case that you *have* to properly release any memory you allocate. I usually stick a debug header at the top of all my code files so if theres any memory leaks it'll tell me where they are when the program exits. - Jed On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] That's what I'd like to know.. I'm not totally convinced that it's safe to just leave stuff in the memory.. perhaps a member of Valve staff can confirm? On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] hmm.. I've gotten way with just calling RemoveAll() on my CUTLVectors. Then when I add new elements, I believe it just overtakes the existing memory addresses of these previous elements that were in the vector. Mind you, my utlvectors typically never grow to be more than 20 elements. When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? - Original Message - From: "Jamie Femia" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 9:55 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? -- [ Picked text/plain from multipart/alternative ] Then why is it that when I try and delete the elements it crashes the game? lol... On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] you have to delete what you add. purging just removes the elements. On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: -- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- -omega -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] If you want a real quick and dirty method, I usually just open up Task Manager and watch the memory usage of the HL2 process.. You can observe the fluctuations as the game is being run. I was able to track down a memory leak with entities being spawned and not being deallocated properly using this method. - Original Message - From: "Jeremy" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 11:04 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > -- > [ Picked text/plain from multipart/alternative ] > I haven't tried this with HL2, so I don't know how it would play with the > HL2 memory manager, but for memory leak detection, this is the best thing > since sliced bread for C++ > > http://www.codeproject.com/KB/applications/visualleakdetector.aspx > > J > > On Jan 11, 2008 10:58 AM, Jed <[EMAIL PROTECTED]> wrote: > >> Well its C++ so I always thought it was a case that you *have* to >> properly release any memory you allocate. I usually stick a debug >> header at the top of all my code files so if theres any memory leaks >> it'll tell me where they are when the program exits. >> >> - Jed >> >> On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > That's what I'd like to know.. I'm not totally convinced that it's safe >> to >> > just leave stuff in the memory.. perhaps a member of Valve staff can >> > confirm? >> > >> > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: >> > >> > > -- >> > > [ Picked text/plain from multipart/alternative ] >> > > hmm.. I've gotten way with just calling >> > > RemoveAll() on my CUTLVectors. >> > > Then when I add new elements, I believe it just overtakes the >> > > existing >> > > memory addresses of these previous elements that were in the vector. >> Mind >> > > you, my utlvectors typically never grow to be more than 20 elements. >> > > >> > > When Half-Life2 shuts down, does all of the memory allocations that >> were >> > > created during the game get deallocated automatically, so other >> programs >> > > can >> > > use them? >> > > >> > > >> > > - Original Message - >> > > From: "Jamie Femia" <[EMAIL PROTECTED]> >> > > To: >> > > Sent: Friday, January 11, 2008 9:55 AM >> > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? >> > > >> > > >> > > > -- >> > > > [ Picked text/plain from multipart/alternative ] >> > > > Then why is it that when I try and delete the elements it crashes >> the >> > > > game? >> > > > lol... >> > > > >> > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> >> wrote: >> > > > >> > > >> -- >> > > >> [ Picked text/plain from multipart/alternative ] >> > > >> you have to delete what you add. purging just removes the >> > > >> elements. >> > > >> >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > > >> >> > > >> > -- >> > > >> > [ Picked text/plain from multipart/alternative ] >> > > >> > Am I right in assuming that if you have a vector of pointers, >> that >> > > >> > point >> > > >> > to >> > > >> > things you create with "new", you have to either call delete on >> each >> > > >> > element >> > > >> > or use PurgeAndDeleteElements()? Because that's what I've been >> using >> > > up >> > > >> > until recently, where it seems that trying to delete elements >> from a >> > > >> > pointer >> > > >> > vector on destruction of whatever they are members of just >> > > >> > causes >> the >> > > >> game >> > > >> > to crash with a memory error. Removing the calls to delete stop >> the >> > > >> crash, >> > > >> > but unless CUtlVector automatically cleans up your memory for >> you, >> > > >> > won't >> >
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] What happens if you don't properly release the memory? Will the Memory Man come to your house and beat you to death? If the app is running under Windows and windows knows how much memory is being allocated, then couldn't we just rely on windows to take care of the memory deallocation process? Or perhaps, we don't trust Windows - Original Message - From: "Jed" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 10:58 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > Well its C++ so I always thought it was a case that you *have* to > properly release any memory you allocate. I usually stick a debug > header at the top of all my code files so if theres any memory leaks > it'll tell me where they are when the program exits. > > - Jed > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: >> -- >> [ Picked text/plain from multipart/alternative ] >> That's what I'd like to know.. I'm not totally convinced that it's safe >> to >> just leave stuff in the memory.. perhaps a member of Valve staff can >> confirm? >> >> On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: >> >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > hmm.. I've gotten way with just calling >> > RemoveAll() on my CUTLVectors. >> > Then when I add new elements, I believe it just overtakes the existing >> > memory addresses of these previous elements that were in the vector. >> > Mind >> > you, my utlvectors typically never grow to be more than 20 elements. >> > >> > When Half-Life2 shuts down, does all of the memory allocations that >> > were >> > created during the game get deallocated automatically, so other >> > programs >> > can >> > use them? >> > >> > >> > - Original Message - >> > From: "Jamie Femia" <[EMAIL PROTECTED]> >> > To: >> > Sent: Friday, January 11, 2008 9:55 AM >> > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? >> > >> > >> > > -- >> > > [ Picked text/plain from multipart/alternative ] >> > > Then why is it that when I try and delete the elements it crashes the >> > > game? >> > > lol... >> > > >> > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> >> > > wrote: >> > > >> > >> -- >> > >> [ Picked text/plain from multipart/alternative ] >> > >> you have to delete what you add. purging just removes the elements. >> > >> >> > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > >> >> > >> > -- >> > >> > [ Picked text/plain from multipart/alternative ] >> > >> > Am I right in assuming that if you have a vector of pointers, that >> > >> > point >> > >> > to >> > >> > things you create with "new", you have to either call delete on >> > >> > each >> > >> > element >> > >> > or use PurgeAndDeleteElements()? Because that's what I've been >> > >> > using >> > up >> > >> > until recently, where it seems that trying to delete elements from >> > >> > a >> > >> > pointer >> > >> > vector on destruction of whatever they are members of just causes >> > >> > the >> > >> game >> > >> > to crash with a memory error. Removing the calls to delete stop >> > >> > the >> > >> crash, >> > >> > but unless CUtlVector automatically cleans up your memory for you, >> > >> > won't >> > >> > this just create MASSIVE memory leaks? As far as I knew, >> > >> > CUtlVector >> > >> > didn't >> > >> > magically look after your memory for you... was I wrong? >> > >> > >> > >> > J >> > >> > -- >> > >> > >> > >> > ___ >> > >> > To unsubscribe, edit your list preferences, or view the list >> > archives, >> > >> > please visit: >> > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> >
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] I haven't tried this with HL2, so I don't know how it would play with the HL2 memory manager, but for memory leak detection, this is the best thing since sliced bread for C++ http://www.codeproject.com/KB/applications/visualleakdetector.aspx J On Jan 11, 2008 10:58 AM, Jed <[EMAIL PROTECTED]> wrote: > Well its C++ so I always thought it was a case that you *have* to > properly release any memory you allocate. I usually stick a debug > header at the top of all my code files so if theres any memory leaks > it'll tell me where they are when the program exits. > > - Jed > > On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > > -- > > [ Picked text/plain from multipart/alternative ] > > That's what I'd like to know.. I'm not totally convinced that it's safe > to > > just leave stuff in the memory.. perhaps a member of Valve staff can > > confirm? > > > > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > hmm.. I've gotten way with just calling > > > RemoveAll() on my CUTLVectors. > > > Then when I add new elements, I believe it just overtakes the existing > > > memory addresses of these previous elements that were in the vector. > Mind > > > you, my utlvectors typically never grow to be more than 20 elements. > > > > > > When Half-Life2 shuts down, does all of the memory allocations that > were > > > created during the game get deallocated automatically, so other > programs > > > can > > > use them? > > > > > > > > > - Original Message - > > > From: "Jamie Femia" <[EMAIL PROTECTED]> > > > To: > > > Sent: Friday, January 11, 2008 9:55 AM > > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > > > > -- > > > > [ Picked text/plain from multipart/alternative ] > > > > Then why is it that when I try and delete the elements it crashes > the > > > > game? > > > > lol... > > > > > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> > wrote: > > > > > > > >> -- > > > >> [ Picked text/plain from multipart/alternative ] > > > >> you have to delete what you add. purging just removes the elements. > > > >> > > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > >> > > > >> > -- > > > >> > [ Picked text/plain from multipart/alternative ] > > > >> > Am I right in assuming that if you have a vector of pointers, > that > > > >> > point > > > >> > to > > > >> > things you create with "new", you have to either call delete on > each > > > >> > element > > > >> > or use PurgeAndDeleteElements()? Because that's what I've been > using > > > up > > > >> > until recently, where it seems that trying to delete elements > from a > > > >> > pointer > > > >> > vector on destruction of whatever they are members of just causes > the > > > >> game > > > >> > to crash with a memory error. Removing the calls to delete stop > the > > > >> crash, > > > >> > but unless CUtlVector automatically cleans up your memory for > you, > > > >> > won't > > > >> > this just create MASSIVE memory leaks? As far as I knew, > CUtlVector > > > >> > didn't > > > >> > magically look after your memory for you... was I wrong? > > > >> > > > > >> > J > > > >> > -- > > > >> > > > > >> > ___ > > > >> > To unsubscribe, edit your list preferences, or view the list > > > archives, > > > >> > please visit: > > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > >> > > > > >> > > > > >> > > > >> > > > >> -- > > > >> -omega > > > >> -- > > > >> > > > >> ___ > > > >> To unsubscribe, edit your list preferences, or view the list > archives, > > > >> please visit: > > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > >> > > > >> > > > > -- > > > > > > > > ___ > > > > To unsubscribe, edit your list preferences, or view the list > archives, > > > > please visit: > > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > > > -- > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Well its C++ so I always thought it was a case that you *have* to properly release any memory you allocate. I usually stick a debug header at the top of all my code files so if theres any memory leaks it'll tell me where they are when the program exits. - Jed On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > That's what I'd like to know.. I'm not totally convinced that it's safe to > just leave stuff in the memory.. perhaps a member of Valve staff can > confirm? > > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > hmm.. I've gotten way with just calling > > RemoveAll() on my CUTLVectors. > > Then when I add new elements, I believe it just overtakes the existing > > memory addresses of these previous elements that were in the vector. Mind > > you, my utlvectors typically never grow to be more than 20 elements. > > > > When Half-Life2 shuts down, does all of the memory allocations that were > > created during the game get deallocated automatically, so other programs > > can > > use them? > > > > > > - Original Message - > > From: "Jamie Femia" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, January 11, 2008 9:55 AM > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Then why is it that when I try and delete the elements it crashes the > > > game? > > > lol... > > > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > > > >> -- > > >> [ Picked text/plain from multipart/alternative ] > > >> you have to delete what you add. purging just removes the elements. > > >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > >> > > >> > -- > > >> > [ Picked text/plain from multipart/alternative ] > > >> > Am I right in assuming that if you have a vector of pointers, that > > >> > point > > >> > to > > >> > things you create with "new", you have to either call delete on each > > >> > element > > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > > up > > >> > until recently, where it seems that trying to delete elements from a > > >> > pointer > > >> > vector on destruction of whatever they are members of just causes the > > >> game > > >> > to crash with a memory error. Removing the calls to delete stop the > > >> crash, > > >> > but unless CUtlVector automatically cleans up your memory for you, > > >> > won't > > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > >> > didn't > > >> > magically look after your memory for you... was I wrong? > > >> > > > >> > J > > >> > -- > > >> > > > >> > ___ > > >> > To unsubscribe, edit your list preferences, or view the list > > archives, > > >> > please visit: > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > > >> > > > >> > > >> > > >> -- > > >> -omega > > >> -- > > >> > > >> ___ > > >> To unsubscribe, edit your list preferences, or view the list archives, > > >> please visit: > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > > -- > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
Minh wrote: When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? Yes. Anytime a Windoze app shuts down, the OS will reclaim any memory that was allocated and never freed. -- Jeffrey "botman" Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Windows cleans up after an application that leaks memory, but yea you don't want to purposely leave memory leaks. I'd venture a guess that it's not the vector thats causing the crash but something else. Memory corruption, double deletion, etc. If you are deleting and then calling a function where it tries to delete again it will crash, and vice versa. I would treat it like an std::vector, just remove the elements and do the deletions yourself. On Jan 11, 2008 10:42 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > That's what I'd like to know.. I'm not totally convinced that it's safe to > just leave stuff in the memory.. perhaps a member of Valve staff can > confirm? > > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > hmm.. I've gotten way with just calling > > RemoveAll() on my CUTLVectors. > > Then when I add new elements, I believe it just overtakes the existing > > memory addresses of these previous elements that were in the vector. > Mind > > you, my utlvectors typically never grow to be more than 20 elements. > > > > When Half-Life2 shuts down, does all of the memory allocations that were > > created during the game get deallocated automatically, so other programs > > can > > use them? > > > > > > - Original Message - > > From: "Jamie Femia" <[EMAIL PROTECTED]> > > To: > > Sent: Friday, January 11, 2008 9:55 AM > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Then why is it that when I try and delete the elements it crashes the > > > game? > > > lol... > > > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > > > >> -- > > >> [ Picked text/plain from multipart/alternative ] > > >> you have to delete what you add. purging just removes the elements. > > >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > >> > > >> > -- > > >> > [ Picked text/plain from multipart/alternative ] > > >> > Am I right in assuming that if you have a vector of pointers, that > > >> > point > > >> > to > > >> > things you create with "new", you have to either call delete on > each > > >> > element > > >> > or use PurgeAndDeleteElements()? Because that's what I've been > using > > up > > >> > until recently, where it seems that trying to delete elements from > a > > >> > pointer > > >> > vector on destruction of whatever they are members of just causes > the > > >> game > > >> > to crash with a memory error. Removing the calls to delete stop the > > >> crash, > > >> > but unless CUtlVector automatically cleans up your memory for you, > > >> > won't > > >> > this just create MASSIVE memory leaks? As far as I knew, > CUtlVector > > >> > didn't > > >> > magically look after your memory for you... was I wrong? > > >> > > > >> > J > > >> > -- > > >> > > > >> > ___ > > >> > To unsubscribe, edit your list preferences, or view the list > > archives, > > >> > please visit: > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > > >> > > > >> > > >> > > >> -- > > >> -omega > > >> -- > > >> > > >> ___ > > >> To unsubscribe, edit your list preferences, or view the list > archives, > > >> please visit: > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > > >> > > >> > > > -- > > > > > > ___ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] That's what I'd like to know.. I'm not totally convinced that it's safe to just leave stuff in the memory.. perhaps a member of Valve staff can confirm? On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > hmm.. I've gotten way with just calling > RemoveAll() on my CUTLVectors. > Then when I add new elements, I believe it just overtakes the existing > memory addresses of these previous elements that were in the vector. Mind > you, my utlvectors typically never grow to be more than 20 elements. > > When Half-Life2 shuts down, does all of the memory allocations that were > created during the game get deallocated automatically, so other programs > can > use them? > > > - Original Message - > From: "Jamie Femia" <[EMAIL PROTECTED]> > To: > Sent: Friday, January 11, 2008 9:55 AM > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Then why is it that when I try and delete the elements it crashes the > > game? > > lol... > > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > > > >> -- > >> [ Picked text/plain from multipart/alternative ] > >> you have to delete what you add. purging just removes the elements. > >> > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > >> > >> > -- > >> > [ Picked text/plain from multipart/alternative ] > >> > Am I right in assuming that if you have a vector of pointers, that > >> > point > >> > to > >> > things you create with "new", you have to either call delete on each > >> > element > >> > or use PurgeAndDeleteElements()? Because that's what I've been using > up > >> > until recently, where it seems that trying to delete elements from a > >> > pointer > >> > vector on destruction of whatever they are members of just causes the > >> game > >> > to crash with a memory error. Removing the calls to delete stop the > >> crash, > >> > but unless CUtlVector automatically cleans up your memory for you, > >> > won't > >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > >> > didn't > >> > magically look after your memory for you... was I wrong? > >> > > >> > J > >> > -- > >> > > >> > ___ > >> > To unsubscribe, edit your list preferences, or view the list > archives, > >> > please visit: > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > > >> > > >> > >> > >> -- > >> -omega > >> -- > >> > >> ___ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] hmm.. I've gotten way with just calling RemoveAll() on my CUTLVectors. Then when I add new elements, I believe it just overtakes the existing memory addresses of these previous elements that were in the vector. Mind you, my utlvectors typically never grow to be more than 20 elements. When Half-Life2 shuts down, does all of the memory allocations that were created during the game get deallocated automatically, so other programs can use them? - Original Message - From: "Jamie Femia" <[EMAIL PROTECTED]> To: Sent: Friday, January 11, 2008 9:55 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > -- > [ Picked text/plain from multipart/alternative ] > Then why is it that when I try and delete the elements it crashes the > game? > lol... > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > >> -- >> [ Picked text/plain from multipart/alternative ] >> you have to delete what you add. purging just removes the elements. >> >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > Am I right in assuming that if you have a vector of pointers, that >> > point >> > to >> > things you create with "new", you have to either call delete on each >> > element >> > or use PurgeAndDeleteElements()? Because that's what I've been using up >> > until recently, where it seems that trying to delete elements from a >> > pointer >> > vector on destruction of whatever they are members of just causes the >> game >> > to crash with a memory error. Removing the calls to delete stop the >> crash, >> > but unless CUtlVector automatically cleans up your memory for you, >> > won't >> > this just create MASSIVE memory leaks? As far as I knew, CUtlVector >> > didn't >> > magically look after your memory for you... was I wrong? >> > >> > J >> > -- >> > >> > ___ >> > To unsubscribe, edit your list preferences, or view the list archives, >> > please visit: >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> >> >> -- >> -omega >> -- >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Then why is it that when I try and delete the elements it crashes the game? lol... On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > you have to delete what you add. purging just removes the elements. > > On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > > > -- > > [ Picked text/plain from multipart/alternative ] > > Am I right in assuming that if you have a vector of pointers, that point > > to > > things you create with "new", you have to either call delete on each > > element > > or use PurgeAndDeleteElements()? Because that's what I've been using up > > until recently, where it seems that trying to delete elements from a > > pointer > > vector on destruction of whatever they are members of just causes the > game > > to crash with a memory error. Removing the calls to delete stop the > crash, > > but unless CUtlVector automatically cleans up your memory for you, won't > > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > > didn't > > magically look after your memory for you... was I wrong? > > > > J > > -- > > > > ___ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > -omega > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] you have to delete what you add. purging just removes the elements. On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: > -- > [ Picked text/plain from multipart/alternative ] > Am I right in assuming that if you have a vector of pointers, that point > to > things you create with "new", you have to either call delete on each > element > or use PurgeAndDeleteElements()? Because that's what I've been using up > until recently, where it seems that trying to delete elements from a > pointer > vector on destruction of whatever they are members of just causes the game > to crash with a memory error. Removing the calls to delete stop the crash, > but unless CUtlVector automatically cleans up your memory for you, won't > this just create MASSIVE memory leaks? As far as I knew, CUtlVector > didn't > magically look after your memory for you... was I wrong? > > J > -- > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > -- -omega -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] CUtlVector<*>... Memory management?
-- [ Picked text/plain from multipart/alternative ] Am I right in assuming that if you have a vector of pointers, that point to things you create with "new", you have to either call delete on each element or use PurgeAndDeleteElements()? Because that's what I've been using up until recently, where it seems that trying to delete elements from a pointer vector on destruction of whatever they are members of just causes the game to crash with a memory error. Removing the calls to delete stop the crash, but unless CUtlVector automatically cleans up your memory for you, won't this just create MASSIVE memory leaks? As far as I knew, CUtlVector didn't magically look after your memory for you... was I wrong? J -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
