tree

[Bill Cunningham]

I am messing up with pointers again. I don't know what I've done here.
In C there can be no new so I am trying malloc and failing.

#include <stdio.h>
#include <stdlib.h>

struct node *newNode(int data)
{
struct node *node=malloc(*node);
struct node->data;
struct node->left=NULL;
struct node->right=NULL;
return (node);}

a.c: In function `newNode':
a.c:6: dereferencing pointer to incomplete type
a.c:7: parse error before '->' token
a.c:8: parse error before '->' token
a.c:9: parse error before '->' token

 

[Bill Cunningham]

When you've understood that problem and fixed it, come on back.

Ok I didn't put the includes and the struct in a header file to share
amongst .c files. I made changes and there's still a problem with malloc. I
haven't usesd malloc on my own so I don't know much about it. Only that it
returns void * and free() is needed after using it.

#include <stdio.h>
#include <stdlib.h>

struct node {
int data;
struct node *right, *left;
};

struct node *newNode(int data)
{
struct node *node = malloc(*node);
struct node->data;
struct node->left = NULL;
struct node->right = NULL;
return (node);
}

 

[osmium]

I haven't usesd malloc on my own so I don't know much about it.

Well, then, that is where you start!!!! Experiment with malloc in a much
less hostile learning environment than trying to make a tree structure. Make
a simple array of int, put stuff in it and retrieve it later. If you learn
anything you didn't already know, make notes. If you don't learn anything
start over. If you can't learn to makes notes, and remember where the notes
are and what the notes mean, you are pretty much stuck in the era of
Neanderthal man with rocks and wooly mammoths and no written language. You
will have to start by inventing reading and writing.

 

[Beej Jorgensen]

I haven't usesd malloc on my own so I don't know much about it. Only
that it returns void * and free() is needed after using it.

Those are good things to know. But here's one:

What arguments does malloc() take?

-Beej

 

[Nick Keighley]

    Ok I didn't put the includes and the struct in a header file to share
amongst .c files. I made changes and there's still a problem with malloc.

what problem? Are we expected to read your mind? The code you posted
doesn't have a main() function so you can't have run it.

I
haven't usesd malloc on my own so I don't know much about it.

read the documentation. You have a copy of K&R. Lookup malloc()

Only that it
returns void * and free() is needed after using it.

#include <stdio.h>
#include <stdlib.h>

struct node {
    int data;
    struct node *right, *left;

};

struct node *newNode(int data)
{
    struct node *node = malloc(*node);

what is the paraemter to malloc()?

 

[Keith Thompson]

Ok I didn't put the includes and the struct in a header file to share
amongst .c files. I made changes and there's still a problem with malloc. I
haven't usesd malloc on my own so I don't know much about it. Only that it
returns void * and free() is needed after using it.

There's more to know about malloc() than that. And you can very
easily learn what you need to know by reading the documentation, which
will tell you, among other things, what argument it expects.

[...]

struct node { [...]
};

struct node *newNode(int data)
{
struct node *node = malloc(*node);

[...]

Once piece of advice: don't use the same identifier for two
different things. Here you're using it both for the struct tag
and for a pointer object. This is legal, but it makes it more
difficult to talk, or even think, about your code.

Your variable "node" is a pointer, not a node, so "node" is a bad
name for it.

As for your mis-use of malloc, I'll repeat
some advice I gave you over a year ago; see
http://groups.google.com/group/comp.lang.c/msg/6da991ad26d30ed9,
Message-ID <[email protected]>, for the full article.

Every time you want to use a function from the standard C library,
whether it's fopen, fclose, printf, fprintf, isalpha, or anything
else, LOOK IT UP FIRST. Have the documentation for the function in
front of you, and read and *understand*:
what the function does;
the meanings and types of its arguments;
the meaning and type of its return value;
and the header in which it's declared,
before you even consider typing the first letter of the function's
name.

Don't use a function without knowing where it's declared. Don't use a
function without understanding what it does. Don't compare a
function's return value to NULL until and unless you *know* that it
returns a pointer, and what a NULL result means.

I have to look this stuff up myself. I honestly couldn't tell you
with certainty off the top of my head the order of the parameters for
fwrite(). (I just now checked the man page, and found that I had
mentally reversed the second and third parameters.)

If you can learn that lesson (and *retain* it), you'll have made some
actual progress.

 

[Barry Schwarz]

what problem? Are we expected to read your mind? The code you posted
doesn't have a main() function so you can't have run it.

Let's not encourage him to execute code that can't even compile.

 

[Ben Bacarisse]

I have to look this stuff up myself. I honestly couldn't tell you
with certainty off the top of my head the order of the parameters for
fwrite(). (I just now checked the man page, and found that I had
mentally reversed the second and third parameters.)

Yes, I kept having to look it up until for some reason I ended up
associating it with the scene in the Python's "Life of Brian" where
Brian gets his Latin graffiti corrected by a centurion[1] (he's trying
to write "Romans go home!" -- Romani ite domum).

The part that always tickles me is the centurion correcting Brian's
singular "go" by pulling his hair and saying "how many Romans?". This
is after specifying _what_ is to go (the void pointer and the size of
each item) and just before saying _where_ it is to go to (the stream).

I now can't think of fwrite without imagining the prototype as:

size_t fwrite(const void *romani, size_t size_of_a_roman,
size_t how_many_romans, FILE *domum);

YMMV

[1]

 

[Richard Tobin]

I have to look this stuff up myself. I honestly couldn't tell you
with certainty off the top of my head the order of the parameters for
fwrite().

That's easy: it's the opposite of what you'd expect. At least, it is
until you internalize that rule sufficiently...

-- Richard

 

[Nick Keighley]

news:[email protected]...

[...]> struct node {
[...]

};

struct node *newNode(int data)
{
    struct node *node = malloc(*node);

[...]

Once piece of advice: don't use the same identifier for two
different things.  Here you're using it both for the struct tag
and for a pointer object.  This is legal, but it makes it more
difficult to talk, or even think, about your code.

Your variable "node" is a pointer, not a node, so "node" is a bad
name for it.

I'm not sure about this. I actually dislike things like
Node *nodePtr;

looks a bit Hungarian to me. I'd use

typedef struct
{

} Node;

Node *newNode (int data)
{
Node *node = malloc (sizeof Node);

As for your mis-use of malloc, I'll repeat
some advice I gave you over a year ago; seehttp://groups.google.com/group/comp.lang.c/msg/6da991ad26d30ed9,
Message-ID <[email protected]>, for the full article.

Every time you want to use a function from the standard C library,
whether it's fopen, fclose, printf, fprintf, isalpha, or anything
else, LOOK IT UP FIRST.  Have the documentation for the function in
front of you, and read and *understand*:
    what the function does;
    the meanings and types of its arguments;
    the meaning and type of its return value;
    and the header in which it's declared,
before you even consider typing the first letter of the function's
name.

Don't use a function without knowing where it's declared.  Don't use a
function without understanding what it does.  Don't compare a
function's return value to NULL until and unless you *know* that it
returns a pointer, and what a NULL result means.

I have to look this stuff up myself.  

ditto. With the internet it's really easy, you can copy/paste
the prototype straight into your code