Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #56922 > unrolled thread
| Started by | jeffkrob16@gmail.com |
|---|---|
| First post | 2015-02-03 09:33 -0800 |
| Last post | 2015-02-05 15:12 -0800 |
| Articles | 20 on this page of 144 — 26 participants |
Back to article view | Back to comp.lang.c
Fortran Guy Learning C - Structures... jeffkrob16@gmail.com - 2015-02-03 09:33 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-03 17:59 +0000
Re: Fortran Guy Learning C - Structures... James Kuyper <jameskuyper@verizon.net> - 2015-02-03 13:01 -0500
Re: Fortran Guy Learning C - Structures... Barry Schwarz <schwarzb@dqel.com> - 2015-02-03 10:49 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <invalid@see.sig.invalid> - 2015-02-03 18:54 +0000
Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 11:50 -0800
Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 12:07 -0800
Re: Fortran Guy Learning C - Structures... Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-03 15:14 -0500
Re: Fortran Guy Learning C - Structures... Barry Schwarz <schwarzb@dqel.com> - 2015-02-03 15:06 -0800
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 22:19 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-03 21:40 +0000
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 22:56 -0800
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 23:02 -0800
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-04 00:01 -0800
Re: Fortran Guy Learning C - Structures... jeffkrob16@gmail.com - 2015-02-04 10:53 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-04 11:21 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-04 19:32 +0000
Re: Fortran Guy Learning C - Structures... Barry Schwarz <schwarzb@dqel.com> - 2015-02-04 11:59 -0800
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-04 15:30 -0800
Re: Fortran Guy Learning C - Structures... jeffkrob16@gmail.com - 2015-02-04 19:41 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 04:06 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-05 10:36 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 10:59 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-05 11:03 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-05 12:30 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 12:46 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 12:49 +0000
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-05 15:08 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-05 08:48 -0800
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-05 15:16 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 23:35 +0000
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-07 12:11 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-07 12:22 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-07 22:03 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-07 14:47 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-07 17:15 -0800
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-08 17:22 +1300
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-08 02:47 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 11:20 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-08 14:36 -0800
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-09 11:51 +1300
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 15:02 -0800
Re: Fortran Guy Learning C - Structures... Geoff <geoff@invalid.invalid> - 2015-02-08 16:55 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-09 03:24 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 11:56 +0000
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-09 14:25 +0100
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 14:00 +0000
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-09 15:26 +0100
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 14:39 +0000
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-09 16:59 +0100
Re: Fortran Guy Learning C - Structures... raltbos@xs4all.nl (Richard Bos) - 2015-02-09 16:01 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 13:39 +0000
Re: Fortran Guy Learning C - Structures... James Kuyper <jameskuyper@verizon.net> - 2015-02-09 09:46 -0500
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 14:50 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 08:22 -0800
Re: Fortran Guy Learning C - Structures... gazelle@shell.xmission.com (Kenny McCormack) - 2015-02-09 13:24 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 16:03 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-09 11:01 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 21:54 +0000
Re: Fortran Guy Learning C - Structures... Öö Tiib <ootiib@hot.ee> - 2015-02-09 19:22 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-10 11:34 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-10 14:15 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 00:38 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-10 09:21 +0000
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-10 22:24 +1300
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 09:25 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 09:03 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 17:12 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 09:56 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 18:12 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-10 11:24 -0800
Re: Fortran Guy Learning C - Structures... gazelle@shell.xmission.com (Kenny McCormack) - 2015-02-10 20:18 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-10 09:16 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-10 22:12 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-11 02:58 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 19:00 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-11 07:56 +0000
Re: Fortran Guy Learning C - Structures... David Thompson <dave.thompson2@verizon.net> - 2015-02-22 18:08 -0500
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-10 16:01 -0800
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-10 11:26 +1300
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-10 10:29 +0100
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 08:32 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-09 11:09 -0800
Re: Fortran Guy Learning C - Structures... gazelle@shell.xmission.com (Kenny McCormack) - 2015-02-09 19:39 +0000
Re: Fortran Guy Learning C - Structures... Martin Shobe <martin.shobe@yahoo.com> - 2015-02-09 14:04 -0600
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 12:24 -0800
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-10 10:34 +0100
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 11:42 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-07 22:50 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-07 17:07 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 11:29 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-08 12:14 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 13:44 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-08 22:39 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 11:12 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 20:01 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 20:06 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 21:04 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 21:11 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 23:48 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 13:30 -0800
Re: Fortran Guy Learning C - Structures... Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-08 16:47 -0500
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 14:53 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 02:31 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 10:35 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 13:57 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 07:59 -0800
Re: Fortran Guy Learning C - Structures... Öö Tiib <ootiib@hot.ee> - 2015-02-09 18:15 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-10 05:54 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 16:17 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 22:04 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 14:57 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 23:45 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 02:53 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 09:29 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 10:10 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 11:24 +0000
Re: Fortran Guy Learning C - Structures... Ike Naar <ike@iceland.freeshell.org> - 2015-02-09 17:36 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 17:56 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 10:51 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 11:10 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 11:25 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 11:43 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-10 02:13 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 03:26 +0000
Re: Fortran Guy Learning C - Structures... raltbos@xs4all.nl (Richard Bos) - 2015-02-09 21:18 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 23:11 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 12:10 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 11:18 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 19:27 +0000
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-09 15:00 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 16:00 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-05 02:49 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-05 11:16 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-05 09:00 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-06 00:29 +0000
Re: Fortran Guy Learning C - Structures... Robert Wessel <robertwessel2@yahoo.com> - 2015-02-05 19:20 -0600
Re: Fortran Guy Learning C - Structures... "Charles Richmond" <numerist@aquaporin4.com> - 2015-02-06 16:15 -0600
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-07 00:57 +0000
Re: Fortran Guy Learning C - Structures... Kaz Kylheku <kaz@kylheku.com> - 2015-02-07 01:40 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-07 08:22 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-07 12:06 +0000
Re: Fortran Guy Learning C - Structures... John Bode <jfbode1029@gmail.com> - 2015-02-06 15:03 -0800
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-05 15:12 -0800
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | jeffkrob16@gmail.com |
|---|---|
| Date | 2015-02-03 09:33 -0800 |
| Subject | Fortran Guy Learning C - Structures... |
| Message-ID | <32aade7c-a60c-4d76-9b25-ddb285438ce2@googlegroups.com> |
All,
I'm working with the code from the "General Polygon Clipper" Project. I've come across a recursive subroutine "add_to_sbtree" & included is the associated typedef struct.
****************************************************************************
typedef struct sbt_t_shape /* Scanbeam tree */
{
double y; /* Scanbeam node y value */
struct sbt_t_shape *less; /* Pointer to nodes with lower y */
struct sbt_t_shape *more; /* Pointer to nodes with higher y */
} sb_tree;
static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
{
if (!*sbtree)
{
/* Add a new tree node here */
MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
(*sbtree)->y= y;
(*sbtree)->less= NULL;
(*sbtree)->more= NULL;
(*entries)++;
}
else
{
if ((*sbtree)->y > y)
{
/* Head into the 'less' sub-tree */
add_to_sbtree(entries, &((*sbtree)->less), y);
}
else
{
if ((*sbtree)->y < y)
{
/* Head into the 'more' sub-tree */
add_to_sbtree(entries, &((*sbtree)->more), y);
}
}
}
}
*************************************************************
I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
if (!*sbtree)
What specifically is it asking for about the sbtree struct?
Also, I presume the *less & *more are pointers to it's own struct...why??
Thanks in advance,
Jeff
[toc] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-02-03 17:59 +0000 |
| Message-ID | <mar29c$nd7$1@dont-email.me> |
| In reply to | #56922 |
On 03/02/2015 17:33, jeffkrob16@gmail.com wrote:
> All,
>
> I'm working with the code from the "General Polygon Clipper" Project. I've come across a recursive subroutine "add_to_sbtree" & included is the associated typedef struct.
>
> ****************************************************************************
>
> typedef struct sbt_t_shape /* Scanbeam tree */
> {
> double y; /* Scanbeam node y value */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
> } sb_tree;
>
> static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
> {
> if (!*sbtree)
> if (!*sbtree)
>
> What specifically is it asking for about the sbtree struct?
> Also, I presume the *less & *more are pointers to it's own struct...why??
sbtree is defined as a pointer to pointer to an instance of an sb_tree
struct.
*sbtree dereferences that once to get a pointer to the struct.
if (!*sbstree) is testing whether that pointer is NULL (and goes on to
initialise if it is, presumably by allocating a new sb_tree struct).
** or pointer-to-pointer is used to allow the pointer value in the
caller to be modified (as well as what it points to; ie. the struct
/and/ the pointer to it in the caller). If only sb_tree* sbtree was
used, the function would need another way of passing that new pointer
back to the caller.
Sorry, pointers rapidly get confusing in C, especially the more you try
to explain!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-02-03 13:01 -0500 |
| Message-ID | <54D10CEB.1020107@verizon.net> |
| In reply to | #56922 |
On 02/03/2015 12:33 PM, jeffkrob16@gmail.com wrote:
> All,
>
> I'm working with the code from the "General Polygon Clipper" Project. I've come across a recursive subroutine "add_to_sbtree" & included is the associated typedef struct.
>
> ****************************************************************************
>
> typedef struct sbt_t_shape /* Scanbeam tree */
> {
> double y; /* Scanbeam node y value */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
> } sb_tree;
>
> static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
> {
> if (!*sbtree)
> {
> /* Add a new tree node here */
> MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
> (*sbtree)->y= y;
> (*sbtree)->less= NULL;
> (*sbtree)->more= NULL;
> (*entries)++;
> }
> else
> {
> if ((*sbtree)->y > y)
> {
> /* Head into the 'less' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->less), y);
> }
> else
> {
> if ((*sbtree)->y < y)
> {
> /* Head into the 'more' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->more), y);
> }
> }
> }
> }
>
> *************************************************************
> I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
>
> if (!*sbtree)
>
> What specifically is it asking for about the sbtree struct?
sbtree is not a struct. It's a pointer to a pointer to a struct. *sbtree
retrieves the value of the thing that sbtree points at, which in this
case is itself a pointer to a struct.
"The result of the logical negation operator ! is 0 if the value of its
operand compares unequal to 0, 1 if the value of its operand compares
equal to 0. ... The expression !E is equivalent to (0==E)." (6.5.3.3p5)
0 qualifies as a null pointer constant (6.3.2.3p3). When a pointer is
compared for equality with a null pointer constant, the null pointer
constant is converted to the type of the pointer (6.5.9p5). The result
of such a conversion is a null pointer of that type (6.3.2.3p4). Null
pointers compare equal only to other null pointers - they never compare
equal to pointers to actual objects or functions (6.5.9p6). Therefore,
*sbtree compares equal to 0 only if *sbtree is a null pointer.
Therefore, if(!*sbtree) is asking whether *sbtree is a null pointer.
> Also, I presume the *less & *more are pointers to it's own struct...why??
No: read the comments on the lines where they are declared: less is a
"Pointer to nodes with lower y", and more is "Pointer to nodes with
higher y". I'd say "a node" rather than "nodes" - possibly the author is
not a native speaker of English. I'd normally name such pointers as prev
(for "previous") and next, which I consider to be more obvious.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-02-03 10:49 -0800 |
| Message-ID | <vf32da558ovi3u207350u05drs0fdjd6do@4ax.com> |
| In reply to | #56922 |
On Tue, 3 Feb 2015 09:33:25 -0800 (PST), jeffkrob16@gmail.com wrote:
>All,
>
>I'm working with the code from the "General Polygon Clipper" Project. I've come across a recursive subroutine "add_to_sbtree" & included is the associated typedef struct.
>
>****************************************************************************
>
>typedef struct sbt_t_shape /* Scanbeam tree */
>{
> double y; /* Scanbeam node y value */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
>} sb_tree;
>
>static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
>{
> if (!*sbtree)
> {
> /* Add a new tree node here */
> MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
> (*sbtree)->y= y;
> (*sbtree)->less= NULL;
> (*sbtree)->more= NULL;
> (*entries)++;
> }
> else
> {
> if ((*sbtree)->y > y)
> {
> /* Head into the 'less' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->less), y);
> }
> else
> {
> if ((*sbtree)->y < y)
> {
> /* Head into the 'more' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->more), y);
> }
> }
> }
>}
>
>*************************************************************
>I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
>
>if (!*sbtree)
>
>What specifically is it asking for about the sbtree struct?
>Also, I presume the *less & *more are pointers to it's own struct...why??
Somewhere in the function that calls add_to_sbtree there is a pointer
to the tree to which y is about to be added. Call this ptr0.
Consider the situation at program startup. No trees have been created
yet. There is no tree to add y to. The program needs to create a
tree with y as the root. This situation is implemented in the code by
ptr0 a value of NULL. This is the C idiom for a pointer that does not
yet point to anything.
When it is time to call add_to_sbtree, it is not sufficient to simply
pass the value of ptr0. Because C passes by value, add_to_sbtree
would receive a copy of this value. Any changes that add_to_sbtree
makes to the value would be lost when add_to_sbtree returns. The
chosen method for allowing add_to_sbtree to change ptr0 is for the
calling function to pass its address. Since ptr0 has type sb_tree*,
its address must have type sb_tree** (as declared in the function
header). Then, add_to_sbtree can evaluate (and alter if desired) the
value of ptr0 by dereferencing sbtree. (The need to update the entry
count in the calling function is the reason entries has type int* and
not int.)
add_to_sbtree needs to determine if there already exists a tree to add
y to or not. It detects this situation by evaluating ptr0. Since
sbtree is the address of ptr0, *sbtree evaluates to the value of ptr0.
The expression
if (!*sbtree)
is exactly equivalent to
if (*sbtree == NULL)
and is the way the program asks "Does no tree exist at the moment so I
should create one?".
less and more never point to the same struct they are contained in.
They always point to subtrees that hang off the struct they are
contained in, if such a subtree exists. If it doesn't, they contain
NULL.
Using the notation struct(x) to indicate a struct with the value x in
the member y, consider a typical sequence:
ptr0 is NULL. add_to_sbtree is called with a value of 25. Space
is dynamically allocated to contain struct(25); the address of this
space is saved in ptr0; y is set to 25; less and more are both set to
NULL. In short hand, struct(25) contains 25, NULL, NULL.
ptr0 points to struct(25). add_to_sbtree is called with a value
of 10. *sbtree is not NULL. 10 < 25. add_to_sbtree is called
RECURSIVELY with the address of struct(25).less and the value 10. Now,
*sbtree is NULL and struct(10) is created as above but the address is
stored in *sbtree which is struct(25).less. Consequently, struct(25)
contains 25, &struct(10), NULL and struct(10) contains 10, NULL, NULL.
ptr0 still points to struct(25). add_sb_tree is called with a
value of 15. *sbtree is not NULL. 15 < 25. add_to_sbtree is called
recursively with the address of struct(25).less and value 15. *sbtree
is not NULL. 15 > 10. add_to_sbtree is again called recursively with
the address of struct(10).more and value 15. Now *sbtree is NULL and
struct(15) is created as above but the address is stored in
struct(10).more. Consequently, struct(25) is unchanged; struct(10)
contains 10, NULL, &struct(15); and struct(15) contains 15, NULL,
NULL.
If add_to_sbtree were no called with a value of 50, struct(50)
would be added at struct(25).more and struct(10) and struct(15) would
be unchanged.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-02-03 18:54 +0000 |
| Message-ID | <uP8Aw.574247$El2.256448@fx04.am4> |
| In reply to | #56922 |
jeffkrob16@gmail.com wrote:
> All,
>
> I'm working with the code from the "General Polygon Clipper" Project.
James and Bartc have already answered the question you asked, so I'm going
instead to answer a question you didn't ask...
> I've
> come across a recursive subroutine "add_to_sbtree" & included is the
> associated typedef struct.
...and it's about this phrase: "the associated typedef struct".
Thinking back to when I was fairly new to C, I remember having a similar
confusion here. I thought that "typedef struct" was a sort of two-word
keyword. But it isn't. It's a shorthand that combines two very different
concepts, and it's important to disentangle these two concepts from each
other.
There is, of course, no such thing as a "typedef struct". There are structs,
and there are typedefs. So let's look at them separately, and then see how
and why we combine them.
A struct is an "aggregate data type". My minimal research suggests that this
concept also exists in Fortran, so you should be fine with it.
A struct is a programmer-defined aggregate data type, so you get to choose
what it contains:
struct Point
{
int x;
int y;
};
for example. Now, the above is not a data definition. It defines a type. It
says: "there now exists a type 'struct Point', which has members int x and
int y."
If we wanted to define an instance of such a struct, we'd do it like this:
struct Point p;
p is now a struct Point, and p.x and p.y are its members.
We can take p's address: &p
We can define a pointer: struct Point *q = &p;
and so on. Okay, that'll do for struct, for now.
Enter the typedef.
The typedef keyword allows us to introduce a synonym for a type. Thus, if
we're feeling particularly unkind to our readers, we can do things like
this:
typedef int rabbit;
'rabbit' is now a synonym for 'int', so we can do this:
rabbit r = 0;
rabbit *pr = &r;
etc.
But this isn't a typedef int. It's just a typedef.
The syntax for typedef works like this: if you want a synonym X for a
particular type Y, start by writing a declaration of X:
Y X;
and then add typedef at the beginning:
typedef Y X;
X is now a synonym for Y.
So if, for example, we have an array of six pointers to function taking
double and returning int, but we want to make life easy on ourselves, we
start off with a function declaration:
int foo(double);
Now let's make that a pointer:
int (*foo)(double);
NOW let's make foo a synonym for "pointer to function taking double and
returning int":
typedef int (*foo)(double);
And now let's declare our array of six of them:
foo myfuncptrs[6];
Compared to the syntax for declaring such an array /without/ typedef, this
is a major win!
Okay, back to structs.
We're sick and tired of typing 'struct' at the front of every declaration of
a commonly-used struct. So we want to use a typedef. The rules are exactly
the same. Start off with your struct declaration:
struct Point
{
int x;
int y;
} mypoint;
and now add typedef to the front:
typedef struct Point
{
int x;
int y;
} mypoint;
You can now write: mypoint firstpoint, secondpoint; firstpoint.x = 6; and so
on.
Self-referential structures are a little trickier, because you have to
remember to use the word struct after all. You can't do this:
typedef struct Tree
{
tree *left;
tree *right;
int value;
} tree;
but you *can* do this:
typedef struct Tree
{
struct Tree *left;
struct Tree *right;
int value;
} tree;
Personally, I dislike this way of doing things. I think it's better to make
a clear distinction between the creation of the type and the creation of the
synonym:
struct Tree
{
struct Tree *left;
struct Tree *right;
int value;
};
typedef struct Tree tree;
Strictly speaking, the synonym could be 'Tree', but I prefer, again, to keep
the names different to avoid confusion. Normally, though, I don't rely on
case, but on an underscore:
struct tree_
{
struct tree_ *left;
struct tree_ *right;
int value;
};
typedef struct tree_ tree;
Note that the underscore, if you choose to use it, goes at the end, not at
the beginning. Many identifiers that begin with an underscore are reserved
for the implementation, so in practice it's best to avoid them completely.
But you're okay with underscores at the end.
The key point to take away is this: separate in your mind the concepts of
'typedef' and 'struct'. They are not related in any way, other than that you
can create a synonym for a struct, just as you can for any other type.
<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-02-03 11:50 -0800 |
| Message-ID | <ce5a98f1-157b-406b-b65f-eff7b54b1f28@googlegroups.com> |
| In reply to | #56922 |
#I wrote
#Jeff wrote:"
typedef struct sbt_t_shape /* Scanbeam tree */
{
double y; /* Scanbeam node y value */
struct sbt_t_shape *less; /* Pointer to nodes with lower y */
struct sbt_t_shape *more; /* Pointer to nodes with higher y */
} sb_tree;
static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
#i never had seen something as above... I suppose
#sbtree is one pointer pointer to int, sb_tree a int
{
if (!*sbtree)
{
/* Add a new tree node here */
MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
(*sbtree)->y= y;
(*sbtree)->less= NULL;
(*sbtree)->more= NULL;
(*entries)++;
}
else
{
if ((*sbtree)->y > y)
{
/* Head into the 'less' sub-tree */
add_to_sbtree(entries, &((*sbtree)->less), y);
}
else
{
if ((*sbtree)->y < y)
{
/* Head into the 'more' sub-tree */
add_to_sbtree(entries, &((*sbtree)->more), y);
}
}
}
}
*************************************************************
I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
if (!*sbtree)
What specifically is it asking for about the sbtree struct?
#it is the same of:
#if(*sbtree==NULL)
#in few word if that is 0
#we can write in *sbtree
#without make a leak because that
#memory point to null
#than fill that arg with a pointer
#that came from malloc
Also, I presume the *less & *more are pointers to it's own struct...why??
#I say they would point to entry
#argument
Thanks in advance,
Jeff
"
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-02-03 12:07 -0800 |
| Message-ID | <7acae636-8bc5-47ca-b444-64913faf0175@googlegroups.com> |
| In reply to | #56928 |
##I write #I wrote #Jeff wrote Also, I presume the *less & *more are pointers to it's own struct...why?? #I say they would point to entry #argument ## perhaps the new node is add in the ## tree pointed from 'entry'
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-02-03 15:14 -0500 |
| Message-ID | <d_9Aw.358108$_R5.195319@fx28.iad> |
| In reply to | #56928 |
On Tuesday February 3 2015 14:50, in comp.lang.c, "asetofsymbols@gmail.com"
<asetofsymbols@gmail.com> wrote:
>
> #I wrote
> #Jeff wrote:"
> typedef struct sbt_t_shape /* Scanbeam tree
> */
> {
> double y; /* Scanbeam node y value
> */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y
> */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y
> */
> } sb_tree;
>
> static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
>
> #i never had seen something as above... I suppose
> #sbtree is one pointer pointer to int, sb_tree a int
>
> {
> if (!*sbtree)
> {
[snip]
> I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
>
> if (!*sbtree)
>
> What specifically is it asking for about the sbtree struct?
sbtree is a pointer, it points at something, and that something is
*sbtree
The ! is a logical NOT; it results in 0 if that-which-it-is-applied-to is
non-zero, or 1 if that-which-it-is-applied-to is zero.
So (!*sbtree) evaluates to
0 when the thing pointed to by sbtree is nonzero,
or
1 when the thing pointed to by sbtree is zero
The thing pointed to by sbtree (that is, *sbtree) is itself a pointer, and
pointers with a value of zero point nowhere.
So, (!*sbtree) tests to see if the pointer pointed to by sbtree points
nowhere.
Now, <conditions> in C are either 0 or non-zero, with zero signifying
falsity (note that the results of a comparison or logical operator is
either 0 when false or 1 when true).
So
if (!*sbtree)
will execute the <true> side of the if statement when the pointer pointed to
by sbtree points nowhere.
> #it is the same of:
> #if(*sbtree==NULL)
Yes.
> #in few word if that is 0
> #we can write in *sbtree
> #without make a leak because that
> #memory point to null
> #than fill that arg with a pointer
> #that came from malloc
Yes
> Also, I presume the *less & *more are pointers to it's own struct...why??
Think of them as connections to other structures. The sbt_t_shape structure
pointed to by *sbtree connects to other sbt_t_shape structures through
these two links.
> #I say they would point to entry
> #argument
> Thanks in advance,
> Jeff
> "
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-02-03 15:06 -0800 |
| Message-ID | <hlk2da5s2heq8r1rvg3k4vhfdmdgbk8pr6@4ax.com> |
| In reply to | #56928 |
On Tue, 3 Feb 2015 11:50:56 -0800 (PST), asetofsymbols@gmail.com
wrote:
>
>#I wrote
>#Jeff wrote:"
>typedef struct sbt_t_shape /* Scanbeam tree */
>{
> double y; /* Scanbeam node y value */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
>} sb_tree;
>
>static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
>
>#i never had seen something as above... I suppose
>#sbtree is one pointer pointer to int, sb_tree a int
sbtree is a parameter of the function. It has type pointer to pointer
to sb_tree. sb_tree is an alternate name for the defined type struct
sbt_t_shape. At no point does either have anything to do with the
type int or an object of type int.
<snip>
>Also, I presume the *less & *more are pointers to it's own struct...why??
>#I say they would point to entry
>#argument
Each points to another instance of a struct which is how a leaf of the
current node is implemented (or contains NULL if the corresponding
leaf of the for this node does not yet exist).
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-02-03 22:19 -0800 |
| Message-ID | <37f13d6d-aec4-4a9d-bb6b-48879bfdc3ea@googlegroups.com> |
| In reply to | #56932 |
##Barry wrote: >#I wrote >#Jeff wrote:" >static void add_to_sbtree(int *entries, sb_tree **sbtree, double y) > >#i never had seen something as above... I suppose >#sbtree is one pointer pointer to int, sb_tree a int sbtree is a parameter of the function. It has type pointer to pointer to sb_tree. ##yes I seen one "," after sb_tree ##that does not exist ... sb_tree is an alternate name for the defined type struct sbt_t_shape. At no point does either have anything to do with the type int or an object of type int.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-02-03 21:40 +0000 |
| Message-ID | <87h9v2hdwz.fsf@bsb.me.uk> |
| In reply to | #56922 |
jeffkrob16@gmail.com writes:
> I'm working with the code from the "General Polygon Clipper"
> Project. I've come across a recursive subroutine "add_to_sbtree" &
> included is the associated typedef struct.
>
> ****************************************************************************
>
> typedef struct sbt_t_shape /* Scanbeam tree */
> {
> double y; /* Scanbeam node y value */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
> } sb_tree;
>
> static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
> {
> if (!*sbtree)
> {
> /* Add a new tree node here */
> MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
> (*sbtree)->y= y;
> (*sbtree)->less= NULL;
> (*sbtree)->more= NULL;
> (*entries)++;
> }
> else
> {
> if ((*sbtree)->y > y)
> {
> /* Head into the 'less' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->less), y);
> }
> else
> {
> if ((*sbtree)->y < y)
> {
> /* Head into the 'more' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->more), y);
> }
> }
> }
> }
Sometimes is helps to see a variety of ways to handle a give structure,
so here's "the other way" to do the same operation. Note how, at the
expense of assigning a value that has not changed as you go down the
tree, you can get away with one few indirection (fewer *s):
static sb_tree *add_to_sbtree(int *entries, sb_tree *sbtree, double y)
{
if (!sbtree) {
if (sbtree = malloc(sizeof *sbtree)) {
sbtree->y = y;
sbtree->less = sbtree->more = NULL;
*entries += 1;
}
}
else if (sbtree->y > y)
sbtree->less = add_to_sbtree(entries, sbtree->less, y);
else if (sbtree->y < y)
sbtree->more = add_to_sbtree(entries, sbtree->more, y);
return sbtree;
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-02-03 22:56 -0800 |
| Message-ID | <b2be2cd0-52fd-4da3-b8de-b36818ed7f1c@googlegroups.com> |
| In reply to | #56931 |
#Ben wrote:
static sb_tree *add_to_sbtree(int *entries, sb_tree *sbtree, double y)
{
if (!sbtree) {
if (sbtree = malloc(sizeof *sbtree)) {
#but if I want to change memory pointed from m in
#int *m;
#it is need we call f(&m) and has to be f(int**)
#so I think above line should be
#*sbtree=malloc(etc
#and the arg should be sb_tree **sbtree
#but I see it wrong
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-02-03 23:02 -0800 |
| Message-ID | <3cf18129-0908-41f9-a1b6-3b32b817bd6d@googlegroups.com> |
| In reply to | #56935 |
##I wrote: #but I see it wrong ##but possibly I see it wrong
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-02-04 00:01 -0800 |
| Message-ID | <b4c1de56-6cb9-4601-8f19-8738f78bcaed@googlegroups.com> |
| In reply to | #56935 |
Ok I thought wrong... It returns the value...
[toc] | [prev] | [next] | [standalone]
| From | jeffkrob16@gmail.com |
|---|---|
| Date | 2015-02-04 10:53 -0800 |
| Message-ID | <08f17b24-a4bb-4e3b-ba52-035287ab63a5@googlegroups.com> |
| In reply to | #56922 |
On Tuesday, February 3, 2015 at 12:33:34 PM UTC-5, jeffk...@gmail.com wrote:
> All,
>
> I'm working with the code from the "General Polygon Clipper" Project. I've come across a recursive subroutine "add_to_sbtree" & included is the associated typedef struct.
>
> ****************************************************************************
>
> typedef struct sbt_t_shape /* Scanbeam tree */
> {
> double y; /* Scanbeam node y value */
> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
> } sb_tree;
>
> static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
> {
> if (!*sbtree)
> {
> /* Add a new tree node here */
> MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
> (*sbtree)->y= y;
> (*sbtree)->less= NULL;
> (*sbtree)->more= NULL;
> (*entries)++;
> }
> else
> {
> if ((*sbtree)->y > y)
> {
> /* Head into the 'less' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->less), y);
> }
> else
> {
> if ((*sbtree)->y < y)
> {
> /* Head into the 'more' sub-tree */
> add_to_sbtree(entries, &((*sbtree)->more), y);
> }
> }
> }
> }
>
> *************************************************************
> I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
>
> if (!*sbtree)
>
> What specifically is it asking for about the sbtree struct?
> Also, I presume the *less & *more are pointers to it's own struct...why??
>
> Thanks in advance,
> Jeff
Everyone,
Thanks for all the info/details. I must admit, I still, at times, have a difficult time thinking in terms of 'pointers' vs. 'normal' variables & keeping everything straight & untangled.
Out of curiosity, is there a way to have a 'normal variable' version of the struct/subroutine or, just because the way it is written/structured, it can't be done?
Thanks again,
Jeff
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-04 11:21 -0800 |
| Message-ID | <72661cda-1046-4d61-bd2e-7c68bb259d82@googlegroups.com> |
| In reply to | #56944 |
On Wednesday, February 4, 2015 at 6:54:05 PM UTC, jeffk...@gmail.com wrote: > > Out of curiosity, is there a way to have a 'normal variable' version > of the struct/subroutine or, just because the way it is > written/structured, > it can't be done? > C passes arguments by value. If you want to change a value, you pass a pointer to it (the address), and write through the address. Also, arrays have to be passed by pointer. Typical C tree code will create a tree consisting of nodes allocated by malloc(), and hung together by pointer members of nodes. So you can't really get away from pointers, they're very idiomatic, characteristic C.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-02-04 19:32 +0000 |
| Message-ID | <mats3k$vkk$1@dont-email.me> |
| In reply to | #56944 |
On 04/02/2015 18:53, jeffkrob16@gmail.com wrote: > Out of curiosity, is there a way to have a 'normal variable' version of the struct/subroutine or, just because the way it is written/structured, it can't be done? You can replace simple pointers by integer indices into a global array of structs that you then have to manage. (With some extra complexity because each integer index has to be paired with a particular array.) With pointer-to-pointers as used here, just have the function return the new index (of the newly allocated struct) as its return value. But C is design to use pointers and the resulting code might look a bit odd. It's best to use conventional methods. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2015-02-04 11:59 -0800 |
| Message-ID | <nur4dalj2meibge62ed3p3melb9tihiha1@4ax.com> |
| In reply to | #56944 |
On Wed, 4 Feb 2015 10:53:42 -0800 (PST), jeffkrob16@gmail.com wrote:
>On Tuesday, February 3, 2015 at 12:33:34 PM UTC-5, jeffk...@gmail.com wrote:
>> All,
>>
>> I'm working with the code from the "General Polygon Clipper" Project. I've come across a recursive subroutine "add_to_sbtree" & included is the associated typedef struct.
>>
>> ****************************************************************************
>>
>> typedef struct sbt_t_shape /* Scanbeam tree */
>> {
>> double y; /* Scanbeam node y value */
>> struct sbt_t_shape *less; /* Pointer to nodes with lower y */
>> struct sbt_t_shape *more; /* Pointer to nodes with higher y */
>> } sb_tree;
>>
>> static void add_to_sbtree(int *entries, sb_tree **sbtree, double y)
>> {
>> if (!*sbtree)
>> {
>> /* Add a new tree node here */
>> MALLOC(*sbtree, sizeof(sb_tree), "scanbeam tree insertion");
>> (*sbtree)->y= y;
>> (*sbtree)->less= NULL;
>> (*sbtree)->more= NULL;
>> (*entries)++;
>> }
>> else
>> {
>> if ((*sbtree)->y > y)
>> {
>> /* Head into the 'less' sub-tree */
>> add_to_sbtree(entries, &((*sbtree)->less), y);
>> }
>> else
>> {
>> if ((*sbtree)->y < y)
>> {
>> /* Head into the 'more' sub-tree */
>> add_to_sbtree(entries, &((*sbtree)->more), y);
>> }
>> }
>> }
>> }
>>
>> *************************************************************
>> I'm sorry but stupid ol' fortran guy doesn't understand the first 'if';
>>
>> if (!*sbtree)
>>
>> What specifically is it asking for about the sbtree struct?
>> Also, I presume the *less & *more are pointers to it's own struct...why??
>>
>> Thanks in advance,
>> Jeff
>
>Everyone,
>
>Thanks for all the info/details. I must admit, I still, at times, have a difficult time thinking in terms of 'pointers' vs. 'normal' variables & keeping everything straight & untangled.
>
>Out of curiosity, is there a way to have a 'normal variable' version of the struct/subroutine or, just because the way it is written/structured, it can't be done?
Currently the function updates two variables whose addresses are
provided by the calling function. If the int that entries points to
was a global variable, there would be no need to pass its address to
the function. The function could update the int by name.
Now that the function has to update only one variable (the pointer),
it can do this by returning the address as part of the return
statement. The statement that calls the function would have to be an
assignment statement so that the caller keeps track of the returned
value.
The function becomes:
static void add_to_sbtree(sb_tree *sbtree, double y)
{
if (!sbtree)
{
/* Add a new tree node here */
MALLOC(sbtree, sizeof(sb_tree), "scanbeam tree insertion");
sbtree->y= y;
sbtree->less= NULL;
sbtree->more= NULL;
global_counter++;
}
else
{
if (sbtree->y > y)
{
/* Head into the 'less' sub-tree */
sbtree->less = add_to_sbtree(sbtree->less, y);
}
else
{
if (sbtree->y < y)
{
/* Head into the 'more' sub-tree */
sbtree->more = add_to_sbtree(sbtree->more, y);
}
}
}
return sbtree;
}
Remember that each time the function is called recursively, a new copy
of sbtree is created. Within that nesting level, sbtree is changed
only if the pointer is NULL. Consequently, each non-NULL pointer is
assigned its current value as each level of recursion returns and the
NULL pointer is assigned the address of the newly allocated space.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | hormelfree@gmail.com |
|---|---|
| Date | 2015-02-04 15:30 -0800 |
| Message-ID | <ba44af53-b35b-4c7d-8f84-d25bf2ab9c59@googlegroups.com> |
| In reply to | #56944 |
On Wednesday, February 4, 2015 at 10:54:05 AM UTC-8, jeffk...@gmail.com wrote: > On Tuesday, February 3, 2015 at 12:33:34 PM UTC-5, jeffk...@gmail.com wrote: > > Thanks for all the info/details. I must admit, I still, at times, have a difficult time thinking in terms of 'pointers' vs. 'normal' variables & keeping everything straight & untangled. > This just means you're human... > Out of curiosity, is there a way to have a 'normal variable' version of the struct/subroutine or, just because the way it is written/structured, it can't be done? > Of course it could be done in a less confusing way using more standard variables, but then it would be less "elegant" and more importantly, would confuse far less people...remember, once you master "C" you've got a skill that very few people have...in fact, you don't even have to master it, because so few people have mastered it it's unlikely anybody will know you're faking it... And isn't that what's most important in a job "skill"? --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | jeffkrob16@gmail.com |
|---|---|
| Date | 2015-02-04 19:41 -0800 |
| Message-ID | <8d68369b-24e9-485a-aa58-07ed34a6aee9@googlegroups.com> |
| In reply to | #56951 |
On Wednesday, February 4, 2015 at 6:30:59 PM UTC-5, horme...@gmail.com wrote: > On Wednesday, February 4, 2015 at 10:54:05 AM UTC-8, jeffk...@gmail.com wrote: > > On Tuesday, February 3, 2015 at 12:33:34 PM UTC-5, jeffk...@gmail.com wrote: > > > > Thanks for all the info/details. I must admit, I still, at times, have a difficult time thinking in terms of 'pointers' vs. 'normal' variables & keeping everything straight & untangled. > > > This just means you're human... > > > Out of curiosity, is there a way to have a 'normal variable' version of the struct/subroutine or, just because the way it is written/structured, it can't be done? > > > Of course it could be done in a less confusing way using more standard > variables, but then it would be less "elegant" and more importantly, would > confuse far less people...remember, once you master "C" you've got a skill > that very few people have...in fact, you don't even have to master it, > because so few people have mastered it it's unlikely anybody will know > you're faking it... > > And isn't that what's most important in a job "skill"? > > --- > William Ernest Reid HA - Got that right!! Thanks for the reply. I'm the kind of guy that prefers to program in the 'KISS' way so when I go back months/years later to it (if required), I don't need a lifetime novel of documentation to explain what/why I did it. With pointers being abstract as they are (passing addresses & not values), code logic can get spaghetti-like if the programmer is not careful leaving out associated documentation. With Fortran adopting pointers, it can get that way as well so this isn't just a 'C' thing. (not trying to start a flame war...just my opinion/observation) And, thanks again to everyone for their input & assistance. Jeff
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web