pointers and ram


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

    • Sep 06 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|
    • Sep 06 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|
      >
      >
    • Sep 06 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
    • Sep 07 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|
    • Sep 07 2006 | 8:05 am
    • Sep 07 2006 | 9:58 am
    • Sep 07 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|
    • Sep 07 2006 | 11:17 am
    • Sep 07 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 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|
    • Sep 07 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.
    • Sep 07 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 > 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
    • Sep 07 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
      >
      >
    • Sep 07 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://
      >> www.castine.de
      >>
      >>
      >
    • Sep 07 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
      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
    • Sep 07 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):
      >
      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.
      -Joshua
    • Sep 08 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.
      >
      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