Forums > Dev

pointers and ram


f.e
September 5, 2006 | 10:25 pm

Hello,

sorry to bother again, but i’m stuck since yesterday with a stupid
problem. When using an object which one of the main function is to
handle drawing in an lcd, the percentage of my used RAM grows each time
i do something. I think this could be because i’m creating pointers,
change their contents and length often and never empty it. But i still
don’t figure out how to do this.

nb: l_templist was defined before as t_atom * templist[256];

example function :

void draw_you(t_sdmain *x, int xx, int yy)
{
if (!init) initlcd(x); // make sure we got the lcd pointer

t_atom *templist;
templist = x->l_templist;

typedmess(x->l_lcdobj, ps_recordsprite, 0L, 0);

SETLONG(templist+0, xx-15);
SETLONG(templist+1, yy-15);
SETLONG(templist+2, xx+15);
SETLONG(templist+3, yy+15);
SETLONG(templist+4, 10);

typedmess(x->l_lcdobj, ps_paintoval, 5, templist);

SETSYM(templist+0, ps_you);

typedmess(x->l_lcdobj, ps_closesprite, 1, templist);

SETSYM(templist+0, ps_you);
SETLONG(templist+1, 0);
SETLONG(templist+2, 0);

typedmess(x->l_lcdobj, ps_drawsprite, 3, templist);

}

best regards

f.e


f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|


September 6, 2006 | 6:09 am

It looks like you’re not setting the init flag, so you may be calling
the initlcd function over and over.
If that function allocates memory then you’ve got a leak.

try

/*
* make sure we got the lcd pointer
*/
if(!init) {
initlcd(x);
init = 1;
}

_Mark

On Sep 5, 2006, at 3:25 PM, f.e wrote:

> Hello,
>
> sorry to bother again, but i’m stuck since yesterday with a stupid
> problem. When using an object which one of the main function is to
> handle drawing in an lcd, the percentage of my used RAM grows each
> time i do something. I think this could be because i’m creating
> pointers, change their contents and length often and never empty it.
> But i still don’t figure out how to do this.
>
> nb: l_templist was defined before as t_atom * templist[256];
>
> example function :
>
> void draw_you(t_sdmain *x, int xx, int yy)
> {
> if (!init) initlcd(x); // make sure we got the lcd pointer
> t_atom *templist; templist = x->l_templist;
> typedmess(x->l_lcdobj, ps_recordsprite, 0L, 0);
> SETLONG(templist+0, xx-15);
> SETLONG(templist+1, yy-15);
> SETLONG(templist+2, xx+15);
> SETLONG(templist+3, yy+15);
> SETLONG(templist+4, 10);
> typedmess(x->l_lcdobj, ps_paintoval, 5, templist);
> SETSYM(templist+0, ps_you);
> typedmess(x->l_lcdobj, ps_closesprite, 1, templist);
> SETSYM(templist+0, ps_you);
> SETLONG(templist+1, 0); SETLONG(templist+2, 0);
> typedmess(x->l_lcdobj, ps_drawsprite, 3, templist);
>
> }
>
> best regards
>
> f.e
>
> —
> f.e chanfrault | aka | personal computer music
>> >>>>>> http://www.personal-computer-music.com
>> >>>>>> |sublime music for a desperate people|



f.e
September 6, 2006 | 8:59 am

Hello Mark,

the init flag is set at the end of the initlcd() function…

cheers

f.e

f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|

Mark Pauley wrote:
> It looks like you’re not setting the init flag, so you may be calling
> the initlcd function over and over.
> If that function allocates memory then you’ve got a leak.
>
> try
>
>
> /*
> * make sure we got the lcd pointer
> */
> if(!init) {
> initlcd(x);
> init = 1;
> }
>
>
> _Mark
>
> On Sep 5, 2006, at 3:25 PM, f.e wrote:
>
>> Hello,
>>
>> sorry to bother again, but i’m stuck since yesterday with a stupid
>> problem. When using an object which one of the main function is to
>> handle drawing in an lcd, the percentage of my used RAM grows each
>> time i do something. I think this could be because i’m creating
>> pointers, change their contents and length often and never empty it.
>> But i still don’t figure out how to do this.
>>
>> nb: l_templist was defined before as t_atom * templist[256];
>>
>> example function :
>>
>> void draw_you(t_sdmain *x, int xx, int yy)
>> {
>> if (!init) initlcd(x); // make sure we got the lcd pointer
>> t_atom *templist; templist = x->l_templist;
>> typedmess(x->l_lcdobj, ps_recordsprite, 0L, 0);
>> SETLONG(templist+0, xx-15);
>> SETLONG(templist+1, yy-15);
>> SETLONG(templist+2, xx+15);
>> SETLONG(templist+3, yy+15);
>> SETLONG(templist+4, 10);
>> typedmess(x->l_lcdobj, ps_paintoval, 5, templist);
>> SETSYM(templist+0, ps_you);
>> typedmess(x->l_lcdobj, ps_closesprite, 1, templist);
>> SETSYM(templist+0, ps_you);
>> SETLONG(templist+1, 0); SETLONG(templist+2, 0);
>> typedmess(x->l_lcdobj, ps_drawsprite, 3, templist);
>>
>> }
>>
>> best regards
>>
>> f.e
>>
>> –f.e chanfrault | aka | personal computer music
>>> >>>>>> http://www.personal-computer-music.com
>>> >>>>>> |sublime music for a desperate people|
>
>


September 6, 2006 | 5:34 pm

void draw_you(t_sdmain *x, int xx, int yy)
{
if (!init) initlcd(x); // make sure we got the lcd pointer

t_atom *templist;
templist = x->l_templist;

On 9/6/06, f.e

wrote:
> Hello Mark,
>
> the init flag is set at the end of the initlcd() function…

How? I don’t even see a variable named init that gets set or passed
in anywhere.

wes


September 7, 2006 | 7:53 am

On 6-Sep-2006, at 19:34, Wesley Smith wrote:

> How? I don’t even see a variable named init that gets set or passed
> in anywhere.

It’s presumably a global var. Which is not good programming practice
(relying on a side-effect to a global), but there are other problems
in the code.

If I had more time I could go through the code, but I’ve got a
submission deadline staring me in the face.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de



f.e
September 7, 2006 | 8:05 am


September 7, 2006 | 9:36 am



f.e
September 7, 2006 | 9:58 am


September 7, 2006 | 10:30 am

On 7-Sep-2006, at 10:05, f.e wrote
> Why every programmers around me and now you, Peter, warn me not to
> use globals ?

Globals have their place, but not everything needs to be global.

The problem with globals is, first of all, one of code correctness
and maintenance. The more places you can access a variable, the
higher the likelihood of shooting yourself in the foot. Maybe you
don’t shoot yourself in the foot with your init variable today, but
tomorrow or next month or next year or when someone else ports your
code. Because with a global variable you _always_ have to think about
what it means and how it’s used throughout the entire project.

In your case I would suggest something like

void
draw_you(t_sdmain *x, int xx, int yy)
{
static Boolean sInit = false;

t_atom* templist; // Declare vars at the beginning
// of the block. This is C.

if (!sInit) {
initlcd(x); // make sure we got the lcd pointer
sInit = true; // don’t do this again
}

// … and so on
}

The sInit variable is now only accessible in one place, you’re not
relying on side-effects, everyone reading the code understands what’s
going on, and nobody can come along and change the value of sInit in
another function.

However, Jeremy’s point is still valid: does sInit really apply if
you only call initlcd() for one particular instance of your object?
Should it not be an instance member? Sais pas. Jeremy n’en sait pas.
C’est seulement toi, qui en peut savoir.

That’s all for this week. Submission deadline.

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


September 7, 2006 | 10:36 am


September 7, 2006 | 11:17 am


September 7, 2006 | 11:44 am


September 7, 2006 | 12:35 pm

On 7-Sep-2006, at 12:43, Mathieu Orjebin wrote:
> Is there any possibility to create externals in a C++ way? I mean,
> you talk about objects, classes and instance… but using these
> concepts along with an iterative language like C seems so weird to me.

There is nothing wierd about this at all. Many notable authorities on
Object-Oriented modeling and design point out that you can implement
an OO-design with *any* programming language. Read some Rumbaugh or
Booch or Yourdon or Blaha. Or < http://www.accu.org/acornsig/public/
articles/oop_c.html>.

Also, consider that Max/MSP was originally developed between 1986 and
1990. How many commercial C++ compilers were available at that time?
For Mac OS? Somewhere I have an old MacTech article with a survey of
available OOPLs in the late 80s. There was Object Pascal, Objective
C, Smalltalk, THINK’s curious C+, even an OO Assembler, but not an
awful lot of choice on the C++ front.

Finally, someone ought to state publically that C++ is not a model
example of a good OOPL. How do you say "morceau de merde" in French?

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de


September 7, 2006 | 1:32 pm

Peter and Jeremy have given good responses. If you haven’t haven’t been scared off of the over-use of globals yet, check this one out: All new (and many existing) Macs have multiple processors (cores), and Max is a multi-threaded app.

This means that you may have multiple functions running *simultaneously* and if they are both accessing/modifying your global at the same time then you are one hosed duck.


September 7, 2006 | 1:43 pm

On 9/7/06, Peter Castine

wrote:
>
>
> There is nothing wierd about this at all. Many notable authorities on
> Object-Oriented modeling and design point out that you can implement
> an OO-design with *any* programming language. Read some Rumbaugh or
> Booch or Yourdon or Blaha. Or < http://www.accu.org/acornsig/public/
> articles/oop_c.html>.

Any advise for books on this subject? My K&R reference is arriving soon, but
I have a feeling it doesn’t cover OOP design. Are there books that are
particularly about OO designs in C?

cheers -thijs


September 7, 2006 | 5:11 pm

Peter, while I admire the static function variable, I wonder whether
this is really what f.e. wants.
The static variable is essentially a global that only has scope during
the function call… Yet it would seem to me that the initlcd
function is operating on an instance of the t_sdmain struct.

What I would recommend is that the t_sdmain struct contain an
lcdInitialized flag and then the initlcd function had a bail-out check
for that flag.

_Mark

On Sep 7, 2006, at 3:30 AM, Peter Castine wrote:

> On 7-Sep-2006, at 10:05, f.e wrote
>> Why every programmers around me and now you, Peter, warn me not to
>> use globals ?
>
> Globals have their place, but not everything needs to be global.
>
> The problem with globals is, first of all, one of code correctness
> and maintenance. The more places you can access a variable, the
> higher the likelihood of shooting yourself in the foot. Maybe you
> don’t shoot yourself in the foot with your init variable today, but
> tomorrow or next month or next year or when someone else ports your
> code. Because with a global variable you _always_ have to think
> about what it means and how it’s used throughout the entire project.
>
> In your case I would suggest something like
>
> void
> draw_you(t_sdmain *x, int xx, int yy)
> {
> static Boolean sInit = false;
>
> t_atom* templist; // Declare vars at the beginning
> // of the block. This is C.
>
> if (!sInit) {
> initlcd(x); // make sure we got the lcd pointer
> sInit = true; // don’t do this again
> }
>
> // … and so on
> }
>
> The sInit variable is now only accessible in one place, you’re not
> relying on side-effects, everyone reading the code understands
> what’s going on, and nobody can come along and change the value of
> sInit in another function.
>
> However, Jeremy’s point is still valid: does sInit really apply if
> you only call initlcd() for one particular instance of your object?
> Should it not be an instance member? Sais pas. Jeremy n’en sait pas.
> C’est seulement toi, qui en peut savoir.
>
> That’s all for this week. Submission deadline.
>
> ————– http://www.bek.no/~pcastine/Litter/ ————-
> Peter Castine +–> Litter Power & Litter Bundle for Jitter
> Universal Binaries on the way
> iCE: Sequencing, Recording &
> Interface Building for |home | chez nous|
> Max/MSP Extremely cool |bei uns | i nostri|
> http://www.dspaudio.com/ http://www.castine.de
>
>


September 7, 2006 | 5:20 pm

Whoops, sorry. I meant to say more clearly that I essentially agree
with the last part of your reply Peter. I was trying to cite the fact
that the function operates on an instance as further proof. :)

cheers and good luck with the deadline.

_Mark

On Sep 7, 2006, at 10:11 AM, Mark Pauley wrote:

> Peter, while I admire the static function variable, I wonder whether
> this is really what f.e. wants.
> The static variable is essentially a global that only has scope
> during the function call… Yet it would seem to me that the
> initlcd function is operating on an instance of the t_sdmain struct.
>
> What I would recommend is that the t_sdmain struct contain an
> lcdInitialized flag and then the initlcd function had a bail-out
> check for that flag.
>
> _Mark
>
> On Sep 7, 2006, at 3:30 AM, Peter Castine wrote:
>
>> On 7-Sep-2006, at 10:05, f.e wrote
>>> Why every programmers around me and now you, Peter, warn me not to
>>> use globals ?
>>
>> Globals have their place, but not everything needs to be global.
>>
>> The problem with globals is, first of all, one of code correctness
>> and maintenance. The more places you can access a variable, the
>> higher the likelihood of shooting yourself in the foot. Maybe you
>> don’t shoot yourself in the foot with your init variable today, but
>> tomorrow or next month or next year or when someone else ports your
>> code. Because with a global variable you _always_ have to think
>> about what it means and how it’s used throughout the entire project.
>>
>> In your case I would suggest something like
>>
>> void
>> draw_you(t_sdmain *x, int xx, int yy)
>> {
>> static Boolean sInit = false;
>>
>> t_atom* templist; // Declare vars at the beginning
>> // of the block. This is C.
>>
>> if (!sInit) {
>> initlcd(x); // make sure we got the lcd pointer
>> sInit = true; // don’t do this again
>> }
>>
>> // … and so on
>> }
>>
>> The sInit variable is now only accessible in one place, you’re not
>> relying on side-effects, everyone reading the code understands
>> what’s going on, and nobody can come along and change the value of
>> sInit in another function.
>>
>> However, Jeremy’s point is still valid: does sInit really apply if
>> you only call initlcd() for one particular instance of your object?
>> Should it not be an instance member? Sais pas. Jeremy n’en sait
>> pas. C’est seulement toi, qui en peut savoir.
>>
>> That’s all for this week. Submission deadline.
>>
>> ————– http://www.bek.no/~pcastine/Litter/
>> ————-
>> Peter Castine +–> Litter Power & Litter Bundle for
>> Jitter
>> Universal Binaries on the way
>> iCE: Sequencing, Recording &
>> Interface Building for |home | chez
>> nous|
>> Max/MSP Extremely cool |bei uns | i
>> nostri|
>> http://www.dspaudio.com/ http://
>> http://www.castine.de
>>
>>
>


September 7, 2006 | 8:26 pm

On Sep 7, 2006, at 6:43 AM, Thijs Koerselman wrote:

>
> Any advise for books on this subject? My K&R reference is arriving
> soon, but I have a feeling it doesn’t cover OOP design. Are there
> books that are particularly about OO designs in C?

Not books, but you might check out the following links we list in the
Jitter SDK (more good info found by googling):

http://www.accu.org/acornsig/public/articles/oop_c.html

http://en.wikipedia.org/wiki/Object-oriented_programming

Max’s OO design specifically uses dynamic binding, which is more like
SmallTalk/ObjC than C++ or Java. So you might want to google that one
too…

-Joshua


September 7, 2006 | 8:39 pm

On Sep 7, 2006, at 1:26 PM, Joshua Kit Clayton wrote:

> Not books, but you might check out the following links we list in
> the Jitter SDK (more good info found by googling):
>
> http://www.accu.org/acornsig/public/articles/oop_c.html

Sorry for being redundant here…didn’t pay close attention to
Peter’s post.

As for books…I do have the following book which illustrate this
stuff more thoroughly, building everything you get from C++ in C, and
then shows why C++ makes people’s lives easier when approaching OO
programming. The thing is that C++ doesn’t give us much advantage
over C for a dynamic, message based architecture as we have in Max,
since no C++ language OO constructs can be applied to this end.

Here’s the book, "C+ C++: Programming With Objects in C and C++" by
Allen Holub (which is out of print but available used). I can’t say
that it’s the best book on the subject, but it covers this topic in
detail.

http://www.amazon.com/C+-C++-Programming-Objects/dp/0070296626

-Joshua


September 8, 2006 | 9:55 am

On 9/7/06, Joshua Kit Clayton wrote:
>
>
>
> Here’s the book, "C+ C++: Programming With Objects in C and C++" by
> Allen Holub (which is out of print but available used). I can’t say
> that it’s the best book on the subject, but it covers this topic in
> detail.
>
> http://www.amazon.com/C+-C++-Programming-Objects/dp/0070296626

Hi Joshua,
Thanks for the tips. I already read the articles from the sdk links, but
that book looks useful. Amazon doesn’t allow these used books to ship to my
country so I have to find it somewhere else. I’ll check it out.

-thijs


Viewing 20 posts - 1 through 20 (of 20 total)