Boost process and C

[jacob navia]

Ben Pfaff a écrit :

No. I mean that some string operations can be expressed shorter
and with more clarity in Perl than in C. No new string library
will change this.

If you want to actually change the C language to improve its
string support, as you seem to want, that's completely separate.
But your changes to C won't affect my software for 10 years or
more, because that's at least how long it'll take for them to get
into the standard (assuming they ever do) and then make it into
a wide range of real-world implementations.

OK, that seems more balanced.

Thanks

 

[jacob navia]

Mark McIntyre a écrit :

More accurately
"C has no native string type, if you find you need to excessively
manipulate strings, perl may suit your needs better".

Of course, feel free to stick with your highly pejorative version.

But if you agree that C has a extremely weak string type Mark, why
wouldn't a revision of that part of the language be a good thing?

I wouldn't say that C "has no string type". Strings in C were a mere
afterthought and they are inefficient and very error prone. Granted.

But they do exist and they do get used, very often with catastrophic
results.

Why not change/improve this part of the language then?

jacob

 

[Herbert Rosenau]

You are saying you should throw out an entire language because you
don't like the way it handles strings?

No, but when a twit like jacob gets whining that the C standard has to
change to fullify his wishes then I send him to another language that
fullifys that.

Are you aware that many Pascal
implementations have strings limited to a length of 255 characters?

I know. But is uninteresting here.

There are somewhat easier, and less retarded solutions to this problem:

http://bstring.sf.net/

Does not matter. I've written such extension myself for a special use
while in the same program beside that was massive handling of standard
C strings.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Herbert Rosenau]

But if you agree that C has a extremely weak string type Mark, why
wouldn't a revision of that part of the language be a good thing?

The only who whines that C strings are weak is the twit who names
himself as jacob navia.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Keith Thompson]

OR even a change of use of this one

Yes, that could theoretically be done -- but I would oppose it.

I like having a group that discusses the C language as defined by the
ISO standard(s). Loosening the definition of what's topical here in
comp.lang.c would mean that there would no longer be any such group.
That would be a great loss, and I'm certain I'm not the only person
who feels that way.

comp.lang.c++ in effect tried a similar experiment some years ago. It
barely survived. As it drowned in a flood of discussions of
system-specific C++ programming, the regulars who wanted to talk about
the language itself drifted away.

 

[jacob navia]

Keith Thompson a écrit :

comp.lang.c++ in effect tried a similar experiment some years ago. It
barely survived. As it drowned in a flood of discussions of
system-specific C++ programming, the regulars who wanted to talk about
the language itself drifted away.

But that's the point Keith. We want to talk ABOUT THE LANGUAGE ITSELF.

Not just the narrow definition of "The language as it was in 1989" or
"The language as specified in the C standard", but including discussions
like this discussion, that is the first in many years that touches
topics that go beyond

"I wrote i++=i++ and doesn't work...."

What are those discussions "About C"???

I am long enough here to see that those are:

Homework assignments students that get their jobs done by an always
helpful hand from comp.lang.c (in many cases).

Trivia like:
i++ = i++;
Why is my gcc telling me
undefined reference to _cos?
etc
etc

Substantive discussions about software constructions, pro/cons of
specific ways of writing in C, or discussions about the language itself
and its direction, new proposals etc, are

"beyond the scope of this group".

Everything is frozen here, like in a museum.

jacob

 

[Ian Collins]

That's not overloading. In a real C compiler, those would be int_128t's,
a normal integer type, and the normal C arithmetic operations would
apply to them.

Also *= is a unary operator, so the syntax looks clumsy.

Learn to read.

Functions which take a reference can change _my_ object behind my back,
and the only way I'd know about it is if I dug up the prototype. You
cannot tell from a single call. With pointers, the difference is always
clear. To illustrate:

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

 

[jacob navia]

Ian Collins a écrit :

Also *= is a unary operator, so the syntax looks clumsy.

Multiplication needs TWO operators. In C++ you have the "implicit this".
In C you don't have any implicit arguments so you need a different
prototype.

 

[Ian Collins]

What has UNIX got to do with anything? The number of people who
mistakenly think they can post here with gcc or Visual C questions is
pretty staggering.




I don't get you train of thought -- these are newsgroups about
operating systems, not C.

Look at the names, they include 'programmer' or 'development', so they
are valid places to discuss the main programming language used in those
environments, C.

 

[jacob navia]

Ian Collins a écrit :

That's why we have const. If a function isn't going to change the value
passed in, it should reference (or pointer) to a const object. If the
parameter isn't const, assume the worst. No difference between pointers
and references in this case.

lcc-win32 will COPY the argument into the stack ALWAYS when the function
prototype specifies a structure passed by value.

typedef struct {int a; int b;} Struct;

Struct someGlobal;

void fn(Struct);

int main(void)
{
Struct &a = someGlobal;

fn(a);
...
}

The call to fn(a) will provoke a dereferencing of a, and a copy of the
result of that dereferencing into the stack.

This means that even if you do NOT have any "const" declaration the
prototype specifications are ALWAYS followed.

This makes for clearer software. Otherwise you can effectively never
know if a function will change its argument!

jacob

 

[jacob navia]

I said:

Multiplication needs TWO operators.

It should have been

Multiplication needs TWO operands.

Sorry for this stupid bug

 

[Ian Collins]

Ian Collins a écrit :

lcc-win32 will COPY the argument into the stack ALWAYS when the function
prototype specifies a structure passed by value.

typedef struct {int a; int b;} Struct;

Struct someGlobal;

void fn(Struct);

int main(void)
{
Struct &a = someGlobal;

fn(a);
...
}

The call to fn(a) will provoke a dereferencing of a, and a copy of the
result of that dereferencing into the stack.

This means that even if you do NOT have any "const" declaration the
prototype specifications are ALWAYS followed.

This makes for clearer software. Otherwise you can effectively never
know if a function will change its argument!

I'm not sure what you are saying, the above describes normal pass by
value in C, I was answering a question about pass by reference....

 

[Ian Collins]

Ian Collins a écrit :



Multiplication needs TWO operators. In C++ you have the "implicit this".
In C you don't have any implicit arguments so you need a different
prototype.

Very true, but how would you invoke the operator you prototype above?

 

[jacob navia]

Ian Collins a écrit :

I'm not sure what you are saying, the above describes normal pass by
value in C, I was answering a question about pass by reference....

Excuse me. I was just saying that passing a reference to a function that
accepts a structure VALUE does NOT force a pass by reference. To pass by
reference you have to write:

void fn(STRUCT &);

ONLY then, a pass by reference is done.

 

[jacob navia]

Ian Collins a écrit :

Very true, but how would you invoke the operator you prototype above?

Just
int128 a,b,c;
...
a *= b;

 

[Ian Collins]

Substantive discussions about software constructions, pro/cons of
specific ways of writing in C, or discussions about the language itself
and its direction, new proposals etc, are

"beyond the scope of this group".

Everything is frozen here, like in a museum.

There are similar issues on the C++ group, but the biggest difference is
there is always somewhere else for OT discussions to migrate to.

 

[Ian Collins]

Ian Collins a écrit :

Excuse me. I was just saying that passing a reference to a function that
accepts a structure VALUE does NOT force a pass by reference. To pass by
reference you have to write:

void fn(STRUCT &);

ONLY then, a pass by reference is done.

Ah, I see. That is how it should be.

 

[Keith Thompson]

Keith Thompson a écrit :

But that's the point Keith. We want to talk ABOUT THE LANGUAGE ITSELF.

If you just wanted to talk about the language itself, I wouldn't have
any problem.

The language itself doesn't have operator overloading, yet you insist
on talking at length about operator overloading.

 

[Ian Collins]

If you just wanted to talk about the language itself, I wouldn't have
any problem.

The language itself doesn't have operator overloading, yet you insist
on talking at length about operator overloading.

Keith,

Where would you draw the line on topicality?

My interpretation is

Off topic:

Platform specific issues.
Product specific issues.

On topic:

The current language and its use.
Potential improvements?

 

[Keith Thompson]

Keith,

Where would you draw the line on topicality?

My interpretation is

Off topic:

Platform specific issues.
Product specific issues.

On topic:

The current language and its use.
Potential improvements?

I would say that potential improvements *would be* topical here if it
weren't for the existence of comp.std.c.

Discussions of potential improvements are off-topic if they're a thin
disguise for advertisements for some specific compiler that happens to
implement them as an extension.