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 

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

void draw_you(t_sdmain *x, int xx, int yy)

if (!init) initlcd(x); // make sure we got the lcd pointer

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

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

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

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

f.e chanfrault | aka | personal computer music

> >>>>>> |sublime music for a desperate people|

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.

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);

    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);

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


pointers-and-ram

It looks like you're not setting the init flag, so you may be calling 

If that function allocates memory then you've got a leak.

> 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];

> 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);

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

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

> SETLONG(templist+1, 0); SETLONG(templist+2, 0);

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

> f.e chanfrault | aka | personal computer music

>> >>>>>> |sublime music for a desperate people|

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.

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

> 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|


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

> It looks like you're not setting the init flag, so you may be calling 

> If that function allocates memory then you've got a leak.

>> 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];

>> 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);

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

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

>> SETLONG(templist+1, 0); SETLONG(templist+2, 0);

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

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|
>
>


> 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

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.

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

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 

If I had more time I could go through the code, but I've got a 

submission deadline staring me in the face.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

> 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

> Why every programmers around me and now you, Peter, warn me not to 

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

t_atom* templist; // Declare vars at the beginning

initlcd(x); // make sure we got the lcd pointer

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 

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. 

That's all for this week. Submission deadline.

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 ?

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.

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
     }

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.

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 

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 

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?

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
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?

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.

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.


> 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

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

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
> 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?

Peter, while I admire the static function variable, I wonder whether 

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 

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

>> Why every programmers around me and now you, Peter, warn me not to 

> 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

> t_atom* templist; // Declare vars at the beginning

> initlcd(x); // make sure we got the lcd pointer

> 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 

> 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.

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

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.

> 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
>
>


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. :)

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

> Peter, while I admire the static function variable, I wonder whether 

> 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 

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

>>> Why every programmers around me and now you, Peter, warn me not to 

>> 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

>> t_atom* templist; // Declare vars at the beginning

>> initlcd(x); // make sure we got the lcd pointer

>> 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 

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. :)

> 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
>>
>>
>


pointers and ram