Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > About regaining the memory associated with a block-specific variableand reusing it further.

Reply
Thread Tools

About regaining the memory associated with a block-specific variableand reusing it further.

 
 
Keith Thompson
Guest
Posts: n/a
 
      02-01-2011
Seebs <(E-Mail Removed)> writes:
> On 2011-02-01, Myth__Buster <(E-Mail Removed)> wrote:
>> However, it would be interesting to know whether are
>> there any restrictions imposed by Standard C(C99) in doing so(reuse)
>> as
>> far as the language "C" is concerned.

>
> None, it's all undefined behavior.


What behavior is undefined?

It's up to the implementation to decide whether to use the same
storage for different objects (but only if doing so doesn't change
the behavior of the program). But I see nothing undefined about
the behavior of the original program. Plenty of unspecified and/or
implementation-defined behavior (such as the output produced by
"%p"), but nothing undefined.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Seebs
Guest
Posts: n/a
 
      02-01-2011
On 2011-02-01, Keith Thompson <(E-Mail Removed)> wrote:
> What behavior is undefined?


> It's up to the implementation to decide whether to use the same
> storage for different objects (but only if doing so doesn't change
> the behavior of the program). But I see nothing undefined about
> the behavior of the original program. Plenty of unspecified and/or
> implementation-defined behavior (such as the output produced by
> "%p"), but nothing undefined.


Right you are. I misinterpreted the OP to be asking about reusing objects
after they'd been deallocated -- say, returning pointers to local variables
and using them after they've gone out of scope.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-02-2011
Keith Thompson <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>> Myth__Buster <(E-Mail Removed)> writes:
>> <snip>
>>> Okay. Actually, my idea was to optimize the stack usage by the local
>>> arrays
>>> of reasonable sizes specific to blocks.

>>
>> In that case, if the arrays are not variably modified, you could put
>> those that can be reused into a union. If they are of the same element
>> type, you could even dispense with the union, but it helps to keep the
>> naming clear.
>>
>> Your example with single ints would then be:
>>
>> int a;
>> /* ... */
>> union { int b, c; } b_or_c;
>> {
>> /* use b_or_c.b here */
>> }
>> /* use b_or_c.c here */
>>
>> If the arrays are variably modified and of different types, then I am
>> not sure what the best strategy might be. I think it would depend on
>> exactly what you are doing.

>
> Hmm. That strikes me as excessive micro-optimization, especially
> since (in this case) all it saves you is the storage for a single
> int.


The OP said it was for arrays. I am not sure if it is worth it even
then, but I didn't want to make up a new example so I just illustrated
the idea with the OP's example which had stand-alone ints.

<snip>
--
Ben.
 
Reply With Quote
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      02-02-2011
On Feb 1, 12:14*pm, Myth__Buster <(E-Mail Removed)> wrote:
> On Feb 1, 8:30*am, Keith Thompson <(E-Mail Removed)> wrote:
>
>
>
>
>
> > Myth__Buster <(E-Mail Removed)> writes:
> > > NOTE : I am using the terms "reuse" or "reusable" with respect to
> > > the object code generated at the compilation time.

>
> > > /*
> > > ** * *Program to analyze whether it is meaningful to reuse the
> > > ** * *stack memory once the respective variable goes out of
> > > ** * *scope.
> > > **/

>
> > > #include<stdio.h>

>
> > > int main()
> > > {
> > > * *int a; */* Let's say this has the address : A. */
> > > * *printf("\n &a = %p ", &a);

>
> > > * *{
> > > * * * * * *int b; /* Let's say this has the address : B. */
> > > * * * * * *printf("\n &b = %p", &b);
> > > * *}

>
> > > * *int c; /* Let's say this has the address : C. */
> > > * *printf("\n &c = %p", &c);

>
> > > * *return 0;
> > > }

>
> > The lifetimes of both a and c cover the entire block that encloses
> > their declarations. *The lifetime of b covers the inner block in
> > which it's declared. *Thus b and c have overlapping lifetimes,
> > and cannot (in the abstract machine) share the same address.

>
> If this turns out to be the case, I could see that some stack space
> being eaten up by the variables yet unused in the outermost block.
> Well, this could be an inefficient object code generation as well
> right? The inefficiency here I am referring is in terms of memory
> space consumption.
>
> Having said that, I could see no other sort of manipulations to avoid
> this compile-time inefficiency in case the control doesn't reach the
> yet
> unused variables as mentioned above. If there are, then I would be
> eager to know them.



Why not enclose the parts that use a and c in their own blocks?
 
Reply With Quote
 
Myth__Buster
Guest
Posts: n/a
 
      02-03-2011
On Feb 2, 1:57*am, "(E-Mail Removed)" <(E-Mail Removed)>
wrote:
> On Feb 1, 12:14*pm, Myth__Buster <(E-Mail Removed)> wrote:
>
>
>
> > On Feb 1, 8:30*am, Keith Thompson <(E-Mail Removed)> wrote:

>
> > > Myth__Buster <(E-Mail Removed)> writes:
> > > > NOTE : I am using the terms "reuse" or "reusable" with respect to
> > > > the object code generated at the compilation time.

>
> > > > /*
> > > > ** * *Program to analyze whether it is meaningful to reuse the
> > > > ** * *stack memory once the respective variable goes out of
> > > > ** * *scope.
> > > > **/

>
> > > > #include<stdio.h>

>
> > > > int main()
> > > > {
> > > > * *int a; */* Let's say this has the address : A. */
> > > > * *printf("\n &a = %p ", &a);

>
> > > > * *{
> > > > * * * * * *int b; /* Let's say this has the address : B.. */
> > > > * * * * * *printf("\n &b = %p", &b);
> > > > * *}

>
> > > > * *int c; /* Let's say this has the address : C. */
> > > > * *printf("\n &c = %p", &c);

>
> > > > * *return 0;
> > > > }

>
> > > The lifetimes of both a and c cover the entire block that encloses
> > > their declarations. *The lifetime of b covers the inner block in
> > > which it's declared. *Thus b and c have overlapping lifetimes,
> > > and cannot (in the abstract machine) share the same address.

>
> > If this turns out to be the case, I could see that some stack space
> > being eaten up by the variables yet unused in the outermost block.
> > Well, this could be an inefficient object code generation as well
> > right? The inefficiency here I am referring is in terms of memory
> > space consumption.

>
> > Having said that, I could see no other sort of manipulations to avoid
> > this compile-time inefficiency in case the control doesn't reach the
> > yet
> > unused variables as mentioned above. If there are, then I would be
> > eager to know them.

>
> Why not enclose the parts that use a and c in their own blocks?


Yes, that sounds good. So, I tried it with the below example on both
win32
and Fedora core Linux platforms with the same gcc and gdb versions
used earlier.

int main()
{
{
int a = 1;
}

{
int b = 1;
}

{
int c = 1;
}

return 0;
}

The addresses seen through GDB was same for all the variables under
both win32
and Linux platforms.

Based on these observations and the inputs from the people here, I am
getting
the feeling that it is really up to the compiler to reuse the memory
specific
to block variables for the subsequent variables. So, this flexibility
doesn't
appear as a portable one.

The only difference though not relevant to the present question was
that when
an attempt was made to print the addresses of all the variables after
putting
the breakpoint at main and running it, under win32 it succeeded in
displaying
the addresses whereas under Linux, it was not the case.

Under Linux, when I tried the same way of debugging, unless the
control reached
the variable's definition, the respective symbol information wasn't
available
and hence was unable to print the variables' addresses in advance at
the very
entry point of main.

I said the above observation is irrelevant here since I think the
above is something
to do with the debugging information populated by the gcc when used
with option 'g'.
Isn't it?





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
regaining partition news.ntlworld.com Computer Support 5 04-02-2008 01:37 AM
Reusing HttpWebRequest.GetRequestStream Dan ASP .Net 4 06-01-2007 07:29 AM
Reusing DataSet/DataTable anon ASP .Net 1 04-01-2004 04:53 PM
Session Variables and reclaiming associated memory. Mario ASP General 1 02-18-2004 01:08 PM
reusing a bit of code? Rob Meade ASP .Net 4 01-30-2004 02:47 PM



Advertisments