Hi i want to make fltk 2 on snow leopard but i saw :
Compiling clip.cxx... In file included from clip.cxx:27: osx/clip.cxx: In function ‘void fl_restore_clip()’: osx/clip.cxx:73: error: ‘GetWindowPort’ was not declared in this scope osx/clip.cxx:75: error: ‘NewRgn’ was not declared in this scope osx/clip.cxx:77: error: ‘CopyRgn’ was not declared in this scope osx/clip.cxx:79: error: ‘SectRgn’ was not declared in this scope osx/clip.cxx:80: error: ‘GetPortBounds’ was not declared in this scope osx/clip.cxx:82: error: ‘ClipCGContextToRegion’ was not declared in this scope osx/clip.cxx:84: error: ‘DisposeRgn’ was not declared in this scope osx/clip.cxx: In function ‘void fltk::clip_region(OpaqueRgnHandle*)’: osx/clip.cxx:92: error: ‘DisposeRgn’ was not declared in this scope osx/clip.cxx: In function ‘void fltk::push_clip(int, int, int, int)’: osx/clip.cxx:111: error: ‘NewRgn’ was not declared in this scope osx/clip.cxx:113: error: ‘SetEmptyRgn’ was not declared in this scope osx/clip.cxx:117: error: ‘SetRectRgn’ was not declared in this scope osx/clip.cxx:118: error: ‘SectRgn’ was not declared in this scope osx/clip.cxx: In function ‘void fltk::clipout(const fltk::Rectangle&)’: osx/clip.cxx:137: error: ‘NewRgn’ was not declared in this scope osx/clip.cxx:137: error: ‘SetRectRgn’ was not declared in this scope osx/clip.cxx:138: error: ‘NewRgn’ was not declared in this scope osx/clip.cxx:139: error: ‘SetRectRgn’ was not declared in this scope osx/clip.cxx:140: error: ‘DiffRgn’ was not declared in this scope osx/clip.cxx: In function ‘void fltk::pop_clip()’: osx/clip.cxx:166: error: ‘DisposeRgn’ was not declared in this scope osx/clip.cxx: In function ‘bool fltk::not_clipped(const fltk::Rectangle&)’: osx/clip.cxx:188: error: ‘RectInRgn’ was not declared in this scope osx/clip.cxx: In function ‘int fltk::intersect_with_clip(fltk::Rectangle&)’: osx/clip.cxx:217: error: ‘NewRgn’ was not declared in this scope osx/clip.cxx:218: error: ‘SetRectRgn’ was not declared in this scope osx/clip.cxx:219: error: ‘SectRgn’ was not declared in this scope osx/clip.cxx:220: error: ‘GetRegionBounds’ was not declared in this scope osx/clip.cxx:224: error: ‘DisposeRgn’ was not declared in this scope make[1]: *** [clip.o] Error 1 make: *** [all] Error 2 On 8/22/11, [email protected] <[email protected]> wrote: > Send fltk mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.easysw.com/mailman/listinfo/fltk > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of fltk digest..." > > > Today's Topics: > > 1. Re: creating menu items separately ... (asif saeed) > 2. Re: Creating members on stack/heap (Albrecht Schlosser) > 3. Re: Creating members on stack/heap (Ben Stott) > 4. Re: Creating members on stack/heap (asif saeed) > 5. Re: Creating members on stack/heap (Ben Stott) > 6. Re: Creating members on stack/heap > (MacArthur, Ian (SELEX GALILEO, UK)) > 7. Re: Creating members on stack/heap (asif saeed) > 8. Re: Creating members on stack/heap (asif saeed) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 22 Aug 2011 14:37:04 +0500 > From: asif saeed <[email protected]> > Subject: Re: [fltk.general] creating menu items separately ... > To: "Mirror of fltk.general Newsgroup" <[email protected]> > Message-ID: > <CAJuVpq4fOsRHPp1A5BHPPfR6h=zpcT=jab7uj24ag6wx6qc...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Ian, > > On Mon, Aug 22, 2011 at 1:57 PM, MacArthur, Ian (SELEX GALILEO, UK) < > [email protected]> wrote: > >> >> > Is there any way to, for example, first create a few menu >> > items then create >> > a menu and then add each menu item previously created to this >> > menu then >> > create a menu bar and add to it the menu previously created >> > (with all the >> > menu items) - all dynamically on heap - instead of defining >> > arrays. I don't >> > see any functions like Menu::add(MenuItem *mi), >> > MenuBar::add(Menu *m), etc. >> > All functions take pointers to char strings. Any help? >> >> Um, this is C++, so you do know that the Fl_Menu_ widgets all inherit >> the methods of their parents, right? >> >> Anyway, did you look at the examples Greg suggested? Several of those >> demonstrate dynamic menu creation. > > > That's all very well. But I mean menus get created on arrays and they have > to be found using strings. If they got created dynamically on heap using a > linked list structures then any menu/menu item/menu bar could be accessed > directly via object pointers. That's what I meant. But anyway, I think I can > maintain this structure myself. > > Best, Asif > > > ------------------------------ > > Message: 2 > Date: Mon, 22 Aug 2011 02:51:36 -0700 > From: Albrecht Schlosser <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 22.08.2011 11:30, asif saeed wrote: > >> The docs say that the groups automatically add whatever children get >> created >> after them - they automatically issue a begin or something like that - >> apparently each widget adds itself to the group in its constructor. I read >> that while reading about creating members on heap using new(). I also read >> that the groups automatically delete the children. Now if you create >> children on stack then they will first be released via stack pop and then >> the group will delete them - and here the group will delete something that >> will have already been deallocated through stack unwinding. > > The order matters here. Of course you create the group first, and then > you add the children on the stack. This guarantees that the children > will be deleted first, and in FLTK 1.3 and later this will also remove > each child from its group. Eventually, when the group will be deleted, > all children that were created on the stack, have already removed them- > selves from the group. Only children allocated with new will still be > contained in the group and have to be released. > > It is your responsibility not to add other (static) widgets to a group > and let the group delete them on destruction. In this case you must > remove these children from the group before deleting the group. > > In FLTK 1.1 and probably also 2.0 there is a "kludge" that shall assure > that no double deletion takes place, but this has other drawbacks, i.e. > there is a potential to access memory of deleted objects (children). > > Albrecht > > > ------------------------------ > > Message: 3 > Date: Mon, 22 Aug 2011 20:01:56 +1000 > From: Ben Stott <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > Hey Asif, > >> > > On Mon, Aug 22, 2011 at 1:36 PM, asif saeed >> > > > I read the following tutorial yesterday - it creates class >> > > members on stack >> > > > - that is, it does not make them pointers and allocate them >> > > using new(): >> > > > >> > > > http://www.fltk.org/doc-2.0/html/example3.html >> > > > >> > > > I have also gone through examples that create members on >> > > heap - that is, >> > > > the members are pointers - not values/objects. I have read >> > > in docs that >> > > > Fl_Group automatically deletes the children, that you add, >> > > upon exit. What >> > > > is the difference between creating members on stack and on >> > > heap? Don't you >> > > > think creating them on stack will automatically release >> > > them that could >> > > > cause Fl_Group to release non-existing memory? >> > >> > >> > Why do you think that would happen? >> > >> >> The docs say that the groups automatically add whatever children get >> created >> after them - they automatically issue a begin or something like that - >> apparently each widget adds itself to the group in its constructor. I read >> that while reading about creating members on heap using new(). I also read >> that the groups automatically delete the children. Now if you create >> children on stack then they will first be released via stack pop and then >> the group will delete them - and here the group will delete something that >> will have already been deallocated through stack unwinding. >> > > So, two things: > 1) You've posted a link to fltk2.0 documentation -- and judging by some of > your comments in a few threads, seem to be referencing 2.0 classes -- but > are talking about Fl_Group and the 1.3 counterparts. These are not the same, > so please don't confuse yourself here. What 1.3 does and what 2.0 does are > two different things (unfortunately, at least until we all get fltk3 off the > ground). > In any case, their Group's behave similarly, so I'll answer your question > from a common, C++ standpoint. > > A variable that is just "generally" declared (i.e. not declared static / > auto / <insert a few keywords here>) is defined as "automatically" > allocated. A variable that has had operator new used is defined as > "dynamically" allocated. If you need proof that the current system works -- > and will always work -- it follows as such: > The really cool thing about C++ is that you can't call operator delete on > any variable that's not dynamically allocated. In the case of items that you > add as a child of the group that is automatically allocated, you can't > actually delete this object. It just won't work; programs will segfault > wildly and the world will explode. "delete"-ing an object calls the > deallocation function (i.e. the class' operator delete). If this doesn't > exist (which it doesn't, for FLTK classes), it calls the global operator > delete. This global operator _will not_ operate on objects and will *only* > operate on pointers -- any attempt to operate on an object will throw a > compile error. As above, non-dynamically allocated memory will segfault > *every single time* on most OS's. > > You also don't have your deallocation ordering strictly correct. The stack > unwind will always be the last-constructed order - so if you declare a > Fl_Group above a Fl_Widget, the Fl_Widget will be destructed *before* the > Fl_Group. > > Hopefully this answers your question. The group will never delete anything > that has been deallocated via the stack, and vice versa. How this is done is > more up to the implementation, but this double-deletion can't *ever* occur > in a well-formed program! > > Ben > > > ------------------------------ > > Message: 4 > Date: Mon, 22 Aug 2011 15:23:57 +0500 > From: asif saeed <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: "Mirror of fltk.general Newsgroup" <[email protected]> > Message-ID: > <cajuvpq4crgynwvj4pbpxshybx4+lm2p+pzla6t8sejy9qkf...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Ben, > > Please see my responses below: > > On Mon, Aug 22, 2011 at 3:01 PM, Ben Stott <[email protected]> wrote: > >> > > > On Mon, Aug 22, 2011 at 1:36 PM, asif saeed >> > > > > I read the following tutorial yesterday - it creates class >> > > > members on stack >> > > > > - that is, it does not make them pointers and allocate them >> > > > using new(): >> > > > > >> > > > > http://www.fltk.org/doc-2.0/html/example3.html >> > > > > >> > > > > I have also gone through examples that create members on >> > > > heap - that is, >> > > > > the members are pointers - not values/objects. I have read >> > > > in docs that >> > > > > Fl_Group automatically deletes the children, that you add, >> > > > upon exit. What >> > > > > is the difference between creating members on stack and on >> > > > heap? Don't you >> > > > > think creating them on stack will automatically release >> > > > them that could >> > > > > cause Fl_Group to release non-existing memory? >> > > >> > > Why do you think that would happen? >> > >> > The docs say that the groups automatically add whatever children get >> created >> > after them - they automatically issue a begin or something like that - >> > apparently each widget adds itself to the group in its constructor. I >> read >> > that while reading about creating members on heap using new(). I also >> read >> > that the groups automatically delete the children. Now if you create >> > children on stack then they will first be released via stack pop and >> > then >> > the group will delete them - and here the group will delete something >> that >> > will have already been deallocated through stack unwinding. >> > >> >> So, two things: >> 1) You've posted a link to fltk2.0 documentation -- and judging by some of >> your comments in a few threads, seem to be referencing 2.0 classes -- but >> are talking about Fl_Group and the 1.3 counterparts. > > > Yes, you're right. I posted an fltk-2.0 link but the example applies to 1.3 > as well. > > > The really cool thing about C++ is that you can't call operator delete on >> any variable that's not dynamically allocated. > > > { > int i; > delete &i; //this works but blows up big-time, of course. But compiler > doesn't check it at compile time. > } > > >> You also don't have your deallocation ordering strictly correct. The stack >> unwind will always be the last-constructed order - so if you declare a >> Fl_Group above a Fl_Widget, the Fl_Widget will be destructed *before* the >> Fl_Group. >> > > Ya, I know - I call it DMB (DUMB) destruction - (D)erived classes, (M)embers > and (B)ase. I probably mis-typed something in a hurry. > > Hopefully this answers your question. The group will never delete anything >> that has been deallocated via the stack, and vice versa. > > > That's exactly what I wanted to know. But the question remans: when should I > create member widgets as pointers and when should I create them as direct > object members (non pointers, that is)? > > Ben >> > > Best, Asif > > > ------------------------------ > > Message: 5 > Date: Mon, 22 Aug 2011 20:40:53 +1000 > From: Ben Stott <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > >> { >> int i; >> delete &i; //this works but blows up big-time, of course. But >> compiler >> doesn't check it at compile time. >> } >> > > It's not watertight, but my proof-by-example is that I've never seen this > happen with FLTK ;-) > >> > You also don't have your deallocation ordering strictly correct. The >> > stack >> > unwind will always be the last-constructed order - so if you declare a >> > Fl_Group above a Fl_Widget, the Fl_Widget will be destructed *before* >> > the >> > Fl_Group. >> > >> >> Ya, I know - I call it DMB (DUMB) destruction - (D)erived classes, >> (M)embers >> and (B)ase. I probably mis-typed something in a hurry. > > Even still, not quite. Per-object this is right, but all derived classes > aren't destroyed together, and then all members, etc. Though I assume you > know this already. > >> Hopefully this answers your question. The group will never delete anything >> > that has been deallocated via the stack, and vice versa. >> >> >> That's exactly what I wanted to know. But the question remans: when should >> I >> create member widgets as pointers and when should I create them as direct >> object members (non pointers, that is)? > > Well, this is an entirely different question; when to use a pointer vs when > to use an object. This depends on a heap of things; cache locality being one > (if you're not updating objects constantly, you'll get more benefit from the > cpu cache in using objects). Pointers can also use magic to be casted up and > down the derived tree; objects can't. > There are a myriad of reasons to use one over the other; I'm sure others in > this list have much to offer here. > > Ben > > > ------------------------------ > > Message: 6 > Date: Mon, 22 Aug 2011 11:41:55 +0100 > From: "MacArthur, Ian (SELEX GALILEO, UK)" > <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: "Mirror of fltk.general Newsgroup" <[email protected]> > Message-ID: > <7f50a84254e28c4d87123119e97722ab09778...@desmdswms201.des.grplnk.net> > Content-Type: text/plain; charset="us-ascii" > > >> That's exactly what I wanted to know. But the question >> remans: when should I >> create member widgets as pointers and when should I create >> them as direct >> object members (non pointers, that is)? > > I don't think there's a "right" answer to that question - it will depend > on the strucure of your code, and what makes most sense for your model. > > I tend to always create as pointers then "new" the object into > existence, but that's just my coding style; other ways are at least as > valid... > > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex > SS14 3EL > A company registered in England & Wales. Company no. 02426132 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > ------------------------------ > > Message: 7 > Date: Mon, 22 Aug 2011 15:54:39 +0500 > From: asif saeed <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: "Mirror of fltk.general Newsgroup" <[email protected]> > Message-ID: > <cajuvpq6s31ow7hefyzmgn8p5xtt3buivugnnarw_syz7shb...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Ben, > > On Mon, Aug 22, 2011 at 3:40 PM, Ben Stott <[email protected]> wrote: >> >> > > You also don't have your deallocation ordering strictly correct. The >> stack >> > > unwind will always be the last-constructed order - so if you declare a >> > > Fl_Group above a Fl_Widget, the Fl_Widget will be destructed *before* >> the >> > > Fl_Group. >> > >> > Ya, I know - I call it DMB (DUMB) destruction - (D)erived classes, >> (M)embers >> > and (B)ase. I probably mis-typed something in a hurry. >> >> Even still, not quite. Per-object this is right, but all derived classes >> aren't destroyed together, and then all members, etc. Though I assume you >> know this already. >> > > Yes, hierarchy is always maintained - recursively in case of each object. > > >> > That's exactly what I wanted to know. But the question remans: when >> should I >> > create member widgets as pointers and when should I create them as >> > direct >> > object members (non pointers, that is)? >> >> Well, this is an entirely different question; when to use a pointer vs >> when >> to use an object. This depends on a heap of things; cache locality being >> one >> (if you're not updating objects constantly, you'll get more benefit from >> the >> cpu cache in using objects). Pointers can also use magic to be casted up >> and >> down the derived tree; objects can't. >> > > I guess I am safer with pointers. > > >> Ben >> > > Best, Asif > > > ------------------------------ > > Message: 8 > Date: Mon, 22 Aug 2011 15:55:54 +0500 > From: asif saeed <[email protected]> > Subject: Re: [fltk.general] Creating members on stack/heap > To: "Mirror of fltk.general Newsgroup" <[email protected]> > Message-ID: > <CAJuVpq5P89xJG9zahWat9_m36XqW4QnmuO=P1qN6tMB4trtH=q...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Ian, > > Thanks for replying. > > On Mon, Aug 22, 2011 at 3:41 PM, MacArthur, Ian (SELEX GALILEO, UK) < > [email protected]> wrote: > >> >> > That's exactly what I wanted to know. But the question >> > remans: when should I >> > create member widgets as pointers and when should I create >> > them as direct >> > object members (non pointers, that is)? >> > > I tend to always create as pointers then "new" the object into >> existence, but that's just my coding style; other ways are at least as >> valid... >> > > Yes, I guess this is a better approach. > > Best, Asif > > > ------------------------------ > > _______________________________________________ > fltk mailing list > [email protected] > http://lists.easysw.com/mailman/listinfo/fltk > > > End of fltk Digest, Vol 91, Issue 24 > ************************************ > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
