Porting C software

[Jean-Pierre Mestre]

Good evening,

I have a C software for Windows that I need to port to Redhat Unix. At
the moment it works completely fine with the Windows FLOSS compiler
lccwin32. I try gcc but now it doesn't work :(

There seems to be two serious problems, one operator overloading and the
other the safe String type. Is there a compiler for Unix with these
advanced features, or what's the best way to port them across?

Thanks to all!
J-P.

[jacob navia]

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>Richard Bos wrote:

>>jacob navia <ja***@jacob.remcomp.frwrote:

Philip Potter wrote:
jacob navia wrote:
>Most of the lcc-win32 extensions are very easily ported to C++
Why not make it a C++ compiler then? Making a compiler for a language
that is neither C nor C++ but somewhere in between seems like a silly idea.
My objective is to improve the C language retaining its simplicity.
Since you have already introduced a secondary string type and a large
over-complication in the operator system, I'd say that, whatever anyone
may think about your first aim, you have already failed the second.

1) The string type uses operator overloading, and it is a demonstration
of what can be done just with operator overloading and generic
functions.

So... yet more needless complication.

Unable to put any arguments, you just repeat yourself.

I said that it is needed because you can't create new types of numbers
in current C. See the other posts to see my arguments.

Question then:

How do you create and work with other types of numbers in C?
(extra precision, bignums, ratios, decimal representation, fixed point,
etc)

>

>2) "Over complication of the operator system" is just an empty sentence
unless you fill it with some meaning.

No, if you don't mangle the grammar by removing the hyphen, it means
exactly what it says. Operator overloading makes the operator system
more complicated than it needs or should be. Hence, over-complication of
the operator system. That, in my book, is not simple.

Richard

What is "more complicated" ?

Applications that do not use this feature are the same, and not
any more complicated.

Applications that DO use this feature overload the operators that they
wish to overload. The operator system remains the same. There are no new
complications, but the language is simplified, making possible to
use new kinds of numbers in C without any problems.

[Flash Gordon]

jacob navia wrote, On 29/08/07 16:22:

Richard Bos wrote:

>jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Bos wrote:

<snip operator overloading discussion>

>>2) "Over complication of the operator system" is just an empty sentence
unless you fill it with some meaning.

No, if you don't mangle the grammar by removing the hyphen, it means
exactly what it says. Operator overloading makes the operator system
more complicated than it needs or should be. Hence, over-complication of
the operator system. That, in my book, is not simple.

Richard

What is "more complicated" ?

Applications that do not use this feature are the same, and not
any more complicated.

Applications that DO use this feature overload the operators that they
wish to overload. The operator system remains the same. There are no new
complications, but the language is simplified, making possible to
use new kinds of numbers in C without any problems.

With you language, even if the program does not use operator overloading
you have to check the rest of the source file and all the headers it
includes to be sure that the + was actually arithmetic addition rather
than, for example, string concatenation or a set union operator (both of
which have been meanings of + in some situations). In C one knows that
the + is arithmetic addition, you just don't know the arithmetic types
involved. That is one reason why a number of people consider operator
overloading to be a complication.
--
Flash Gordon

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]
[operator overloading]

I said that it is needed because you can't create new types of numbers
in current C. See the other posts to see my arguments.

Don't overstate your case. Operator overloading makes new numeric
types more convenient. There is nothing you can do with operator
overloading that you can't do without it. The question is whether the
convenience is worth the complication.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Hills]

In article <fa**********@aioe.org>, santosh <sa*********@gmail.com>
writes

>cr88192 wrote:

>>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:QJ******************************@bt.com...

>>cr88192 said:
"Richard Heathfield" wrote...
Jean-Pierre Mestre said:
>
>>
>Is there a description anywhere of a "common subset" of C recognized
>by all compilers?
>
[Summary of my reply: "C90"]

yes.

C90 is good, yes...

C99 contains a few features that look particularly problematic
(dynamic arrays and so on...).

still, should work pretty good as a reference for writing portable
code

No, it doesn't work pretty good for that. It might do one day, but it
doesn't yet. And the OP asked for a description of C that is recognised
by all compilers. C99 doesn't come anywhere near achieving that.

yes, well then one has to ask, where to find the C90 spec?...
I failed before I think, so I use the C99 spec.

<http://flash-gordon.me.uk/ansi.c.txt>

Isn't that a breach of copyright?
I.e. Illegal?

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

In article <fa**********@aioe.org>, santosh <sa*********@gmail.com>
writes

<snip>

>><http://flash-gordon.me.uk/ansi.c.txt>

Isn't that a breach of copyright?
I.e. Illegal?

Is it illegal to make copies of public drafts of proposed ANSI
standards? I suspect that it is probably perfectly legal under US law
(which would be the applicable jurisdiction here, I think), but of
course I could be wrong.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Flash Gordon]

Richard Heathfield wrote, On 29/08/07 20:40:

Chris Hills said:

>In article <fa**********@aioe.org>, santosh <sa*********@gmail.com>
writes

<snip>

>><http://flash-gordon.me.uk/ansi.c.txt>

Isn't that a breach of copyright?
I.e. Illegal?

Is it illegal to make copies of public drafts of proposed ANSI
standards?

I think so.

I suspect that it is probably perfectly legal under US law
(which would be the applicable jurisdiction here, I think), but of
course I could be wrong.

Well, Dan Pop made a copy, and that would be covered by US law, but as I
am in the UK as is my server it gets a bit more complex. Of course, the
way the UK government is going the US would not have much difficulty
extraditing me.
--
Flash Gordon

[CBFalconer]

Flash Gordon wrote:

Keith Thompson wrote,

.... snip ...

>>
ansi.c.txt is not the actual C89 or C90 standard; it's a pre-standard
draft from 1988, which I believe was made publicly available.

This is what I believe based on what I remember of Dan Pop publicising
it when he hosted it.

If you got it from Dan (as I did) there is a section missing
somewhere. I don't remember exactly where.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Fr************@googlemail.com said:

<snip>

What ever happened to this famous Dan Pop?

Presumably, he popped. Knowing Dan, it was what he would have wanted.

For those who weren't around clc at the time: Dan Pop was strident,
irascible, arrogant, insulting, infuriating, and right. Many people
found the combination difficult to handle.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Bos]

Flash Gordon <sp**@flash-gordon.me.ukwrote:

Richard Heathfield wrote, On 29/08/07 20:40:

Is it illegal to make copies of public drafts of proposed ANSI
standards?

I think so.

I suspect that it is probably perfectly legal under US law
(which would be the applicable jurisdiction here, I think), but of
course I could be wrong.

Well, Dan Pop made a copy, and that would be covered by US law,

No, I don't think it would. Dan is East-European (Romanian, IIRC), and
last thing I remember he worked at CERN.

Richard

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>This makes possible:

int fn(void)
{
OtherNumber f = 56;

But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Wow.

So

const OtherNumber array[] {1,2,3};

isn't an initialisation?

--
Ian Collins.

[Richard]

Ian Collins <ia******@hotmail.comwrites:

jacob navia wrote:

>Ian Collins wrote:

>>jacob navia wrote:
This makes possible:

int fn(void)
{
OtherNumber f = 56;

But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Wow.

So

const OtherNumber array[] {1,2,3};

isn't an initialisation?

In fairness, he didn't say it isn't. He just says, and I can understand
why, that he doesn't bother to distinguish since it has little if any
effect in the understanding of how the program behaves. In this case it
doesn't kill the system to consider this as a one off assignment. I can't see
how this way of thinking damages anything.

[CBFalconer]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

.... snip ...

>>

>>int fn(void)
{
OtherNumber f = 56;

But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Here Jacob is almost correct. For automatic storage,
initialization statements just generate additional (unseen) code to
do the first assignment. For static storage the values are
normally stored in the code file image of a data segment.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[pete]

Ian Collins wrote:

>
jacob navia wrote:

Ian Collins wrote:

jacob navia wrote:
This makes possible:

int fn(void)
{
OtherNumber f = 56;

But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Wow.

So

const OtherNumber array[] {1,2,3};

isn't an initialisation?

You're missing the = (equal-sign punctuator).

--
pete

[Richard Heathfield]

CBFalconer said:

jacob navia wrote:

>Ian Collins wrote:

>>jacob navia wrote:

... snip ...

>>>
int fn(void)
{
OtherNumber f = 56;

But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Here Jacob is almost correct.

No, he isn't even remotely correct. Even the grammar is different.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Joe Wright]

Richard Heathfield wrote:

Fr************@googlemail.com said:

<snip>

>What ever happened to this famous Dan Pop?

Presumably, he popped. Knowing Dan, it was what he would have wanted.

For those who weren't around clc at the time: Dan Pop was strident,
irascible, arrogant, insulting, infuriating, and right. Many people
found the combination difficult to handle.

I do miss Dan but he wasn't right all the time. I caught him out once
(only once). Lawrence Kirby gets my vote for 'right' most of the time
and without the rudeness.

Heathfield was pretty good when he was younger. :-) g,d&r

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Heathfield]

Joe Wright said:

<snip>

I do miss Dan but he wasn't right all the time.

Very true. I found myself disagreeing with him quite a few times -
although it must be said that this was often on issues where "the right
answer" was a matter of opinion rather than of an ISO lookup.

I caught him out once (only once).

I don't recall how often I caught him out, but I'm pretty sure it was
more than once.

Lawrence Kirby gets my vote for 'right' most of the time
and without the rudeness.

Absolutely. Lawrence was in the Chris Torek mould - polite, forthright,
and right.

Heathfield was pretty good when he was younger. :-) g,d&r

Drop dead. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Kenny McCormack]

In article <tg************@homelinux.net>, Richard <rg****@gmail.comwrote:
....

>In fairness, he didn't say it isn't. He just says, and I can understand
why, that he doesn't bother to distinguish since it has little if any
effect in the understanding of how the program behaves. In this case it
doesn't kill the system to consider this as a one off assignment. I can't see
how this way of thinking damages anything.

Then you haven't been hanging around this ng long enough. Here, the
rule is that if it can be nit-picked, it will be. Reasonableness has no
place here.

[Richard Heathfield]

Ernie Wright said:

<snip>

More to the point, if you live in a Berne country, there's no way for
you to make a "clean" copy of a copyrighted work. Passing the work
through Vulgaria doesn't launder the copyright from it for you.

<grin@"Copyright laundering">

Lacking any authoritative knowledge of the subject at hand, I bow to
your confident assertions. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jacob navia]

CBFalconer wrote:

jacob navia wrote:

>Ian Collins wrote:

>>jacob navia wrote:

... snip ...

>>>int fn(void)
{
OtherNumber f = 56;
But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Here Jacob is almost correct. For automatic storage,
initialization statements just generate additional (unseen) code to
do the first assignment. For static storage the values are
normally stored in the code file image of a data segment.

You bring a sore point into the foreground.

I have not yet implemented a solution for assignments at the
global level. My example was within an inner scope. At a global
scope I do not know what to do yet.

[Ian Collins]

jacob navia wrote:

CBFalconer wrote:

>jacob navia wrote:

>>Ian Collins wrote:
jacob navia wrote:

... snip ...

>>>>int fn(void)
{
OtherNumber f = 56;
But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;
I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Here Jacob is almost correct. For automatic storage,
initialization statements just generate additional (unseen) code to
do the first assignment. For static storage the values are
normally stored in the code file image of a data segment.

You bring a sore point into the foreground.

I have not yet implemented a solution for assignments at the
global level. My example was within an inner scope. At a global
scope I do not know what to do yet.

You see, you can't fully implement a new numeric type with operator
overloading alone, you have to add constructors into the pot to cope
with all initialisation situations.

Your scheme won't work with my earlier example:

extern f( OtherNumber );

f( 42 );

--
Ian Collins.

[Ernie Wright]

Richard Heathfield wrote:

Ernie Wright said:

<snip>

>>More to the point, if you live in a Berne country, there's no way for
you to make a "clean" copy of a copyrighted work. Passing the work
through Vulgaria doesn't launder the copyright from it for you.

<grin@"Copyright laundering">

Lacking any authoritative knowledge of the subject at hand, I bow to
your confident assertions. :-)

I'm full of those. In this case I think they're reasonably truthy. :)

- Ernie http://home.comcast.net/~erniew

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>CBFalconer wrote:

>>jacob navia wrote:
Ian Collins wrote:
jacob navia wrote:
>
... snip ...
>int fn(void)
>{
> OtherNumber f = 56;
But that's initialisation, not assignment.
>
Assignment is
>
OtherNumber f;
f = 56;
I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.
Here Jacob is almost correct. For automatic storage,
initialization statements just generate additional (unseen) code to
do the first assignment. For static storage the values are
normally stored in the code file image of a data segment.

You bring a sore point into the foreground.

I have not yet implemented a solution for assignments at the
global level. My example was within an inner scope. At a global
scope I do not know what to do yet.

You see, you can't fully implement a new numeric type with operator
overloading alone, you have to add constructors into the pot to cope
with all initialisation situations.

Your scheme won't work with my earlier example:

extern f( OtherNumber );

f( 42 );

This can be done with:
f ((OtherNumber)42);

if you overload the cast operator.

Without an explicit cast it is an error. This is a design issue.

At first glance, you see:
f(42);
and you do not expect that a constructor is called, you think that
f accepts an integer argument. Requiring an explicit cast makes
the reader aware that the passed type is OtherNumber, not int,
and makes the writer avoid unintentionally passing 42 to a function
that expects a OtherNumber!

Making the language less explicit is NOT a good idea, as C++ proves :-)

jacob

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

jacob navia wrote:

>Ian Collins wrote:

jacob navia wrote:
Ian Collins wrote:
jacob navia wrote:

[...]

>>>Better to use the assignment operator.

OtherNumber operator=(int n);
How does that help with initialisation?

This makes possible:

int fn(void)
{
OtherNumber f = 56;

But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;

I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Then:
1 you don't distinguish between object definitions and statements,
2 and you also think that you can assign an array value
to an object of array type.

I suspect what jacob means is that, with his non-standard operator
overloading extension, an overloaded assignment operator will be
invoked for either an assignment or an initialization. I presume he
doesn't allow the assignment operator to be overloaded for array
types, so the issue of array initializations vs. assignments doesn't
arise.

But since it's not standard C, I don't know why we're discussing it
here. It appears to be a valid extension (see C99 4p6), as long as an
overloaded operator can't be applied to types that already have that
operator. For example, if this:
double d;
int i;
d + i;
were allowed to invoke an overloaded "+" operator, that would make the
compiler non-conforming. (And I'm guilty myself of perpetuating this
discussion.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Keith Thompson wrote:

pete <pf*****@mindspring.comwrites:

>jacob navia wrote:

>>Ian Collins wrote:
jacob navia wrote:
Ian Collins wrote:
>jacob navia wrote:

[...]

>>>>>>Better to use the assignment operator.
>>>
>>OtherNumber operator=(int n);
>How does that help with initialisation?
>>
This makes possible:
>
int fn(void)
{
OtherNumber f = 56;
But that's initialisation, not assignment.

Assignment is

OtherNumber f;
f = 56;
I do not make distinction between initialisation and assignment.
Initialisation is just another assignment that happens to go into
previously not initialized memory.

Then:
1 you don't distinguish between object definitions and statements,
2 and you also think that you can assign an array value
to an object of array type.

I suspect what jacob means is that, with his non-standard operator
overloading extension, an overloaded assignment operator will be
invoked for either an assignment or an initialization. I presume he
doesn't allow the assignment operator to be overloaded for array
types, so the issue of array initializations vs. assignments doesn't
arise.

To tell you the truth, I have never thought about it. That is why this
discussions are good. It is a very legitimate question that I have not
looked at all. Oversight.

One way of solving that is to see if there is an overloaded operator
assignment or a cast operator that allows to convert the result of
the RHS into the expected array type.

OtherNumber Table[] = {1,2,3,4};

would require either an

OtherNumber operator=(int); // Assignment operator
or
OtherNumber operator()(int); // Cast operator
Within my system, I do not allow chains. The operators must work
directly, so it is not possible to pass through an intermediate type.

But since it's not standard C, I don't know why we're discussing it
here.

Because it is an interesting subject. And it helps me develop it
correctly!

It appears to be a valid extension (see C99 4p6), as long as an
overloaded operator can't be applied to types that already have that
operator. For example, if this:
double d;
int i;
d + i;
were allowed to invoke an overloaded "+" operator, that would make the
compiler non-conforming. (And I'm guilty myself of perpetuating this
discussion.)

You are not guilty of anything. And true, that is NOT allowed. At least
ONE parameter for the overloaded operator MUST be a user defined type.

For pointer parameters, only combinations where there is NO conflicts
can be used. For instance you cant define an operator addition with a
pointer and an integer since addition is defined for pointers and
integers already.

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>>
Your scheme won't work with my earlier example:

extern f( OtherNumber );

f( 42 );

This can be done with:
f ((OtherNumber)42);

if you overload the cast operator.

So let me get this right, an overloaded cast operator creates an
instance of the type. Sounds like a constructor by another name to me.

Without an explicit cast it is an error. This is a design issue.

At first glance, you see:
f(42);
and you do not expect that a constructor is called, you think that
f accepts an integer argument. Requiring an explicit cast makes
the reader aware that the passed type is OtherNumber, not int,
and makes the writer avoid unintentionally passing 42 to a function
that expects a OtherNumber!

Then your new type does not behave like a standard type it is attempting
to mimic.

Making the language less explicit is NOT a good idea, as C++ proves :-)

On the contary, C++ gives one the choice of implicit or explicit
constructors. Each has its place.
--
Ian Collins.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Ian Collins wrote:

>>Your scheme won't work with my earlier example:

extern f( OtherNumber );

f( 42 );

This can be done with:
f ((OtherNumber)42);

if you overload the cast operator.

So let me get this right, an overloaded cast operator creates an
instance of the type. Sounds like a constructor by another name to me.

You can name it as you wish. What is important are the semantics.

A cast operator CONVERTS an input type into an output type. It can
never accept nothing, as a constructor would do. It *must* have
an input argument.

>Without an explicit cast it is an error. This is a design issue.

At first glance, you see:
f(42);
and you do not expect that a constructor is called, you think that
f accepts an integer argument. Requiring an explicit cast makes
the reader aware that the passed type is OtherNumber, not int,
and makes the writer avoid unintentionally passing 42 to a function
that expects a OtherNumber!

Then your new type does not behave like a standard type it is attempting
to mimic.

Maybe, please be more explicit. If you have:

structure foo;

struct foo SomeFunction(struct foo);

SomeFunction(42);

This is an error. Why doesn't it behave as the int type?

>Making the language less explicit is NOT a good idea, as C++ proves :-)

On the contary, C++ gives one the choice of implicit or explicit
constructors. Each has its place.

I just do not agree. The objective here is to enhance the C language,
not to mimick C++!

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>Then your new type does not behave like a standard type it is attempting
to mimic.

Maybe, please be more explicit. If you have:

structure foo;

struct foo SomeFunction(struct foo);

SomeFunction(42);

This is an error. Why doesn't it behave as the int type?

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction just
as you would be able to pass an integer to a function which has long or,
where supported, long long as its parameter.

--
Ian Collins.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Ian Collins wrote:

>>Then your new type does not behave like a standard type it is attempting
to mimic.

Maybe, please be more explicit. If you have:

structure foo;

struct foo SomeFunction(struct foo);

SomeFunction(42);

This is an error. Why doesn't it behave as the int type?

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction just
as you would be able to pass an integer to a function which has long or,
where supported, long long as its parameter.

Well, IF there is a conversion for long long and you pass an int, I make
"the usual arithmetic conversions" as specified in the standard, and
then convert the int in long long. How to make those conversions is a
complicated stuff, and I have published in the comp.std.c a paper about
the rules. In general I first try without any conversions at all.
Then I do the usual conversions and try again.

I have to find ONLY ONE conversion. If I find more than one it is an
error.

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>Ian Collins wrote:

>>>Then your new type does not behave like a standard type it is
attempting
to mimic.

Maybe, please be more explicit. If you have:

structure foo;

struct foo SomeFunction(struct foo);

SomeFunction(42);

This is an error. Why doesn't it behave as the int type?

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction just
as you would be able to pass an integer to a function which has long or,
where supported, long long as its parameter.

Well, IF there is a conversion for long long and you pass an int, I make
"the usual arithmetic conversions" as specified in the standard, and
then convert the int in long long. How to make those conversions is a
complicated stuff, and I have published in the comp.std.c a paper about
the rules. In general I first try without any conversions at all.
Then I do the usual conversions and try again.

Yes, but my point is if your new numeric type is a struct with
overloaded operators representing 64 bit int on a system the does not
have one, say

typedef struct Uint64
{
unsigned bit1, bit2;
} uint64_t;

Then you can't write

extern f( uint64_t );

f( 42 );

Which would appear to be a natural thing to do.

--
Ian Collins.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Ian Collins wrote:

>>jacob navia wrote:
Ian Collins wrote:
Then your new type does not behave like a standard type it is
attempting
to mimic.
>
Maybe, please be more explicit. If you have:

structure foo;

struct foo SomeFunction(struct foo);

SomeFunction(42);

This is an error. Why doesn't it behave as the int type?

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction just
as you would be able to pass an integer to a function which has long or,
where supported, long long as its parameter.

Well, IF there is a conversion for long long and you pass an int, I make
"the usual arithmetic conversions" as specified in the standard, and
then convert the int in long long. How to make those conversions is a
complicated stuff, and I have published in the comp.std.c a paper about
the rules. In general I first try without any conversions at all.
Then I do the usual conversions and try again.

Yes, but my point is if your new numeric type is a struct with
overloaded operators representing 64 bit int on a system the does not
have one, say

typedef struct Uint64
{
unsigned bit1, bit2;
} uint64_t;

Then you can't write

extern f( uint64_t );

f( 42 );

Which would appear to be a natural thing to do.

It is a natural thing to do. But you have to specify a conversion
from int to your structure! The compiler can't figure out alone
how to do it.

You overload the cast operator, and THEN you write:
f((Uint64)42);

[Ian Collins]

jacob navia wrote:

Ian Collins wrote:

>jacob navia wrote:

>>Well, IF there is a conversion for long long and you pass an int, I make
"the usual arithmetic conversions" as specified in the standard, and
then convert the int in long long. How to make those conversions is a
complicated stuff, and I have published in the comp.std.c a paper about
the rules. In general I first try without any conversions at all.
Then I do the usual conversions and try again.

Yes, but my point is if your new numeric type is a struct with
overloaded operators representing 64 bit int on a system the does not
have one, say

typedef struct Uint64
{
unsigned bit1, bit2;
} uint64_t;

Then you can't write

extern f( uint64_t );

f( 42 );

Which would appear to be a natural thing to do.

It is a natural thing to do. But you have to specify a conversion
from int to your structure! The compiler can't figure out alone
how to do it.

Exactly, you've added operator overloading, so why not initialisation?

You overload the cast operator, and THEN you write:
f((Uint64)42);

Yes but if you intend to provide a means of adding numeric types via
operator overloading, you should provide the full set of operations on
the struct, which include initialisation. Then you can use your new
shiny 64 bit int type to write code that requires 64 bit math on
platforms with and without built in long long.

You should be able to use your new type as if it were a built in one,
otherwise the job is incomplete.

--
Ian Collins.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Ian Collins wrote:

>jacob navia wrote:

[...]

>>Making the language less explicit is NOT a good idea, as C++ proves :-)

On the contary, C++ gives one the choice of implicit or explicit
constructors. Each has its place.

I just do not agree. The objective here is to enhance the C language,
not to mimick C++!

Your language includes standard C as a subset, plus the extensions
you've added, right?

It seems to me that most of your extensions are more or less
compatible with C++. In other words, the language you want is
somewhere *between* C and C++.

Wouldn't it have been easier to take an existing C++ compiler and
selectively disable the features you don't like? (And then it *might*
be reasonable to discuss it in comp.lang.c++.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Ian Collins said:

<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

<snip>

>Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

I guess is is getting to be on par with old pennies when it comes to
topicality.

--
Ian Collins.

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Ian Collins said:

<snip>

>Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

Incredible. It would seem that there is one rule for Richard Heathfield
and another one for others.

It's called a developing thread. And it's staying civil. If you don't
like it, then kill the thread. If you don't know how to use a news
reader then go somewhere they are on topic and ask someone
nicely. Hopefully they are a little more civil and less up themselves
than you.

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Ian Collins wrote:

>>jacob navia wrote:

[...]

>>>Making the language less explicit is NOT a good idea, as C++ proves :-)

On the contary, C++ gives one the choice of implicit or explicit
constructors. Each has its place.

I just do not agree. The objective here is to enhance the C language,
not to mimick C++!

Your language includes standard C as a subset, plus the extensions
you've added, right?

It seems to me that most of your extensions are more or less
compatible with C++. In other words, the language you want is
somewhere *between* C and C++.

Wouldn't it have been easier to take an existing C++ compiler and
selectively disable the features you don't like? (And then it *might*
be reasonable to discuss it in comp.lang.c++.)

As I have said many times the crux of the matter is the object oriented
aspects of C++.

For instance the operator [] can only be overloaded within a class
definition, hence it has the implicit "this" argument. This would break
C, and transform it into C++.

Within the context of C, the operator [ ] receives two arguments, and
the operator []= three: the container to index, the index, and the new
value. This is absolutely different to C++ since in C++ there is NO
distinction between [ ] and [ ]= (read and write).

In other cases of operator overloading, I am compatible with C++,
like, for instance, the operator +.

Note that I do not think that the extensions I propose transform
anything in the basic language and hence I think they are extensions to
C.

[jacob navia]

Richard wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

>Ian Collins said:

<snip>

>>Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

Incredible. It would seem that there is one rule for Richard Heathfield
and another one for others.

It's called a developing thread. And it's staying civil. If you don't
like it, then kill the thread. If you don't know how to use a news
reader then go somewhere they are on topic and ask someone
nicely. Hopefully they are a little more civil and less up themselves
than you.

Please let's ignore that guy. This is a good discussion, and helps me to
explain how C can be enhanced and spot the bugs in my specifications.

Let's agree that "OT" nonsense is off topic ok? :-)

[Ian Collins]

jacob navia wrote:

Keith Thompson wrote:

>>
It seems to me that most of your extensions are more or less
compatible with C++. In other words, the language you want is
somewhere *between* C and C++.

Wouldn't it have been easier to take an existing C++ compiler and
selectively disable the features you don't like? (And then it *might*
be reasonable to discuss it in comp.lang.c++.)

As I have said many times the crux of the matter is the object oriented
aspects of C++.

For instance the operator [] can only be overloaded within a class
definition, hence it has the implicit "this" argument. This would break
C, and transform it into C++.

And the support required for your extensions doesn't?

As soon as you add references (which probably is a good extension to C)
and overloading, you start to break ABI compatibility with other C
compilers on your platform.

--
Ian Collins.

[Kenny McCormack]

In article <ko************@homelinux.net>, Richard <rg****@gmail.comwrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>Ian Collins said:

<snip>

>>Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

Incredible. It would seem that there is one rule for Richard Heathfield
and another one for others.

It's called a developing thread. And it's staying civil. If you don't
like it, then kill the thread. If you don't know how to use a news
reader then go somewhere they are on topic and ask someone
nicely. Hopefully they are a little more civil and less up themselves
than you.

And thanks for watching another episode of:

"CLC Regulars ... eating their own"

It is always so satisfying (when they turn on each other).

[Spiros Bousbouras]

On Aug 31, 10:03 am, Richard Heathfield <[e-mail]:

Ian Collins said:

<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

Don't you think it's a bit too late to complain about
topicality in *this* thread ? You recently had an extended
exchange on legal matters yourself.

[Richard]

Spiros Bousbouras <sp****@gmail.comwrites:

On Aug 31, 10:03 am, Richard Heathfield <[e-mail]:

>Ian Collins said:

<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

Don't you think it's a bit too late to complain about
topicality in *this* thread ? You recently had an extended
exchange on legal matters yourself.

Heathfield thinks he is in charge. He is used to pushing people around
and getting his own way.

[Kenny McCormack]

In article <jt************@homelinux.net>, Richard <rg****@gmail.comwrote:

>Spiros Bousbouras <sp****@gmail.comwrites:

>On Aug 31, 10:03 am, Richard Heathfield <[e-mail]:

>>Ian Collins said:

<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

Don't you think it's a bit too late to complain about
topicality in *this* thread ? You recently had an extended
exchange on legal matters yourself.

Heathfield thinks he is in charge. He is used to pushing people around
and getting his own way.

Yes. The cops *are* special. They are allowed to carry guns, even if
no one else is. Similarly, netcops are allowed (by their own lights, if
no one else's) to push topicality around even when sensible people would
defer that option.

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Keith Thompson wrote:

>>It seems to me that most of your extensions are more or less
compatible with C++. In other words, the language you want is
somewhere *between* C and C++.

Wouldn't it have been easier to take an existing C++ compiler and
selectively disable the features you don't like? (And then it *might*
be reasonable to discuss it in comp.lang.c++.)

As I have said many times the crux of the matter is the object oriented
aspects of C++.

For instance the operator [] can only be overloaded within a class
definition, hence it has the implicit "this" argument. This would break
C, and transform it into C++.

And the support required for your extensions doesn't?

As soon as you add references (which probably is a good extension to C)
and overloading, you start to break ABI compatibility with other C
compilers on your platform.

This is a problem.

The way to overcome this is to standardize the name mangling, to keep
binary compatibility.

Anyway, binary compatibility is NOT guaranteed even today.

If you use Microsoft visual C, it is impossible to link with gcc anyway.
And the other way around, even under the same OS.

[jacob navia]

Richard Heathfield wrote:

Ian Collins said:

<snip>

>Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's topical?
Perhaps comp.compilers.lcc is appropriate. Thank you.

heathfield,

You wrote in comp.std.c, under the thread

"implcit inr" the following:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>

I agree with you.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Richard Heathfield wrote:

>Ian Collins said:
<snip>

>>Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.

Ian, could you please take this discussion somewhere where it's
topical? Perhaps comp.compilers.lcc is appropriate. Thank you.

heathfield,

You wrote in comp.std.c, under the thread

"implcit inr" the following:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>

I agree with you.

Was that an attempt to refute Richard's statement that this discussion
is off-topic here?

I believe he was discussing the hypothetical possibility of adding
operator overloading to a future version of the C standard. That's
perfectly topical in comp.std.c.

Detailed discussions of how to use a compiler-specific extension would
be topical in a newsgroup devoted to that compiler.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard]

Keith Thompson <ks***@mib.orgwrites:

jacob navia <ja***@jacob.remcomp.frwrites:

>Richard Heathfield wrote:

>>Ian Collins said:
<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.
Ian, could you please take this discussion somewhere where it's
topical? Perhaps comp.compilers.lcc is appropriate. Thank you.

heathfield,

You wrote in comp.std.c, under the thread

"implcit inr" the following:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>

I agree with you.

Was that an attempt to refute Richard's statement that this discussion
is off-topic here?

I believe he was discussing the hypothetical possibility of adding
operator overloading to a future version of the C standard. That's
perfectly topical in comp.std.c.

Not according to RH it isn't. Since it's not "standard C". It is a
possibility in the future. For all you know what they are discussing in
this thread is a possibility for future C too.

Detailed discussions of how to use a compiler-specific extension would
be topical in a newsgroup devoted to that compiler.

It's a developing thread. Kill it. Or is there an arbitrary point where
people commonly accept to take a perfectly good and linear conversation
elsewhere?

I would not say start totally OT threads. But ones which adapt are
fine. Its what people do. It's why newsreaders maintain threads. Its why
you can ignore threads which become less interesting.
,----
| (defun cg-gnus-summary-ignore-thread ()
| (interactive)
| (let* ((hdr (gnus-summary-article-header))
| (subj (aref hdr 1)))
| (gnus-summary-score-entry "Subject" subj 'S' -1000
| (current-time-string))
| (gnus-summary-limit-to-unread)
| (gnus-summary-scroll-up 0)))
|
| ;;F7 ignores a thread
| (define-key gnus-summary-mode-map (kbd "<f7>") 'cg-gnus-summary-ignore-thread)
`----

[jacob navia]

Keith Thompson wrote:

jacob navia <ja***@jacob.remcomp.frwrites:

>Richard Heathfield wrote:

>>Ian Collins said:
<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.
Ian, could you please take this discussion somewhere where it's
topical? Perhaps comp.compilers.lcc is appropriate. Thank you.

heathfield,

You wrote in comp.std.c, under the thread

"implcit inr" the following:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>

I agree with you.

Was that an attempt to refute Richard's statement that this discussion
is off-topic here?

Surely not. It was a quote from a famous member of this group
that confirms that operator overloading is "ideal for complex and
bignum types, for vector operations and for combinatorics".

I believe he was discussing the hypothetical possibility of adding
operator overloading to a future version of the C standard. That's
perfectly topical in comp.std.c.

That thread started on a discussion about C99 and what was missing
and what was wrong with it. Within that context, mr heathfield make
that remark.

Detailed discussions of how to use a compiler-specific extension would
be topical in a newsgroup devoted to that compiler.

I think that since everybody (heathfield included) agrees that this is
missing from the language why don't we try to specify how that could be
included?

The founder of this group wrote on Fri Oct 22 01:28:04 1982:

My suggestion for a "C" newsgroup met with support and no
opposition so net.lang.c (note lower case) has been created.

It's purpose is to carry on discussion of C programming and
the C programming language. Appropriate topics are

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.

Jerry Schwarz
BTL -- Murray Hill
harpo!eagle!jerry
See "Suggestions for C modifications or extensions"?

Have we just become too OLD !!!! ?????

Heathfield and many other people KNOW that this could IMPROVE
the language. Is it that ALL improvements are exclusively
the domain of C++???

Is this a discussion group about a DEAD (no longer growing)
language?

Please let's stop this and resume the discussion.

A paper with the detailed algorithms was published at
ftp://ftp.cs.virginia.edu:/pub/lcc-win32 but virginia
stopped its ftp service. I will upload it somewhere else
monday.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Keith Thompson wrote:

>jacob navia <ja***@jacob.remcomp.frwrites:

>>Richard Heathfield wrote:
Ian Collins said:
<snip>

Say your type is a long long implementation on a system that does not
have it, then you should be able to pass an integer to SomeFunction
just as you would be able to pass an integer to a function which has
long or, where supported, long long as its parameter.
Ian, could you please take this discussion somewhere where it's
topical? Perhaps comp.compilers.lcc is appropriate. Thank you.
heathfield,

You wrote in comp.std.c, under the thread

"implcit inr" the following:

<quote>
One of the very few temptations C++ has to offer that I find hard to
resist is that of operator overloading, which is ideal for complex and
bignum types, for vector operations (in the graphical sense), and for
combinatorics.
<end quote>

I agree with you.

Was that an attempt to refute Richard's statement that this
discussion
is off-topic here?

Surely not. It was a quote from a famous member of this group
that confirms that operator overloading is "ideal for complex and
bignum types, for vector operations and for combinatorics".

"Surely not." May I assume then that you agree that this discussion
is off-topic here? Or are you trying to be sarcastic again (you're
not good at it).

>I believe he was discussing the hypothetical possibility of adding
operator overloading to a future version of the C standard. That's
perfectly topical in comp.std.c.

That thread started on a discussion about C99 and what was missing
and what was wrong with it. Within that context, mr heathfield make
that remark.

>Detailed discussions of how to use a compiler-specific extension would
be topical in a newsgroup devoted to that compiler.

I think that since everybody (heathfield included) agrees that this is
missing from the language why don't we try to specify how that could be
included?

Go ahead -- but comp.lang.c is for discussion of C as it actually is.
(We hardly have a shortage of things to talk about.)

The founder of this group wrote on Fri Oct 22 01:28:04 1982:

My suggestion for a "C" newsgroup met with support and no
opposition so net.lang.c (note lower case) has been created.

It's purpose is to carry on discussion of C programming and
the C programming language. Appropriate topics are

Queries on how to write something in C
Queries about why some C code behaves the way it does
Suggestions for C modifications or extensions
C coding "tricks"
Compiler bugs
Availability of compilers
etc.

Jerry Schwarz
BTL -- Murray Hill
harpo!eagle!jerry
See "Suggestions for C modifications or extensions"?

Have we just become too OLD !!!! ?????

comp.std.c had not yet been created then.

Heathfield and many other people KNOW that this could IMPROVE
the language. Is it that ALL improvements are exclusively
the domain of C++???

Nobody said that.

Is this a discussion group about a DEAD (no longer growing)
language?

This is a discussion group about C as it currently exists.

comp.std.c is ... oh, heck, I'm tired of explaining this to you.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Francine.Neary]

On Aug 31, 7:46 pm, Richard <[e-mail]:

Keith Thompson <[e-mail]:

I believe he was discussing the hypothetical possibility of adding
operator overloading to a future version of the C standard. That's
perfectly topical in comp.std.c.

Not according to RH it isn't. Since it's not "standard C". It is a
possibility in the future. For all you know what they are discussing in
this thread is a possibility for future C too.

Is it really so hard to understand? Discussions about standard C are
topical here in comp.lang.c, while discussions about the C standard
(including proposed additions in a future version of the standard) are
topical in comp.std.c. I've only been reading this group for a few
months and I've managed to pick it up already :)

Detailed discussions of how to use a compiler-specific extension would
be topical in a newsgroup devoted to that compiler.

It's a developing thread. Kill it. Or is there an arbitrary point where
people commonly accept to take a perfectly good and linear conversation
elsewhere?

It's clear that people are just wasting their time and energy by
pointing out when Jacob's posts are off-topic, as he places
advertising his compiler above any consideration for other readers of
this newsgroup. (My own feeling, btw, is that he shows signs of being
mentally unstable and deserves pity not scorn.)

>
I would not say start totally OT threads. But ones which adapt are
fine. Its what people do. It's why newsreaders maintain threads. Its why
you can ignore threads which become less interesting.

,----
| (defun cg-gnus-summary-ignore-thread ()
| (interactive)
| (let* ((hdr (gnus-summary-article-header))
| (subj (aref hdr 1)))
| (gnus-summary-score-entry "Subject" subj 'S' -1000
| (current-time-string))
| (gnus-summary-limit-to-unread)
| (gnus-summary-scroll-up 0)))
|
| ;;F7 ignores a thread
| (define-key gnus-summary-mode-map (kbd "<f7>") 'cg-gnus-summary-ignore-thread)
`----

[jacob navia]

Ian Collins wrote:

jacob navia wrote:

>Ian Collins wrote:

>>jacob navia wrote:

>>>Well, IF there is a conversion for long long and you pass an int, I make
"the usual arithmetic conversions" as specified in the standard, and
then convert the int in long long. How to make those conversions is a
complicated stuff, and I have published in the comp.std.c a paper about
the rules. In general I first try without any conversions at all.
Then I do the usual conversions and try again.

Yes, but my point is if your new numeric type is a struct with
overloaded operators representing 64 bit int on a system the does not
have one, say

typedef struct Uint64
{
unsigned bit1, bit2;
} uint64_t;

Then you can't write

extern f( uint64_t );

f( 42 );

Which would appear to be a natural thing to do.

It is a natural thing to do. But you have to specify a conversion
from int to your structure! The compiler can't figure out alone
how to do it.

Exactly, you've added operator overloading, so why not initialisation?

>You overload the cast operator, and THEN you write:
f((Uint64)42);

Yes but if you intend to provide a means of adding numeric types via
operator overloading, you should provide the full set of operations on
the struct, which include initialisation. Then you can use your new
shiny 64 bit int type to write code that requires 64 bit math on
platforms with and without built in long long.

You should be able to use your new type as if it were a built in one,
otherwise the job is incomplete.

Please correct me if I am wrong, but how do you do this in C++?
static OtherNumberType OtherTypeArray[] = {1,2,3,4,5};

at the GLOBAL level?

or

static OtherNumberType Myvar =
4555566665544444455544545454.887787778777777789888 778;

As far as I remember that is NOT possible at the global level.

Then that means that even in C++ a derived number type is NOT
exactly like the built in types.