A C Adventure: your comments are welcome

[Flash Gordon]

OK, Flash, trees use links. But they are not "linked lists". Singly

<snip>

You still fail to understand. I was telling you were to find information
on what you needed, not what data structure to use. The part you had
problems with it common to all, so will always be dealt with in the
tutorial for the easiest structure (ie. lists), because the others will
assume you know already how to code a list and therefor how to code
pointers to a node type within a node.

I've used all of the structures you talked about and more, and
understand them and their differences.

 

[bartc]

spinoza1111wrote:

"spinoza1111" <[email protected]> wrote in message

OK, so here's how I represent strings:

struct TYPstring
{
long intSegmentLength;
char * strSegment;
void * usrLeftSegment;
void * usrRightSegment;
}

If you want string handling to become a total nightmare, then that
is a good start.

I'd remark that you're a coward. You smirk that this is a nightmare,
but you're afraid of being shot down in turn, and so, like a Serbian
sniper killing women and children from hiding, you make smart
remarks.

The struct does need one extra element, the startindex of the

I don't know what sort of super-complicated strings you're trying to
implement. How would your string type deal with something
straightforward like:
char
*daynames[7]={"Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","­Saturday"};
printf("Random day: %s\n",daynames[rand()%7]);

Gee, I'm not worthy. I'm scum. Didjoo write that?
No.


So exactly what is it you propose? That all strings be handled by
arrays of 7 character strings?

Of course, for the above, I'd use an array of seven pointers to the
string struct.

Something like:

struct TYPstring
daynames[]={{6,0,"Sunday",NULL,NULL},{6,0,"Monday",NULL,NULL.... ?

Those wouldn't be pointers of course, and each TYPstring is only using a
single flat representation of it's entire string. And there is no sharing of
the "day" suffix of each string.

Or perhaps you propose something more like:

struct TYPstring *daynames[7];

daynames[0]=createTYPstring("Sunday");
etc.

But, guess what, all these rely on C's string literals which are all
nul-terminated, flat, uncounted strings.

 

[Guest]

| struct TYPstring
| {
| long intSegmentLength;
| char * strSegment;
| void * usrLeftSegment;
| void * usrRightSegment;
| };

Why are you not type checking? Following your style (not my style), I
would do:

struct TYPstring
{
long intSegmentLength;
char * strSegment;
struct TYPstring * usrLeftSegment;
struct TYPstring * usrRightSegment;
};


Note that C allows referencing a struct even before it is defined. This
can be done in the first pass since the pointer reference does not need
to know the definition until dereferenced.

struct foo {
struct bar * ref;
};
struct bar {
struct foo * ref;
};

If your compiler can't do it, get a better compiler.

 

[Guest]

| spinoza1111 wrote:
|>>
|>> |
|>>> OK, so here's how I represent strings:
|>>
|>>> struct TYPstring
|>>> {
|>>> long intSegmentLength;
|>>> char * strSegment;
|>>> void * usrLeftSegment;
|>>> void * usrRightSegment;
|>>> }
|>>
|>> If you want string handling to become a total nightmare, then that
|>> is a good start.
|>
|> I'd remark that you're a coward. You smirk that this is a nightmare,
|> but you're afraid of being shot down in turn, and so, like a Serbian
|> sniper killing women and children from hiding, you make smart remarks.
|>
|> The struct does need one extra element, the startindex of the segment
|> in the string. This is redundant but it provides a rationale for an
|> error check in the stringInspector() function to come.
|>
|> struct TYPstring
|> {
|> int intSegmentLength;
|> char * strSegment;
|> int intSegmentStartIndex;
|> void * usrLeftSegment;
|> void * usrRightSegment;
|> };
|>
|> This way, we need not search half the string tree preorder to find a
|> specific indexed location.
|
| I don't know what sort of super-complicated strings you're trying to
| implement. How would your string type deal with something straightforward
| like:
|
| #include <stdio.h>
| #include <stdlib.h>
|
| int main(void)
| {
| char
| *daynames[7]={"Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"};
| printf("Random day: %s\n",daynames[rand()%7]);
| }

Are you referring to being able to initialize an array of strings, or to
being able to randomly index an array of strings. The later can be done
by having an array of struct TYPstring, or an array of pointers to it.

I like simplicity. I don't see a need for your left/right thing unless
you want to do random indexing within the string equivalent to:

int main(void)
{
char
days[22]="SunMonTueWedThuFriSat";
printf("Random day: %3.3s\n",days[rand()%7]);
}

And then to do so within the context of your struct, the division left and
right will have to have known offsets, e.g. the intSegmentStartIndex above,
or a fixed definition of some sort.

 

[spinoza1111]

| struct TYPstring
| {
|    long intSegmentLength;
|    char * strSegment;
|    void * usrLeftSegment;
|    void * usrRightSegment;
| };

Why are you not type checking?  Following your style (not my style), I
would do:

struct TYPstring
{
   long intSegmentLength;
   char * strSegment;
   struct TYPstring * usrLeftSegment;
   struct TYPstring * usrRightSegment;

};

Note that C allows referencing a struct even before it is defined.  This
can be done in the first pass since the pointer reference does not need
to know the definition until dereferenced.

struct foo {
    struct bar * ref;};

struct bar {
    struct foo * ref;

};

If your compiler can't do it, get a better compiler.

--
---------------------------------------------------------------------------­--
| Phil Howard KA9WGN       |http://linuxhomepage.com/     http://ham.org/|
| (first name) at ipal.net |http://phil.ipal.org/ http://ka9wgn.ham.org/|
---------------------------------------------------------------------------­--

Fixed that when I remembered, from 20 years ago, the ugly fact that
struct names have to be prefixed by the keyword struct. Now working on
a version with no void ptrs.

 

[spinoza1111]

|>>
|>>|
|>>> OK, so here's how I represent strings:
|>>
|>>> struct TYPstring
|>>> {
|>>> long intSegmentLength;
|>>> char * strSegment;
|>>> void * usrLeftSegment;
|>>> void * usrRightSegment;
|>>> }
|>>
|>> If you want string handling to become a total nightmare, then that
|>> is a good start.
|>
|> I'd remark that you're a coward. You smirk that this is a nightmare,
|> but you're afraid of being shot down in turn, and so, like a Serbian
|> sniper killing women and children from hiding, you make smart remarks.
|>
|> The struct does need one extra element, the startindex of the segment
|> in the string. This is redundant but it provides a rationale for an
|> error check in the stringInspector() function to come.
|>
|> struct TYPstring
|> {
|>     int intSegmentLength;
|>     char * strSegment;
|>     int intSegmentStartIndex;
|>     void * usrLeftSegment;
|>     void * usrRightSegment;
|> };
|>
|> This way, we need not search half the string tree preorder to find a
|> specific indexed location.
|
| I don't know what sort of super-complicated strings you're trying to
| implement. How would your string type deal with something straightforward
| like:
|
| #include <stdio.h>
| #include <stdlib.h>
|
| int main(void)
| {
| char
| *daynames[7]={"Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","­Saturday"};
| printf("Random day: %s\n",daynames[rand()%7]);
| }

Are you referring to being able to initialize an array of strings, or to
being able to randomly index an array of strings.  The later can be done
by having an array of struct TYPstring, or an array of pointers to it.

I like simplicity.  I don't see a need for your left/right thing unless

The tree when balanced gives log time access to string characters. The
array of strings gives n/2 time access unless you keep each entry
fixed in length.

An array that isn't even a linked list would have to be recopied when
inserts or deletes occur.

you want to do random indexing within the string equivalent to:

int main(void)
{
char
days[22]="SunMonTueWedThuFriSat";
printf("Random day: %3.3s\n",days[rand()%7]);

}

And then to do so within the context of your struct, the division left and
right will have to have known offsets, e.g. the intSegmentStartIndex above,
or a fixed definition of some sort.

--
---------------------------------------------------------------------------­--
| Phil Howard KA9WGN       |http://linuxhomepage.com/     http://ham.org/|
| (first name) at ipal.net |http://phil.ipal.org/ http://ka9wgn.ham.org/|
---------------------------------------------------------------------------­--

 

[spinoza1111]

spinoza1111said:

I generally don't like to read other people's code since once I'm up
to speed in a programming language (a process, by the way, that
takes good programmers hours and not days),

You've had many years. Even if we just count this time around, you've
had weeks. You are clearly not up to speed. Therefore, either[1] your
claim (above) is wrong or you are not a good programmer. Your call.

Dry up, Richard. People would not accept your pompous bullying in a
social environment.

[1] non-exclusive "either" - at least one must apply, but there's no
logical reason why both shouldn't.

their style generally
offends me. I was an adopter of "literate programming" before Knuth
and even before Brian Kernighan's "The Elements of Programming
Style", using systematic naming conventions and extensive line and
blocked comments in IBM 1401 SPS, even though this language only
provided 15 character line comments and six character names. I also
modified the assembler (in machine language) to skip line comments.

Therefore, I am offended by short identifiers and half-literate
comments.

Please don't include your own comment //
80

in this, as it is not half-literate, but illiterate, since it breaks a
syntax rule. It would be interesting to see you blame this one on C,
since IIRC it was first introduced in BCPL and is widely used in C++
and, I believe, C#. Don't let that stop you trying, though.

Navia seems to have implemented them. You could not have done so. Does
this offend you?

I had to remove the comments from which your code was free, since I
don't have a conforming C99 implementation.

Forest and trees, Robin Hood.

I removed the comments, which my compiler doesn't support. Any sane

There you go again. If you're sane, I'm glad I'm crazy.

person, whether or not they agree with my use of a non-C99-conforming
compiler (or yours for that matter, since lcc-win32 does not conform
to C99 either), would agree that removing the comments does not
change the behaviour of the program except in pathological cases

? Such as tags and metastuff?

which don't apply here. I made one other C99-related change, which
was to move a declaration from in-code to pre-code. This necessitated
changing an initialisation to an assignment, but no behaviour was
harmed in the making of this re-mix.

Having made those changes, I was able to give the compiler a fair
crack at your code.

Before I give you the results, I should tell you that no
implementation is required to provide a malloc.h header, and if they
do the contents thereof are not specified.

Since you use C99 features, may we presume that you intend your code
to be C99-conforming? Because it isn't. It requires a diagnostic
message for your implicit definition of a min() function - for which,
by the way, you do not provide a definition. Since lcc-win32, if it
were C99-conforming, *must* diagnose this problem, we conclude that
either you invoked it incorrectly or it isn't C99-conforming (and
therefore has no correct way to be invoked as far as the Standard is
concerned).

I got a number of other warnings which probably won't interest you,
but the linker error was a showstopper:

undefined reference to `min'

For you, perhaps. A competent programmer would have added a min()
function. You know, it's real easy to do this.

If you use non-standard features, you're writing in an extension of C
rather than in C itself.

God, you must be a load of laughs on the job. Remind me never to work
with for or over you.

It shouldn't compile (under either C90 or C99, for different reasons),
and it doesn't link. I could fix that pretty easily, but it's your
problem, not mine.

OK. People like Ben have all the fun here, and not you, because they
are real programmers who aren't alert for the signs of an incompetence
which they feel is theirs. And I shall continue to use Navia's
compiler just to annoy you.

 

[bartc]

I don't know what sort of super-complicated strings you're trying to
implement. How would your string type deal with something
straightforward like:
char
*daynames[7]={"Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","­Saturday"};
printf("Random day: %s\n",daynames[rand()%7]);

Are you referring to being able to initialize an array of strings,
or to
being able to randomly index an array of strings. The later can be
done
by having an array of struct TYPstring, or an array of pointers to
it.

I like simplicity. I don't see a need for your left/right thing
unless

The tree when balanced gives log time access to string characters. The
array of strings gives n/2 time access unless you keep each entry
fixed in length.

An array that isn't even a linked list would have to be recopied when
inserts or deletes occur.

This is all very admirable, and might be useful in the context of using C
for specific applications or helping to implement such strings as built-in
types of a higher level language.

But as a replacement for basic C strings? That would be equivalent to
getting rid of all C's int types and replacing them with a BigInt
implementation (perhaps one structured as a tree so that common sequences of
digits can be shared!)

That's not going to happen with C, it is a /low-level/ language.

 

[spinoza1111]

spinoza1111wrote:

On Sat, 15 Aug 2009 12:10:52 GMT bartc (e-mail address removed)
I don't know what sort of super-complicated strings you're trying to
implement. How would your string type deal with something
straightforward like:
char
*daynames[7]={"Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","­­Saturday"};
printf("Random day: %s\n",daynames[rand()%7]);
Are you referring to being able to initialize an array of strings,
or to
being able to randomly index an array of strings. The later can be
done
by having an array of struct TYPstring, or an array of pointers to
it.
I like simplicity. I don't see a need for your left/right thing
unless

The tree when balanced gives log time access to string characters. The
array of strings gives n/2 time access unless you keep each entry
fixed in length.

An array that isn't even a linked list would have to be recopied when
inserts or deletes occur.

This is all very admirable, and might be useful in the context of using C
for specific applications or helping to implement such strings as built-in
types of a higher level language.

But as a replacement for basic C strings? That would be equivalent to
getting rid of all C's int types and replacing them with a BigInt
implementation (perhaps one structured as a tree so that common sequences of
digits can be shared!)

Once you have a BigString class, albeit written in The Infantile
Disorder (C), you can "inherit" this class to create a BigNumber
class. Remember to implement mantissas, exponents, and complex
numbers, and all of a sudden you get...well, Mathematica.

I am coding and testing a fully commented version of the big string
handler. In some cases (length > approx 2^64) the length would be
unknown unless you had bignumber. The testing version will allow me to
set the max known length to a small value so I can experiment with
"strings of unknown length".

That's not going to happen with C, it is a /low-level/ language.

Just like we ain't gone get no health insurance?

 

[spinoza1111]

| struct TYPstring
| {
|    long intSegmentLength;
|    char * strSegment;
|    void * usrLeftSegment;
|    void * usrRightSegment;
| };

Why are you not type checking?  Following your style (not my style), I
would do:

struct TYPstring
{
   long intSegmentLength;
   char * strSegment;
   struct TYPstring * usrLeftSegment;
   struct TYPstring * usrRightSegment;

};

Note that C allows referencing a struct even before it is defined.  This
can be done in the first pass since the pointer reference does not need
to know the definition until dereferenced.

struct foo {
    struct bar * ref;};

struct bar {
    struct foo * ref;

};

If your compiler can't do it, get a better compiler.

Thanks for proving, once and for all, that C IS NOT PORTABLE.

You "C Experts" are a RIOT! You remind me (with all due respect to
Muslims) of Islamic clerics who will give you a "fatwa", or opinion
about anything you like, with a variety of answers.

For example, where I work I've spotted Muslim women in full covering,
with only the eyes exposed, in 35 degree centigrade (90 farenheit)
heat: but their husbands wear tank top and shorts even though the
Qu'ran clearly states that MEN must be covered by loose clothing from
shoulder to knee. Clearly, some Muslim cleric told the bum what he
wanted to hear: that his wife could suffer while he is cool and
comfortable.

Likewise, you treat your interpretations as holy writ. We don't even
know, do we, oh *imams* of C, whether line comments may be used (cf
Heathfield's rant).

This is what my fat pal Adorno termed the reversion of enlightenment
into barbarism.

This search for Ayatollahs like Richard Heathfield, and this
persecution of dissidents and writers like Navia and Schildt, means
that essentially the same social dynamics are operant in Muslim
fundamentalism (and Jewish fundamentalism, and Christian fundamentals)
as are operant in technology.

 

[Ben Bacarisse]

The questionmark colon statement from hell is the most important
statement. These Godzilla statements to me are elegant but can be hard
to debug.

It seems inappropriate to comment on the code in details since it has
obviously not had the benefit of a single test run, so I'll just say
that the ?: part also has comma operators in it that turn into
something else altogether.

<snip>

 

[spinoza1111]

spinoza1111said:









No, if your compiler can't do it, it isn't a C compiler. You will find
it impossible to locate a conforming C implementation that cannot
correctly parse the above structure definitions.



They are a common extension to C90, and codified in C99. You missed my
point about single-line comments, however; *your* "single-line
comment" straddled two lines, and thus introduced a syntax error into
the code.

No, it wrapped on your screen. I'm surprised (well, not really) that
you confused this with an actual newline. I suppose if I were you, I
would make your oversight a basis for a global attack on your
competence, but I am not thee: lucky me.

The comment was there because I was using Notepad to edit, and
Jacques' compiler was giving me line numbers, so I wanted to remember
a line number.

If you seek to find fault with others at all times, you create long
chains of charge and counterclaim, and you're the one responsible for
the garbage in this newsgroup because your campaigns create
confusion.

 

[spinoza1111]

spinoza1111said:

spinoza1111said:
<nonsense snipped>
I generally don't like to read other people's code since once I'm
up to speed in a programming language (a process, by the way,
that takes good programmers hours and not days),
You've had many years. Even if we just count this time around,
you've had weeks. You are clearly not up to speed. Therefore,
either[1] your claim (above) is wrong or you are not a good
programmer. Your call.

Dry up, Richard. People would not accept your pompous bullying in a
social environment.

[1] non-exclusive "either" - at least one must apply, but there's
[no
logical reason why both shouldn't.
their style generally
offends me. I was an adopter of "literate programming" before
Knuth and even before Brian Kernighan's "The Elements of
Programming Style", using systematic naming conventions and
extensive line and blocked comments in IBM 1401 SPS, even though
this language only provided 15 character line comments and six
character names. I also modified the assembler (in machine
language) to skip line comments.
Therefore, I am offended by short identifiers and half-literate
comments.
Please don't include your own comment //
80
in this, as it is not half-literate, but illiterate, since it
breaks a syntax rule. It would be interesting to see you blame this
one on C, since IIRC it was first introduced in BCPL and is widely
used in C++ and, I believe, C#. Don't let that stop you trying,
though.

Navia seems to have implemented them. You could not have done so.
Does this offend you?

You have, as ever, missed my point. //80 is a valid comment in C99,
but //
80

is not - and that's what you posted. The original text that you posted
contained a newline between the // and the 80, and that's a syntax
error even in C99. If lcc-win32 supports this (which I doubt very
much), it's broken.

Here, you're lying. Navia's compiler would have flagged "80" had this
been so. Whatever claptrap you are using in your Northumberland lair
inserted a newline, and you're either too dumb or too malicious to
realize or to admit that this was the problem.

So here we go again, with another evil campaign that starts with you,
and ruins reputations, and in which people man enough to defend
themselves are blamed for fighting back...like the worst sort of
American politics.

The comment wrapped. You're claiming that I would try to compile "80"
as a C statement, and this is absurd. You're implying that Navia lets
comments continue until God knows when, and this is absurd.

Asshole.

? Such as tags and metastuff?

No, I meant pathological cases such as a = b//* comment */ c
            ;

where the meaning of the code depends on whether the compiler
recognises BCPL-style comments.

For you, perhaps. A competent programmer would have added a min()
function. You know, it's real easy to do this.

I'm well aware of that. You made the claim that the implementation
generated no diagnostic messages. If you would like to modify the
claim to something like "this compiles and links okay provided you
prove yourself competent by fixing all my bugs", that's fine, but
then implementing a string library becomes as simple as this:

hgskjhfdlkf; /* EGN string library - fix all bugs before using */

[...] And I shall continue to use
Navia's compiler just to annoy you.

I don't care what compiler you use. I don't care what compiler
/anyone/ uses. That's the advantage of standardisation. If the
implementation conforms, it doesn't matter which one it is. And if it
doesn't, implementation-specific newsgroups are a better forum for
discussing it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
This line unintentionally left unblank- Hide quoted text -

- Show quoted text -

 

[spinoza1111]

It seems inappropriate to comment on the code in details since it has
obviously not had the benefit of a single test run, so I'll just say
that the ?: part also has comma operators in it that turn into
something else altogether.

I'll check them out. I am adding comments and refining the code before
I test it. But the "comma operators" are supposed to separate
parameters. I know that commas are also an operator, but I don't
remember how or whether C handles this gotcha.

 

[Tom St Denis]

Once you have a BigString class, albeit written in The Infantile
Disorder (C), you can "inherit" this class to create a BigNumber
class. Remember to implement mantissas, exponents, and complex
numbers, and all of a sudden you get...well, Mathematica.

As someone who works with large numbers for a living [among other
things] I really really really want to see what your bigInteger code
looks like...

I am coding and testing a fully commented version of the big string
handler. In some cases (length > approx 2^64) the length would be
unknown unless you had bignumber. The testing version will allow me to
set the max known length to a small value so I can experiment with
"strings of unknown length".

If you have strings > 2^64 bytes I want to see your storage array.
You realize that's 16.7 million terabytes right?

Tom

 

[Phil Carmody]

spinoza1111 said:

No, if your compiler can't do it, it isn't a C compiler. You will find
it impossible to locate a conforming C implementation that cannot
correctly parse the above structure definitions.

Can you please re-insert a "your really know bugger-all about C" line?
There's if you're going to feed him, at least feed him some bile.

Phil

 

[Phil Carmody]

spinoza1111 said:


Would someone else please confirm that I'm telling the truth about a
newline in the OP's so-called "single-line comment"? Message ID is:
<[email protected]>

As rendered by googlegroups itself:
"""
ptrSourceChars,
uintStartIndex
+
(uintSegments > 1 ? SEGMENT_MAX_LENGTH : 0), //
80
uintSegments > 1
?
min(uintLength - SEGMENT_MAX_LENGTH, uintLength)
:
uintLength,
"""

Clear as the nose on your face.

Now please killfile the troll. You don't need to protect anyone from
his idiocy, as he's already demonstrated it so clearly.

Phil

 

[luserXtrog]

Would someone else please confirm that I'm telling the truth about a
newline in the OP's so-called "single-line comment"? Message ID is:
<[email protected]>

That's how it looks from the midwest.

No, I'm claiming that you posted 80 as a C statement. In other words,
it appeared in code for which you invited comments.

Could it be that lcc-win is allowing statements without a semicolon?

No, *you're* implying that. You imply it by posting code that you
claim to have compiled using lcc-win32, without its issuing any
diagnostic messages.

[snippity]

 

[luserXtrog]

Phil Carmody said:



There's no point. He wouldn't believe me, and everyone else already
knows.

Yes, but the come-uppance! No tragedy without pathos.
Blood!

 

[Nick Keighley]

If you have strings > 2^64 bytes I want to see your storage array.
You realize that's 16.7 million terabytes right?

thats about enough memory for everyone on earth to have a reasonable
laptop