«

William Ahern <> writes:

> Ben Bacarisse <> wrote:
>> Bubba <> writes:
> <snip>
>> > temp=i->first_child;
>> > i->first_child->label=l;
>> > i->first_child->first_child=NULL;
>> > i->first_child->next_sib=temp;
>> > i->first_child->last_child=NULL;
>> > i->first_child->zadnji=0;
>> > }
>> > return i->first_child;
>> > }
>
>> The lack of spaces and the confusion caused by using tabs is making this
>> hard to read so I'll stop here.
>
> You mean confusion caused by *not* using tabs, or by software trying to
> convert perfectly fine tabs to spaces and--not surprisingly--fscking the
> indentation?

By "using" I meant "posting with". Tabs in a post are unlikely to look
the same as tabs in a code editor. I made the remark when I was looking
at some code that had tabs, though I see there are some lines that looks
odd and have no tabs (in the post).

> Tabs for indentation, spaces for alignment. Almost every editor gets this
> right by default. It's takes a concerted effort to screw it up. (I'm not
> laying blame on anyone in particular here. I'm presuming it's the OP's
> client software that is causing the problem.)

We are probably in agreement. I don't care what the editor uses for the
code, but once tabs get into a post, you've almost always lost.

--
Ben.

William Ahern <> writes:
> Ben Bacarisse <> wrote:
>> Bubba <> writes:
> <snip>
>> > temp=i->first_child;
>> > i->first_child->label=l;
>> > i->first_child->first_child=NULL;
>> > i->first_child->next_sib=temp;
>> > i->first_child->last_child=NULL;
>> > i->first_child->zadnji=0;
>> > }
>> > return i->first_child;
>> > }
>
>> The lack of spaces and the confusion caused by using tabs is making this
>> hard to read so I'll stop here.
>
> You mean confusion caused by *not* using tabs, or by software trying to
> convert perfectly fine tabs to spaces and--not surprisingly--fscking the
> indentation?

No, I'm fairly sure he means confusion caused by using tabs.

> Tabs for indentation, spaces for alignment. Almost every editor gets this
> right by default. It's takes a concerted effort to screw it up. (I'm not
> laying blame on anyone in particular here. I'm presuming it's the OP's
> client software that is causing the problem.)

I've worked on far too much code that has a random mixture of tabs
and spaces, with a tab representing a variable number of columns,
depending on who modified a particular line of code most recently.
My personal solution to the problem is to use spaces exclusively
for indentation -- and that was part of the coding standard at my
most recent job. (If I worked in environment that required the
exclusive use of tabs for indentation, of course I'd use tabs.)

I'm not going to argue that you should follow my convention, but
you should be aware that there are perfectly legitimate reasons
for using spaces, even if you don't agree with them; people who use
spaces rather than tabs aren't necessarily doing so out of ignorance.

And tabs can cause serious formatting problems when posting to
Usenet, because there's news software that doesn't handle them
correctly.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Bubba <> writes:
> Keith Thompson's log on stardate 16 sij 2012
> I hoped for something like this in the first place, so thank you in
> advance!
>
>> Identifiers starting with underscores are reserved to the
>> implementation in most contexts. Identifiers starting with two
>> underscores are reserved in all contexts. You should never define
>> such identifiers yourself (unless you're writing code for a C
>> compiler or library implementation).
>
> What are the repercussions of choosing wrong number of underscores?

Undefined behavior.

If you're *lucky*, you'll happen to collide with an
implementation-defined identifier and your code will fail to compile.

If you're *unlucky*, your program works as you intended it to work, or
it will fail in subtle ways that are difficult to find.

The compiler and/or standard runtime library can do anything they like
with identifiers that start with "__", and nearly anything they like
with identifiers that start with a single underscore. If you define
such an identifier yourself, it may or may not conflict with a
system-defined identifier.

So don't do that.

[...]

>> And in fact I'd declare this as:
>> struct celltype *make_root(labeltype label, struct celltype **t);
>
> Could you please clarify the need for double pointer?

A "double pointer" could be either a pointer to a pointer, or a pointer
to type "double". It's better to refer to it as a pointer-to-pointer.

Why a pointer to a pointer? Don't ask me, it's your code; you declared
it with a pointer-to-pointer yourself. All I did was replace the
typedef (which hides the fact that the type is a pointer) with its full
definition.

But in general, if you want a function to modify something of type foo,
you need to pass it a foo*. In this case, "foo" happens to be a pointer
type itself.

[...]

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 1/16/2012 18:01, Ben Bacarisse wrote:
> Keith Thompson<kst-> writes:
> <snip>
>> A good idiom is:
>>
>> if ((*T = malloc(sizeof **T) != NULL) {
>
> There's a missing ')' of course:
>
> if ((*T = malloc(sizeof **T)) != NULL) {
>
> <snip>

And change the '!=' to '=='. - Shao

Shao Miller <> writes:
> On 1/16/2012 18:01, Ben Bacarisse wrote:
>> Keith Thompson<kst-> writes:
>> <snip>
>>> A good idiom is:
>>>
>>> if ((*T = malloc(sizeof **T) != NULL) {
>>
>> There's a missing ')' of course:
>>
>> if ((*T = malloc(sizeof **T)) != NULL) {
>>
>> <snip>
>
> And change the '!=' to '=='. - Shao

Quite right, thanks.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

(Richard Harter) writes:
> On Mon, 16 Jan 2012 16:35:48 -0800, Keith Thompson <kst->
> wrote:
[...]
> And if you have a friendly editor it will convert tabs to spaces and
> vice versa just as you desire.

But not very well if different past maintainers had different ideas of
where the tabstops should be. For example, one section of code might
assume 2-column tabstops, and another might assume 4-column or 8-column
tabstops.

Which is ok if tabs (and only tabs) are used exclusively for
indentation, but not if both sections have a mix of tabs and spaces.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Jan 16, 5:01*pm, Bubba <nickn...@banelli.biz.invalid> wrote:
> Greetings,
>
[snip]
>
> Now I need a sane way to input a tree from keyboard. What would be the
> easiest one?
>
> Thanks in advance!

The simplest is probably to leverage an existing XML parser and write
your own XML format to populate your own custom "DOM" structure. The
expat and libxml2 are fairly popular, and there are some varying
implementations of DOM floating around.

If you want to input a tree from the keyboard, you could type in the
tree data in XML format, feed it to one of the parsers, and use its
events to trigger using your interface to populate your tree. It'll
take some work, but learning how to use an XML parser can be quite
useful.

Best regards,
John D.

On 2012-01-17, Richard Harter <> wrote:
> And if you have a friendly editor it will convert tabs to spaces and
> vice versa just as you desire.

I use program that I call autotab. This is integrated into
Vim. When I open a file, autotab is called to analyze up to 5000
lines of text from the file and emit a configuration for Vim,
such as whether tabs are expanded with spaces (expandtab), the soft indentation
size (shiftwidth) and the hard tab size (tabstop).

The code is here:

http://www.kylheku.com/cgit/c-snippets/tree/autotab.c

This program is so rarely wrong that I've stopped fixing the situations when it
is wrong.

On 1/16/2012 10:36 PM, ImpalerCore wrote:
> On Jan 16, 5:01 pm, Bubba<nickn...@banelli.biz.invalid> wrote:
>> Greetings,
>>
> [snip]
>>
>> Now I need a sane way to input a tree from keyboard. What would be the
>> easiest one?
>>
>> Thanks in advance!
>
> The simplest is probably to leverage an existing XML parser and write
> your own XML format to populate your own custom "DOM" structure. The
> expat and libxml2 are fairly popular, and there are some varying
> implementations of DOM floating around.

Angels and ministers of grace defend us! The O.P. is trying
to build a tree in which each node carries a payload of

ONE

LONESOME

`CHAR'

VALUE

.... and you want to inflict XML on him?!?!

Whereabouts do you live, ImpalerCore? I want to be about five
hundred miles away, and upwind, when you find a cockroach in your
cupboard and exterminate it with nuclear armaments.

--
Eric Sosman
d

(Richard Harter) writes:
> On Mon, 16 Jan 2012 19:16:10 -0800, Keith Thompson <kst->
> wrote:
>> (Richard Harter) writes:
>>> On Mon, 16 Jan 2012 16:35:48 -0800, Keith Thompson <kst->
>>> wrote:
>>[...]
>>> And if you have a friendly editor it will convert tabs to spaces and
>>> vice versa just as you desire.
>>
>>But not very well if different past maintainers had different ideas of
>>where the tabstops should be. For example, one section of code might
>>assume 2-column tabstops, and another might assume 4-column or 8-column
>>tabstops.
>
> Within a single file?

Yes.

> And your editor displays them all correctly?

No.

That was the problem.

> How remarkable.

>>Which is ok if tabs (and only tabs) are used exclusively for
>>indentation, but not if both sections have a mix of tabs and spaces.
>
> I don't you caught what I had in mind. If your editor has the option
> of automatically converting tabs into spaces you can use tabs with the
> settings you prefer, get the indentation that floats your boat, and
> still have a tab free file. I keep all of my code in tab free format
> (except for makefiles - boo, hiss). If your editor can go the other
> way, i.e., convert those pesky spaces into tabs, you can deal with
> files that historically have tabs that you want to keep that way.
> Just convert tabs to spaces, edit, and convert back from spaces to
> tabs.

That could work if everyone who modifies the file *either* uses only
tabs for indentation *or* uses only spaces (with a consistent number
of columns per level) for indentation. My recent experience does
not indicate that maintaining that kind of consistency is practical.
Perhaps in some organizations it would be.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"