twitter: comp.lang.c - 25 new messages in 6 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* Stylistic questions on UNIX C coding. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
* Beginner's guide to MinGW? - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/e2cff1c3cf36ab5f?hl=en
* Has thought been given given to a cleaned up C? Possibly called C+. - 12
messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
* -2147483648 and gcc optimisation, all sorts of different results - 2
messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/1e4020710ed342ba?hl=en
* Casting jmp_buf to void * - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/a9e559468513ce12?hl=en
* Depth of Binary Tree - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c/t/8246aca121941e23?hl=en

==============================================================================
TOPIC: Stylistic questions on UNIX C coding.
http://groups.google.com/group/comp.lang.c/t/51d2b24a60d73f18?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Mar 11 2010 7:35 am
From: BruceS

On Mar 10, 1:29 pm, Anand Hariharan <mailto.anand.hariha...@gmail.com>
wrote:
> On Mar 4, 8:40 am, Richard <rgrd...@gmail.com> wrote:
> (...)
>
> > You dont say "if pi is larger than p".You say "if p is larger than
> > pi".
>
> They are not equivalent statements. ;-)

No, they certainly aren't (good catch)! If one writes code with the
assumption that these are the same, one introduces a bug. So, a
better question might be which of the following would you say:

"e is larger than pi"
"pi is larger than e"

I know which *I* prefer.

==============================================================================
TOPIC: Beginner's guide to MinGW?
http://groups.google.com/group/comp.lang.c/t/e2cff1c3cf36ab5f?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Mar 11 2010 7:46 am
From: raltbos@xs4all.nl (Richard Bos)

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:

> On 9 Mar, 22:20, jacob navia <ja...@jacob.remcomp.fr> wrote:
> > MikeC a crit :
>
> > > I know this isn't a C-language related question, but before I get into
> > > C, =A0I have to have a compiler.

> > Well,use lcc-win. It is a free compiler that is MUCH easier to use for a
> > beginner than mingw.

> > Disclaimer:
> > This message is written by the author of lcc-win. So, it is a biased
> > advice. Use with care :-)- Hide quoted text -
>
> Microsoft's "Visual C++ Express" is another free compiler. And despite
> the weird name it compiles bog-standard C. Reasonable IDE. Some say it
> is a very large download. I can't say I noticed.

Dev-C++ is another, rather simple but efficient one; Code::Blocks yet
another. Both of those are based on gcc+MinGW. PellesC is another
implementation based on lcc.
For starters, my favourite would be Dev-C++. If you want to build a real
project, one of the others may be more your thing.

Richard

== 2 of 3 ==
Date: Thurs, Mar 11 2010 9:54 am
From: Seebs

On 2010-03-11, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> Because one want to program in C and use some features from C++
> on top of C code.

Bad idea.

If you're going to write C++, write C++. Using little bits of C++ creates
particularly unmaintainable code, because no two people trying to use
"just a little" C++ will pick the same features. You'll thus have some hunks
of code using C idioms and some using C++ idioms for the same things.

> I mean things would be simpler. Basic idea is compatibility.

Not really, anymore. There's some compatibility, but it's not really all
that much, and I don't think it's particularly good to try to rely on it.

> and c++ is C89/90 based language with added exceptions,

And some overlap with C99.

> templates (automatic calling of init/deinit, copy, assign functions
> that take first parameter as struct) and syntactic sugar.

It's a lot more than that, now. C with Classes was pretty much just syntactic
sugar. C++ is really a pretty distinct language.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 3 ==
Date: Thurs, Mar 11 2010 10:39 am
From: Branimir Maksimovic

On 11 Mar 2010 17:54:09 GMT
Seebs <usenet-nospam@seebs.net> wrote:

> On 2010-03-11, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
> > Because one want to program in C and use some features from C++
> > on top of C code.
>
> Bad idea.
>
> If you're going to write C++, write C++. Using little bits of C++
> creates particularly unmaintainable code, because no two people
> trying to use "just a little" C++ will pick the same features.

Hm, you can;t write c++ , especially if doing low level things.
But put on top c++ classes and syntactic sugar, wrap it up
no problem ;)

> You'll thus have some hunks of code using C idioms and some using C++
> idioms for the same things.

Well, that depends on how things are organized.
You can have pure C modules and C++ modules linked in one program.

>
> > I mean things would be simpler. Basic idea is compatibility.
>
> Not really, anymore. There's some compatibility, but it's not really
> all that much, and I don't think it's particularly good to try to
> rely on it.

True ;(
No, that is not useful for pragmatic approach.

>
> > and c++ is C89/90 based language with added exceptions,
>
> And some overlap with C99.
C99 grrrrr. ;)

>
> > templates (automatic calling of init/deinit, copy, assign functions
> > that take first parameter as struct) and syntactic sugar.
>
> It's a lot more than that, now. C with Classes was pretty much just
> syntactic sugar. C++ is really a pretty distinct language.

Unfortunately.

Greets!

--
http://maxa.homedns.org/

Sometimes online sometimes not

==============================================================================
TOPIC: Has thought been given given to a cleaned up C? Possibly called C+.
http://groups.google.com/group/comp.lang.c/t/5954dc70a43f9f8e?hl=en
==============================================================================

== 1 of 12 ==
Date: Thurs, Mar 11 2010 8:13 am
From: "io_x"

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4b98b93b$0$825$4fafbaef@reader5.news.tin.it...
>> why not somethig of this kind
>> f64 v;
>> cout << fmt("%4:4f64") << v;

[post to c and c++ newsgroup]

the above should be possible in C++ (pheraps using instead "%4.4f").

don't remember what is fmt, could be one "stream manipulator"? could be
one class [the call to one constructor of a tmp object]?
don't know. do you know it someone of you?

Is it possible this below?
double a, b;
cout << SPrintf("%2.2f %2.3f", a, b) << "\n";

with SPrintf() one function (stream manipulator?)
ostream& SPrintf(ostream& v, char* fmt, ...)?
that print like printf() in stdout?

== 2 of 12 ==
Date: Thurs, Mar 11 2010 9:27 am
From: Nick Keighley

On 10 Mar, 21:56, Thomas Richter <t...@math.tu-berlin.de> wrote:
> Flash Gordon wrote:

<snip>

> > My experience is that operator overloading leads to confusion for
> > experienced users.
>
> In most cases, it should be avoided. The C++ overloading of >> and <<
> for IO operations is definitely a pretty bad idea. There are rare cases
> where it does make sense because the operator has a very natural meaning
> (vector addition, matrix multiplication). It is a feature that should be
> used with care. But >> and << for I/O is not one of the

in practice it works quite well

what about comparison and assignment?
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 3 of 12 ==
Date: Thurs, Mar 11 2010 9:28 am
From: Nick Keighley

On 10 Mar, 22:38, jacob navia <ja...@jacob.remcomp.fr> wrote:
> Richard Bos a écrit :
> > jacob navia <ja...@spamsink.net> wrote:

> >> My opinion is that C should be developed further, exactly BECAUSE is
> >> a simple language. Adding a container library to C doesn't make the
> >> language any bigger or more complicated but makes programs COMPATIBLE
> >> because it is possible to interchange data with standard API/containers.
>
> > I'm sorry, but... did you _really_ just write something to the tune of:
> > "C is a simple language. Adding a large, complicated gathering of data
> > structures to it won't make it any bigger and more complicated"?
>
> > Because if you did, I'd like to know what the French government thinks
> > of the stuff you imported from some "coffee shop" in Amsterdam; and if
> > you didn't, I'd like to know how you can possibly think that any
> > flexible container library that could be good enough to use by the
> > majority of C users could ever _not_ be too large, complicated, and
> > highly over-specced to use.
>
> The container library is around 80K (32 bit machines)
>
> In that space I have
> o lists (double/sinlgle linked)
> o bitstrings
> o AVL trees
> o Red/Black trees
> o Dictionary (Hash tables)
> o Flexible arrays.
>
> Is 80K "too large" ???
>
> Over-specced?
>
> You have remained silent (as all other "regs") in the discussions
> about the library here.

how can you complain about him being silent /and/ complain about him
commenting on your proposal?

> It is very easy. You limit yourself to piss at other people's proposals
> without ever proposing anything.

perhaps he doesn't see the need for a library like yours in the
standard. Why can't you confine yourself to a technical discussion
instead of these rants?
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 4 of 12 ==
Date: Thurs, Mar 11 2010 9:28 am
From: jacob navia

Jasen Betts a écrit :
> On 2010-03-10, jacob navia <jacob@jacob.remcomp.fr> wrote:
>> Richard Bos a écrit :
>>> jacob navia <jacob@spamsink.net> wrote:
>> The container library is around 80K (32 bit machines)
>>
>> In that space I have
>> o lists (double/sinlgle linked)
>> o bitstrings
>> o AVL trees
>> o Red/Black trees
>> o Dictionary (Hash tables)
>> o Flexible arrays.
>
> can you plug-in another container system
> (eg: indexed on-disk storage like libdb )
> by writing a wrapper?
>

Yes. If you look at the header files, all containers have
One creation function that returns a structure with
a pointer to a table of methods as its first member,
then some standard fields (size, length, number of
elements), and then you are on you own.

If you follow the directives (not required but useful)
you name your methods the same as other containers
Add for adding one element, etc

Syntax is not very pretty:

Container->lpVtbl->Add(Container, element);

but you get used very quickly. Otherwise

#define Container_Add(a,b) a->lpVtbl->Add(a,b)
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 5 of 12 ==
Date: Thurs, Mar 11 2010 9:29 am
From: Dag-Erling Smørgrav

Michael Foukarakis <electricdelta@gmail.com> writes:
> Dag-Erling Smørgrav <des@des.no> wrote:
> > OpenBSD's strlcpy(), for one.
> Those aren't any more secure than regular strcpy().

That's a pretty tall claim. It will be interesting to see you back it
up with actual arguments and not just bluster.

DES
--
Dag-Erling Smørgrav - des@des.no
--
comp.lang.c.moderated - moderation address: clcm@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.

== 6 of 12 ==
Date: Thurs, Mar 11 2010 9:29 am
From: Dag-Erling Smørgrav

Flash Gordon <smap@spam.causeway.com> writes:
> It doesn't need a standard for name mangling in the sense of something
> added to the language standard. All it needs is for the implementation
> (or OS) to decide on what method it will use (which can be considered
> a standard for that particular implementation or OS), just as it has
> to decide currently how simple names will be stored in the object file
> (assuming there is such a thing).

Significant length of identifiers, for instance. I don't remember what
the minimum is in the current standard, but imagine an ABI where
identifiers are truncated at 32 characters. Throw in namespaces, and
suddenly the length of the significant portion varies depending on the
length of the name of the namespace, you have to subtract a couple of
characters to serve as separators, etc. Nested namespaces complicate
the matter further. I'm not saying these problems can't be solved
(clearly they've been solved in C++), but they will require a lot of
thought.

> A simple way of avoiding breaking anything existing is for the
> implementation to decide that anything not in a namespace will be
> unmangled, and anything defined as in a namespace will start with a
> character which is not currently (for that implementation) a valid
> character to start an identifier.

Too many assumptions here which don't hold up in real life. An addition
to the standard that requires changing the underlying ABI and in the
object file format will most likely be ignored and will only serve to
undermine the industry's respect for the standard and the committee.

== 7 of 12 ==
Date: Thurs, Mar 11 2010 9:30 am
From: Dag-Erling Smørgrav

Andrew Poelstra <apoelstra@localhost.localdomain> writes:
> Feeling C++-ey would be simple enough without any standard library
> changes:
>
> namespace std {
> #include <stdio.h>
> #include <stdlib.h>
> }
>
> And boom, you've got std::malloc() and std::puts() and all that.

You can't randomly wrap declarations for existing symbols in a
namespace. The linker won't find them.

== 8 of 12 ==
Date: Thurs, Mar 11 2010 9:31 am
From: Dag-Erling Smørgrav

Jasen Betts <jasen@xnet.co.nz> writes:
> The linker doesn't have namespaces, C++ only has mamespaces because
> the compiler mangles names, and each compiler mangles differently.

Luckily, you're wrong. Name mangling rules are part of the ABI so
different compilers can coexist on the same platform.

== 9 of 12 ==
Date: Thurs, Mar 11 2010 9:32 am
From: Dag-Erling Smørgrav

Andrew Poelstra <apoelstra@localhost.localdomain> writes:
> IRRC C99 required changes to linkers,

Details? Apart from increasing the length of the significant portion of
identifiers, that is.

== 10 of 12 ==
Date: Thurs, Mar 11 2010 9:32 am
From: Dag-Erling Smørgrav

jacob navia <jacob@jacob.remcomp.fr> writes:
> o AVL trees
> o Red/Black trees

What is the advantage of having both? AFAIK they have the same
semantics and the same computational complexity.

== 11 of 12 ==
Date: Thurs, Mar 11 2010 9:32 am
From: Dag-Erling Smørgrav

Ian Collins <ian-news@hotmail.com> writes:
> I agree. That is one reason why containers are part of the C++
> standard library and not the C one. Containers were a bodge in Java
> before generics were bolted onto that language.

They're still a bodge. Java's generics are just syntactic sugar to hide
down- and up-casts between Object and whatever it is you want to put in
your container. Same thing with enums, they're just syntactic sugar for
static singleton objects of subclasses of a user-defined class.

== 12 of 12 ==
Date: Thurs, Mar 11 2010 9:33 am
From: Dag-Erling Smørgrav

Branimir Maksimovic <bmaxa@hotmail.com> writes:
> For that matter I am pretty much repulsive to Java libs.

I'm sorry they feel that way about you :)

==============================================================================
TOPIC: -2147483648 and gcc optimisation, all sorts of different results
http://groups.google.com/group/comp.lang.c/t/1e4020710ed342ba?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Mar 11 2010 8:33 am
From: Eric Sosman

On 3/11/2010 9:59 AM, Ben Bacarisse wrote:
> "tom_usenet@optusnet.com.au"<tom_usenet@optusnet.com.au> writes:
>
>> I'm surprised at the different results I can get from code with and
>> without optimisation where overflow is involved.
>>
>> I suspect this was "done to death" about 20 years ago, but
>> I can't find anything in comp.lang.c matching this. Is this
>> the "if you overflow the compiler can do whatever it likes"
>> clause?
>
> Looks like it, yes.
>
>> The original problem I was trying to solve is why a simple
>> embedded "printf("%ld")" was printing random garbage when
>> handed -2147483648.
>
> That sounds quite different. For the "long int" that you seem to be
> using it would be a library bug for printf("%ld", x) to print anything
> but -2147483648. Did you mean that printf is being handed something
> apparently random when you expected it to be handed -2147483648?

The way the value is "handed" to printf() may make a
difference, and so may the applicable version of the Standard.
Note that the value 2147483648 is too large for a 32-bit long,
so the operand of the `-' operator will be of a different type.
The chosen type depends on the Standard version: Under C90 rules
you'll get an unsigned long, C99 gives (signed) long long. The
unary `-' operator is then applied; under C90 you wind up with
the unsigned long 2147483648, C99 gives the negative -2147483648
as a long long.

Passing either of these to "%ld" is undefined behavior, because
"%ld" wants a (signed) long, period. Under C90 you're very likely
to get away with it and see the negative output you were expecting
all along, but under C99 you'll be passing a (probably) 64-bit
value where a 32-bit value was expected. This could easily throw
things off and generate the garbage the O.P. encountered.

In short, under C99

printf ("%ld\n", -2147483648); // passes LL

may plausibly generate different output than

long num = -2147483648; // LL converts to L
printf ("%ld\n", num);

... because of the type mismatch. (There's also the potential for
conversion issues in the second fragment, but that's unlikely to
be the source of the trouble.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 2 of 2 ==
Date: Thurs, Mar 11 2010 8:53 am
From: Ben Bacarisse

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 3/11/2010 9:59 AM, Ben Bacarisse wrote:
>> "tom_usenet@optusnet.com.au"<tom_usenet@optusnet.com.au> writes:
>>
>>> I'm surprised at the different results I can get from code with and
>>> without optimisation where overflow is involved.
>>>
>>> I suspect this was "done to death" about 20 years ago, but
>>> I can't find anything in comp.lang.c matching this. Is this
>>> the "if you overflow the compiler can do whatever it likes"
>>> clause?
>>
>> Looks like it, yes.
>>
>>> The original problem I was trying to solve is why a simple
>>> embedded "printf("%ld")" was printing random garbage when
>>> handed -2147483648.
>>
>> That sounds quite different. For the "long int" that you seem to be
>> using it would be a library bug for printf("%ld", x) to print anything
>> but -2147483648. Did you mean that printf is being handed something
>> apparently random when you expected it to be handed -2147483648?
>
> The way the value is "handed" to printf() may make a
> difference, and so may the applicable version of the Standard.
> Note that the value 2147483648 is too large for a 32-bit long,
> so the operand of the `-' operator will be of a different type.
> The chosen type depends on the Standard version: Under C90 rules
> you'll get an unsigned long, C99 gives (signed) long long. The
> unary `-' operator is then applied; under C90 you wind up with
> the unsigned long 2147483648, C99 gives the negative -2147483648
> as a long long.

I was unclear in a way that is depressingly common (not just for me
but I do it quite often): I meant the mathematical value -2147483648
not the C expression. Given that, I think I am right that printf must
print "-2147483648" with the 32 bit longs being used by the OP.

> Passing either of these to "%ld" is undefined behavior, because
> "%ld" wants a (signed) long, period. Under C90 you're very likely
> to get away with it and see the negative output you were expecting
> all along, but under C99 you'll be passing a (probably) 64-bit
> value where a 32-bit value was expected. This could easily throw
> things off and generate the garbage the O.P. encountered.

That's a good point, but it seems unlikely that the original case the
OP is describing is one where the C constant expression -2147483648 is
the actual argument of printf. Why would anyone write that?

<snip>
--
Ben.

==============================================================================
TOPIC: Casting jmp_buf to void *
http://groups.google.com/group/comp.lang.c/t/a9e559468513ce12?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Mar 11 2010 9:10 am
From: Noob

Hello everyone,

I'm using a library which provides a void *user_data field
inside the struct used everywhere within the library.

I need to stuff a jmp_buf inside user_data.

I suppose I can't write

jmp_buf env;
ctx->user_data = env;

and then use ctx->user_data as setjmp's and longjmp's parameter?

Instead, I'd have to write

jmp_buf env;
ctx->user_data = &env;

and when I need the jmp_buf, I have to write
*(jmp_buf *)ctx->user_data
or
jmp_buf *envp = ctx->user_data;
*envp

Did I get it right?
Is there different way to do this?

Regards.

== 2 of 3 ==
Date: Thurs, Mar 11 2010 10:26 am
From: Eric Sosman

On 3/11/2010 12:10 PM, Noob wrote:
> Hello everyone,
>
> I'm using a library which provides a void *user_data field
> inside the struct used everywhere within the library.
>
> I need to stuff a jmp_buf inside user_data.
>
> I suppose I can't write
>
> jmp_buf env;
> ctx->user_data = env;
>
> and then use ctx->user_data as setjmp's and longjmp's parameter?

Yes, you can. For historical reasons jmp_buf is an array
type, and you know The Rule about arrays: In all but a few
contexts, mentioning the name of an array is the same as writing
a pointer to the array's first element. So

ctx->user_data = env;

is the same as

ctx->user_data = &env[0];

> Instead, I'd have to write
>
> jmp_buf env;
> ctx->user_data = &env;

This would also work, but there's no pressing need to
write it this way.

> and when I need the jmp_buf, I have to write
> *(jmp_buf *)ctx->user_data
> or
> jmp_buf *envp = ctx->user_data;
> *envp

Since the only (useful) thing you can do with a pointer
to the first element of a jmp_buf is call longjmp() with it,
and since longjmp() is an ordinary function call, a void*
argument will automatically convert to the proper type as
part of the call.

The situation with setjmp() is less clear. Since setjmp()
is a macro rather than a function (although its expansion may
call one or more functions), it might do things with its jmp_buf
argument that an ordinary function could not do via a pointer.
As far as I can tell, calling setjmp() with a pointer to the
start of a jmp_buf is *not* guaranteed to work.

> Did I get it right?

Sort of, I guess.

> Is there different way to do this?

It's not clear what you mean by "this." You can certainly
call setjmp() on a jmp_buf object, pass around a void* pointer
to that object, and eventually call longjmp() on the pointer.

--
Eric Sosman
esosman@ieee-dot-org.invalid

== 3 of 3 ==
Date: Thurs, Mar 11 2010 10:45 am
From: Ben Bacarisse

Noob <root@127.0.0.1> writes:

> I'm using a library which provides a void *user_data field
> inside the struct used everywhere within the library.
>
> I need to stuff a jmp_buf inside user_data.
>
> I suppose I can't write
>
> jmp_buf env;
> ctx->user_data = env;
>
> and then use ctx->user_data as setjmp's and longjmp's parameter?

In fact you can do this (but see below for some problems) because a
jmp_buf is an array type.

> Instead, I'd have to write
>
> jmp_buf env;
> ctx->user_data = &env;

This is pretty much the same as the above. The main trouble is going
to be the lifetime of 'env'. All will be well provided 'env' still
exists when the point to it is used, but if the function containing
'env' might return before the pointer is used, you'll have to use
malloc to allocate storage for the jmp_buf.

> and when I need the jmp_buf, I have to write
> *(jmp_buf *)ctx->user_data
> or
> jmp_buf *envp = ctx->user_data;
> *envp

You need to do this no matter how you get the pointer into user_data
because once it is a void * you can't do much with it.

Because jmp_buf is an array type, you might think that you can avoid
the cast and the dereference because the result of

*(jmp_buf *)ctx->user_data

is an array lvalue and thus gets converted to a pointer anyway.
Surely (you might think) the void * expression ctx->user_data is just
as good?

The problem with that is that setjmp may be implemented as a macro, so
you can't be sure that it does not use some construct (sizeof and &
being the most obvious) that distinguishes between an array and a
pointer to its first element.

longjmp, however, is a function so I think it is safe to use

longjmp(ctx->user_data, value);

> Did I get it right?

Pretty much so, yes. I wonder if my answer fairs as well :-)

<snip>
--
Ben.

==============================================================================
TOPIC: Depth of Binary Tree
http://groups.google.com/group/comp.lang.c/t/8246aca121941e23?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Mar 11 2010 9:14 am
From: RAKHE

I have come accross with the code for finding Depth of tree, i am
not
getting this, please anyone throw a light on this ....

http://www.math.bas.bg/~nkirov/2010/NETB201/slides/ch06/pic3.jpg

please explain in code level rather than theoratical level.

int depth(treenode *p)
{
if(p==NULL)return(0);
if(p->left){h1=depth(p->left);}
if(p=>right){h2=depth(p->right);}
return(max(h1,h2)+1);

}

== 2 of 4 ==
Date: Thurs, Mar 11 2010 9:32 am
From: Dr Malcolm McLean

On 11 Mar, 17:14, RAKHE <t.sathyanaraya...@gmail.com> wrote:
> I have come accross with the code for finding Depth of tree, i am
> not
> int depth(treenode *p)
> {
> if(p==NULL)return(0);
> if(p->left){h1=depth(p->left);}
> if(p=>right){h2=depth(p->right);}
> return(max(h1,h2)+1);
>
>
There's nothing much wrong with this.
h1 and h2 need to be declared and initialised to zero. max may not be
defined (this is a nuisance and one of the silly quirks of C, it's
easier all round to write the logic yourself).
There's a typo in p=> (should be p->). Ypu don't need to parenthesise
a return expression, though it doesn't do any harm except make the
code harder to read.

== 3 of 4 ==
Date: Thurs, Mar 11 2010 9:49 am
From: Lew Pitcher

On March 11, 2010 12:14, in comp.lang.c, t.sathyanarayanan@gmail.com wrote:

> I have come accross with the code for finding Depth of tree, i am
> not
> getting this, please anyone throw a light on this ....
>
> http://www.math.bas.bg/~nkirov/2010/NETB201/slides/ch06/pic3.jpg
>
>
> please explain in code level rather than theoratical level.
>
>
> int depth(treenode *p)
> {
> if(p==NULL)return(0);
> if(p->left){h1=depth(p->left);}
> if(p=>right){h2=depth(p->right);}
> return(max(h1,h2)+1);
> }

Your treenode consists of some data (not shown) and two pointers. The left
pointer points to the node that starts the left branch of the tree below
the current node, and the right pointer points to the node that starts the
right branch of the tree below the current node. Either (or both) of these
pointers may be NULL, signifying that there are no branch nodes in that
direction below the current node.

The depth() function works on these pointers. You give it a pointer to a
node, and it counts the depth of the tree pointed to by that pointer.

If the pointer you give depth() is NULL, then there is no treenode, and
therefore no subtree. The depth of this branch is zero.

OTOH, if you gave depth() a non-null pointer, then that pointer points to
one level of depth, and the node at that level may lead to other levels of
depth. The code measures the depth of each branch from the current node,
and finds out which branch is longer. It then adds 1 (for the current node)
to that count, and returns that value as the depth of the tree /from this
node down/.

Since the function is recursive, it uses itself to determine the depths of
each branch of the current node.

--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

== 4 of 4 ==
Date: Thurs, Mar 11 2010 10:17 am
From: Ben Bacarisse

RAKHE <t.sathyanarayanan@gmail.com> writes:

> I have come accross with the code for finding Depth of tree, i am
> not
> getting this, please anyone throw a light on this ....
>
> http://www.math.bas.bg/~nkirov/2010/NETB201/slides/ch06/pic3.jpg
>
> please explain in code level rather than theoratical level.
>
> int depth(treenode *p)
> {
> if(p==NULL)return(0);
> if(p->left){h1=depth(p->left);}
> if(p=>right){h2=depth(p->right);}
> return(max(h1,h2)+1);
> }

Other people have explained. All I'd say is that this seem overly
complex. depth is happy to be passed NULL so you can just write:

if (p)
return max(depth(p->left), depth(p->right)) + 1;
else return 0;

In fact, I'd consider:

return p ? max(depth(p->left), depth(p->right)) + 1 : 0;

--
Ben.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Thursday, March 11, 2010

comp.lang.c - 25 new messages in 6 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts