Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #2979
| From | Victor Bazarov <v.bazarov@comcast.invalid> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: Compilers way to implement array allocations |
| Date | 2011-04-01 13:52 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <in53d2$cn$1@dont-email.me> (permalink) |
| References | <xhnlp.1597$0j7.632@newsfe20.ams2> <1469bb1d-d82f-49dd-8a3c-f6a762a145c3@y26g2000yqd.googlegroups.com> <i%nlp.2364$cx.1692@newsfe24.ams2> |
On 4/1/2011 1:32 PM, crea wrote:
> "Goran"<goran.pusic@gmail.com> wrote in message
> news:1469bb1d-d82f-49dd-8a3c-f6a762a145c3@y26g2000yqd.googlegroups.com...
> On Apr 1, 6:44 pm, "crea"<n...@invalid.com> wrote:
> "automatic (objects that exist in a scope; you declare them inside a
> code block, {here}; perhaps class members count as automatic, I am not
> sure; their lifetime is in hands of the compiler, too)"
>
> So my question is, that why cant I destroy this automatic object? How/why
> does the compiler prevent that? Is is located at a specific memory part
> where computer does not accept reallocation?
To answer in the order: no reason, go ahead and destroy it. The
compiler does not even try to prevent that. It is usually allocated in
the "data segment", the portion commonly known as "stack".
There is a catch, however. If you do try to delete (or delete[]) a
pointer that you didn't get from 'new' (or 'new []'), the code has
*undefined behaviour*. Anything can happen. There is no telling *what*
will happen. Not to mention that next time you do it, some *other*
thing can happen (no predictability whatsoever). Read up on undefined
behaviour.
> Or in theory I could delete it, but the compiler prevents it because it
> knows its defined as "automatic" when it compiled it? so its amatter of
> definition....
Stop asking and do it already! Chicken? <g>
V
--
I do not respond to top-posted replies, please don't ask
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Compilers way to implement array allocations "crea" <no@invalid.com> - 2011-04-01 17:44 +0100
Re: Compilers way to implement array allocations Goran <goran.pusic@gmail.com> - 2011-04-01 10:19 -0700
Re: Compilers way to implement array allocations Victor Bazarov <v.bazarov@comcast.invalid> - 2011-04-01 13:32 -0400
Re: Compilers way to implement array allocations Goran <goran.pusic@gmail.com> - 2011-04-02 22:24 -0700
Re: Compilers way to implement array allocations Virchanza <virtual@lavabit.com> - 2011-04-03 17:49 -0700
Re: Compilers way to implement array allocations "crea" <no@invalid.com> - 2011-04-01 18:32 +0100
Re: Compilers way to implement array allocations Victor Bazarov <v.bazarov@comcast.invalid> - 2011-04-01 13:52 -0400
Re: Compilers way to implement array allocations Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-01 13:29 -0500
Re: Compilers way to implement array allocations "crea" <no@invalid.com> - 2011-04-01 20:10 +0100
Re: Compilers way to implement array allocations Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-01 14:56 -0500
Re: Compilers way to implement array allocations Goran <goran.pusic@gmail.com> - 2011-04-02 22:35 -0700
Re: Compilers way to implement array allocations "crea" <no@invalid.com> - 2011-04-03 14:55 +0100
Re: Compilers way to implement array allocations James Kanze <james.kanze@gmail.com> - 2011-04-03 10:22 -0700
Re: Compilers way to implement array allocations Pete Becker <pete@versatilecoding.com> - 2011-04-03 20:25 -0400
Re: Compilers way to implement array allocations James Kanze <james.kanze@gmail.com> - 2011-04-03 10:15 -0700
csiph-web