Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58253 > unrolled thread

What is "complexifying" C?

Back to article view | Back to comp.lang.c

Contents

  What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-16 22:55 +0100
    Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-16 22:55 +0000
      Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:41 -0700
        Re: What is "complexifying"  C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 00:05 +0000
        Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 01:12 +0000
        Re: What is "complexifying"  C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:58 -0700
      Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 07:16 +0100
        Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 13:50 +0000
          Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 14:59 +0100
            Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:22 +0100
              Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-17 16:16 +0100
            Re: What is "complexifying"  C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-17 14:39 +0000
            Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 15:23 +0000
          Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:40 -0700
          Re: What is "complexifying"  C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-18 22:49 +0000
            Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 13:55 +0000
              Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 15:37 +0000
                Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-19 23:06 +0100
                  Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 22:38 +0000
                    Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 19:43 +1300
                      Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 07:49 +0100
                      Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 02:29 -0500
                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 21:37 +1300
                          Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 03:40 -0500
                            Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-20 10:18 +0100
                              Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 00:19 -0500
                          Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 03:15 -0700
                            Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 13:51 +1300
                              Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 15:21 +1300
                              Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 00:57 -0700
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 22:28 +1300
                                  Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-22 02:59 -0700
                                  Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 11:16 -0700
                                    Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 07:25 +1300
                                      Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 12:06 -0700
                                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:01 +1300
                                          Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 03:09 -0700
                                        Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-23 01:42 -0700
                                    Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 19:32 +0100
                                      Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-22 17:34 -0500
                                        Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 20:07 -0400
                                          Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 00:00 -0500
                                            Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:04 +1300
                                            Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-23 23:22 -0400
                                    Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 14:54 -0400
                              Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-23 00:35 +0100
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:06 +1300
                              Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:25 +1300
                                Re: What is "complexifying" C? Martin Shobe <martin.shobe@yahoo.com> - 2015-03-22 23:33 -0500
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:01 +1300
                                  Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 09:41 -0400
                                    Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 10:23 -0400
                                      Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-24 07:10 +1300
                                        Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 14:57 -0400
                                          Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 09:36 +0100
                                            Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 08:42 +0000
                                              Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 11:23 +0100
                                                Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 10:52 +0000
                              Re: What is "complexifying" C? raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:58 +0000
                            Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 02:38 +0100
                            Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 09:11 -0400
                        Re: What is "complexifying" C? Les Cargill <lcargill99@comcast.com> - 2015-03-20 06:30 -0500
                      Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-20 10:31 +0000
                      Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-20 13:49 +0000
                        Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 09:23 -0700
                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:28 +1300
                  Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 01:04 -0700
      Re: What is "complexifying"  C? Keith Thompson <kst-u@mib.org> - 2015-03-17 08:05 -0700
        Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 16:08 +0100
          Re: What is "complexifying"  C? Keith Thompson <kst-u@mib.org> - 2015-03-17 11:09 -0700
            Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 21:37 +0100
              Re: What is "complexifying"  C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 00:40 -0500
        Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 15:34 +0000
      Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 15:06 +0000
    Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-17 00:05 +0100
    Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 23:20 +0000
    Re: What is "complexifying"  C? Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:42 +1300
    Re: What is "complexifying"  C? Mark Storkamp <mstorkamp@yahoo.com> - 2015-03-17 08:59 -0500
      Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:18 +0100
      Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 14:41 +0000
        Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:47 -0700
          Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-19 00:26 +0000
            Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-19 03:23 -0700
              Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-19 11:19 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#58665 — Re: What is "complexifying" C?

On 3/20/15 6:15 AM, Malcolm McLean wrote:
> On Friday, March 20, 2015 at 8:37:12 AM UTC, Ian Collins wrote:
>>
>> I agree again.  The one thing C++ can do that C can't is manage resource
>> lifetime with constructors and destructors.  But then again, if you want
>> C++, you know where to find it...
>>
> lcc_win has garbage collection.
> So effectively you have automatic destructors. C++ allows you to do things like
> close a file or make an space invader explode in a destructor, but generally this
> is a bad idea (maybe not the space invaders). Destructors should just free
> memory, detaching should be done explicitly.
>

"Detaching" may be best done separately so you can report errors, but if 
the detaching wasn't done prior to the destructor, then the destructor 
should do it to keep the resource in the expected state (and not cause 
leaks that can be worse then memory leaks). Some resources have no real 
possible errors on release so work fine in destructors (like locks).

I find garbage collectors/finailizers have the big problem that they 
treat memory as some sort of special resource, when it often really 
isn't (except perhaps that memory is more fungible than other resources 
so the problems with garbage collecting are not as noticeable).

The existence of them seems to more often make people lazy about 
cleaning up after themselves, causing more serious problems.

[toc] | [prev] | [next] | [standalone]

#58488 — Re: What is "complexifying" C?

Robert Wessel wrote:
> On Fri, 20 Mar 2015 19:43:21 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
>
>> Greg Martin wrote:
>>> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>>>
>>>> Look at what happened with complex numbers. There are MANY ways of doing
>>>> a complex division, if you care about speed, or accuracy or robustness,
>>>> or other criteria. With the language solution you
>>>>
>>>> 1) Complexify enormously ALL the C implementations that have to add that
>>>> feature.
>>>>
>>>> 2) You tie the user to its implementation decisions. He/she can't change
>>>> the way a complex division is done.
>>>>
>>>> Can you propose another solution?
>>>>
>>>
>>> You mean other then writing the code to do it? No.
>>>
>>> How does operator overloading remove the burden of writing the code? Or
>>> are you suggesting it's not possible for programmers to operate on
>>> complex numbers in C?
>>
>> His point was in a language with operating overloading (such as C++) you
>> don't have to change the core language in order to add new numeric
>> types, be they complex number of otherwise.
>>
>> The burden is removed from the language standard and implementation and
>> in the case of complex numbers, the user gets the flexibility of
>> choosing the underlying type and implementation.
>
>
> Although in the case of something like complex, I can't work up a lot
> of sympathy for the compiler implementers.  Or for that matter, adding
> bignum and decimal math.  Really, a few more data types in a language
> like C is just not a big deal.
>
> And there are really a pretty small set of things you're really want
> to overload on the numeric operators anyway.
>
> While operator overloading certainly has its uses, I'd judge that a
> basic implementation of classes would be far more useful in C, just
> for the encapsulation.  IMO, polymorphism ends up rather down the
> list, somewhere after inheritance.  But that's me.  Jacob obviously
> made a different judgment.
>

It could go either way. I like the "encapsulation" you
get with block delimiters and file scope in 'C' more
than the corresponding  sort from C++.

But I'm used to it and it flows easily; with C++ you must plan
it and navigate the side effects.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#58482 — Re: What is "complexifying" C?

On 20/03/2015 06:43, Ian Collins wrote:
> Greg Martin wrote:

>> How does operator overloading remove the burden of writing the code? Or
>> are you suggesting it's not possible for programmers to operate on
>> complex numbers in C?
>
> His point was in a language with operating overloading (such as C++) you
> don't have to change the core language in order to add new numeric
> types, be they complex number of otherwise.

But you still have to change the core language in order to support 
operator overloading. And this is a rather more massive change.

> The burden is removed from the language standard and implementation and
> in the case of complex numbers, the user gets the flexibility of
> choosing the underlying type and implementation.

The burden then gets put onto the user, who then has to design and 
implement extensions to the language. This is subtly more difficult than 
just creating a bunch of new functions to support +, -, * and /.

It might also be necessary to support compares. And assign. And casts. 
There might be extra language changes needed to integrate with built-in 
and other user-defined types, or to deal with literals. Or to support 
constant folding. Or to add print formats. Or ...

I also think the number of people who are going to be making use of this 
is small: people implementing libraries perhaps. They might be better 
off with an SDK for adding the extensions to their main C compiler.

(You may have heard of a language called Seed7, where the main feature 
that makes it stand out is that you can add new syntax to it. However, 
once that feature has been used to create the basic language, I've never 
examples of Seed7 look any different. They might as well have hard-coded 
the syntax.

Although it's possible that I have seen such examples, but didn't 
recognise them as Seed7!)

Anyway I would agree that at the moment, it's just easier to use C++ for 
this stuff, and you can do so right now. Or you can just use lcc-win32, 
as I understand this is already all working and without any of the C++ 
overheads.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58498 — Re: What is "complexifying" C?

On 2015-03-20, Ian Collins <ian-news@hotmail.com> wrote:
> Greg Martin wrote:
>> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>>
>>> Look at what happened with complex numbers. There are MANY ways of doing
>>> a complex division, if you care about speed, or accuracy or robustness,
>>> or other criteria. With the language solution you
>>>
>>> 1) Complexify enormously ALL the C implementations that have to add that
>>> feature.
>>>
>>> 2) You tie the user to its implementation decisions. He/she can't change
>>> the way a complex division is done.
>>>
>>> Can you propose another solution?
>>>
>>
>> You mean other then writing the code to do it? No.
>>
>> How does operator overloading remove the burden of writing the code? Or
>> are you suggesting it's not possible for programmers to operate on
>> complex numbers in C?
>
> His point was in a language with operating overloading (such as C++) you 
> don't have to change the core language in order to add new numeric 
> types, be they complex number of otherwise.
>
> The burden is removed from the language standard and implementation and 
> in the case of complex numbers, the user gets the flexibility of 
> choosing the underlying type and implementation.
>

There is no semantic difference inherent in:
Complex c = a + b;
Complex c = complex_add (a, b);

You can argue one looks more natural and so could be easier to read.

	
-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58514 — Re: What is "complexifying" C?

On Friday, March 20, 2015 at 1:49:13 PM UTC, Greg Martin wrote:
>
> There is no semantic difference inherent in:
> Complex c = a + b;
> Complex c = complex_add (a, b);
> 
> You can argue one looks more natural and so could be easier to read.
> 
It depends what you're reading for.

If the difficulty is that the maths may not be correct, then the first method is
a lot easier. If the difficulty is that there's a bookkeeping or accuracy error 
somewhere, or maybe that the code is correct but too inefficient,  then the 
second is a lot easier, the first disguises problems.

[toc] | [prev] | [next] | [standalone]

#58529 — Re: What is "complexifying" C?

Greg Martin wrote:
> On 2015-03-20, Ian Collins <ian-news@hotmail.com> wrote:
>>
>> His point was in a language with operating overloading (such as C++) you
>> don't have to change the core language in order to add new numeric
>> types, be they complex number of otherwise.
>>
>> The burden is removed from the language standard and implementation and
>> in the case of complex numbers, the user gets the flexibility of
>> choosing the underlying type and implementation.
>>
>
> There is no semantic difference inherent in:
> Complex c = a + b;
> Complex c = complex_add (a, b);
>
> You can argue one looks more natural and so could be easier to read.

Especially for any nontrivial expressions..

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#58472 — Re: What is "complexifying" C?

On Thursday, March 19, 2015 at 10:06:25 PM UTC, jacob navia wrote:
> 
> Look at what happened with complex numbers. There are MANY ways of doing 
> a complex division, if you care about speed, or accuracy or robustness, 
> or other criteria. With the language solution you
> 
> 1) Complexify enormously ALL the C implementations that have to add that 
> feature.
> 
> 2) You tie the user to its implementation decisions. He/she can't change 
> the way a complex division is done.
> 
> Can you propose another solution?
>
I think you've got to assume that  z1 / z2; will "do the right thing".
If you need to worry about the specific division algorithm used,
you shouldn't be using operator overloading. You should write

cdiv_fast(&zres, &z1, &z2);

which tells your reader that you've gone for a fast and maybe unstable
or inaccurate divide.  

[toc] | [prev] | [next] | [standalone]

#58307

Bartc <bc@freeuk.com> writes:
> On 16/03/2015 21:55, jacob navia wrote:
>> There are now following number types in C:
>>
>> 1) char (signed and unsigned)
>> 2) short (signed/unsigned)
>> 3) int (signed/unsigned)
>> 4) long (signed/unsigned)
>> 5) long long (signed/unsigned)
>>
>> That makes for 10 integer types
>> 11) float
>> 12) double
>> 13) long double
>> 14) float _Complex
>> 15) double _Complex
>> 16) long double _Complex
>>
>> That makes for 16 different types of numbers
>
> That's one way of looking at it (and you forgot about _Bool).

And plain char, which is distinct from unsigned char and signed char.

And implementation-defined extended integer types -- though I don't know
of any compilers that actually provide them (gcc's __int128 doesn't
conform to the standard's requirements for extended integer types).

> Another way is:
>
> (1) signed integers
> (2) unsigned integers
> (3) floating point
>
> With a range of widths for each (typically four widths for integers,
> and two for floating point). You make the width an attribute rather a
> completely distinct type. Yes, I've left out _Complex, but I doubt
> many people care.

You'd still need to define the existing types somehow if you don't want
to break just about every existing C program.  One possible approach is,
as I think you're suggesting, to have mechanisms for defining signed,
unsigned, and floating-point types by specifying their characteristics,
and then define the existing fundamental types using those mechanisms.

Ada does something like this.

I'm not convinced the fundamental mechanism for defining integer types
could be changed without breaking existing C code, but it's certainly
something to consider when designing new languages.

[...]

>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>> proposes a SINGLE mechanism that would allow users to implement their
>> own number types without adding the enormous complexity of integrating
>> all those numbers into the compiler itself.

Operator overloading by itself doesn't do this.  It is not a type
definition mechanism.  Did I miss a proposal for such a mechanism?
If so, does it cover numeric literals?  Promotion rules?

If I define, for example, my own 96-bit unsigned integer type, how much
code do I have to write in C-with-overloading to make this legal?

    my_uint96 x = 42;
    x += 3;

[...]

>> The reasoning that operator overloading makes C more complex is wrong,
>> actually the opposite is the case. Adding specific types of numbers into
>> the language itself makes the implementations even *more* complex, and
>> forces decisions into the committee that should be actually left to the
>> users!
>
> I can see the problem you're trying to solve, but perhaps there's a
> better way than adding general operator overloads.

I can see the problem he's trying to solve, but operator overloading
alone doesn't solve it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58310

Le 17/03/2015 16:05, Keith Thompson a écrit :
> If I define, for example, my own 96-bit unsigned integer type, how much
> code do I have to write in C-with-overloading to make this legal?
>
>      my_uint96 x = 42;

You define the assignment operator with my_uint96 at the left side and 
int at the right side.

[toc] | [prev] | [next] | [standalone]

#58335

jacob navia <jacob@spamsink.net> writes:
> Le 17/03/2015 16:05, Keith Thompson a écrit :
>> If I define, for example, my own 96-bit unsigned integer type, how much
>> code do I have to write in C-with-overloading to make this legal?
>>
>>      my_uint96 x = 42;
>
> You define the assignment operator with my_uint96 at the left side and
> int at the right side.

So an overloaded assignment operator applies to initialization as well?
And presumably to argument passing and return statements?  That makes
sense, but I don't think you mentioned it (or I missed it).

Suppose an implementation of C+operator-overloading has a maximum size
of 64 bits for its predefined integer types.  Then I can't write:

    my_uint96 x = 79228162514264337593543950335; /* 2**96-1 */

unless there's a mechanism for user-defined literals.  I'm not saying
that's a fatal flaw, it's just an observation.

But you snipped a second line of code:

    x += 3;

Do we also have to explicitly overload "+" for a left operand of
type my_uint96 and a right operand of type int?

For existing types, mixed-type arithmetic depends heavily on implicit
conversions, with moderately complex rules for when they occur.
Can I define an implicit conversion from int to my_uint96, or vice
versa?  Can I define when that implicit conversion occurs?  Can I
define an *explicit* conversion by overloading the cast operator?

Without user-defined implicit conversions, I'd either have to
define overloaded operators for my_uint96 <op> <type> and <type>
<op> my_uint96, for each operator and each existing integer type.
That would quickly become unwieldy.  Or I'd have to ensure that
I don't mix my_uint96 with other types (which would require
user-defined explicit conversions).

Giving users the ability to define their own types that behave like
built-in integer types (and *maybe* redefining the predefined integer
types using the new mechanisms) would be a lot of work.  Defining the
rules consistently might be harder than implementing them.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#58350

Le 17/03/2015 19:09, Keith Thompson a écrit :
> Suppose an implementation of C+operator-overloading has a maximum size
> of 64 bits for its predefined integer types.  Then I can't write:
>
>      my_uint96 x = 79228162514264337593543950335; /* 2**96-1 */

There are two solutions for this problem.

1) the C++ solution.

       my_uint96 x = "79228162514264337593543950335"; /* 2**96-1 */

Then you write

my_uint96 operator=(my_uint96 &valueToAssign, char *str);

This solution doesn't work at the top level (global). That is why I 
think a better solution would be:

2) The solution I am planning is:
   1. You write a dll (or .so under linux/mac) that the compiler loads 
to read from a string into your type.
2) You figure out some unique SUFFIX to put after the number.

That would give

       my_uint96 x = 79228162514264337593543950335I96; /* 2**96-1 */

3) You associate both with

#pragma(suffix,my_uint96,"I96")

[toc] | [prev] | [next] | [standalone]

#58381

On Tue, 17 Mar 2015 21:37:47 +0100, jacob navia <jacob@spamsink.net>
wrote:

>Le 17/03/2015 19:09, Keith Thompson a écrit :
>> Suppose an implementation of C+operator-overloading has a maximum size
>> of 64 bits for its predefined integer types.  Then I can't write:
>>
>>      my_uint96 x = 79228162514264337593543950335; /* 2**96-1 */
>
>There are two solutions for this problem.
>
>1) the C++ solution.
>
>       my_uint96 x = "79228162514264337593543950335"; /* 2**96-1 */
>
>Then you write
>
>my_uint96 operator=(my_uint96 &valueToAssign, char *str);
>
>This solution doesn't work at the top level (global). That is why I 
>think a better solution would be:
>
>2) The solution I am planning is:
>   1. You write a dll (or .so under linux/mac) that the compiler loads 
>to read from a string into your type.
>2) You figure out some unique SUFFIX to put after the number.
>
>That would give
>
>       my_uint96 x = 79228162514264337593543950335I96; /* 2**96-1 */
>
>3) You associate both with
>
>#pragma(suffix,my_uint96,"I96")


In C++11 you can use a raw user defined literal, and define a suffix
operator for the type (in this case "_UI64") something like this:

my_uint96 operator"" _UI96(const char* str)
{
 // Code to cook str into a my_unit64
  return the_resulting_my_uint64;
}

(Note: C++11 requires that user defined literal suffixes start with an
underscore, this is a bit unfortunate, but I don't see it as being a
meaningful problem, although I believe C++14 has addressed that as
well).  And then code:

my_uint96 x = 79228162514264337593543950335_UI96; /* 2**96-1 */

The digits in the above are passed as the parameter to the conversion
function above.

This has the great advantage that you don't need to define some
external code to the compiler, which would be an immediate porting
nightmare.

The downside is that this will nominally generate runtime code, but
with some care you can make this work as a constexpr, which should get
fully computed at compile time, although that's not required.  You can
do some template metaprogramming to force the compile time evaluation
if you like (although that's the usual complex template ugliness).
Fortunately writing the literal conversion function/template is going
to have to happen only once for a type.  If the method selected does
create runtime code, one would hope that a smart compiler in most
cases would execute each literal conversion only once at program
startup, and then save the converted results for the actual
use/assignment while the program runs.

[toc] | [prev] | [next] | [standalone]

#58315

On 17/03/2015 15:05, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:

> If I define, for example, my own 96-bit unsigned integer type, how much
> code do I have to write in C-with-overloading to make this legal?
>
>      my_uint96 x = 42;
>      x += 3;

You will need an overload for "=" as Jacob suggested, and probably one 
for "+=", and possibly for each standard type: short, unsigned, double...

So it could get long-winded. Unless there was a way of specifying only 
int, and having short, float etc converted to that, if there wasn't 
aleady an overload directly involving short and float.

There was a reason, in my counter-proposal, to keep it simple! Then you 
would need to write:

  my_uint96 x = (my_uint)42;
  x += (my_uint96)3;

Although this now requires overloading the cast mechanism so that you 
can define the int => my_uint96 conversion in one place.

Also, for operators such as "=" and "+=", the left operand needs to be 
an lvalue. I think my proposal can deal with that, without having to 
bring & references into the language.

>> I can see the problem you're trying to solve, but perhaps there's a
>> better way than adding general operator overloads.
>
> I can see the problem he's trying to solve, but operator overloading
> alone doesn't solve it.

There are a considerable number of problems in allowing user-defined 
/numeric/ types to be added seamlessly into the language.

For example, literal representations of the new type, promotions and 
automatic casting between the new type and standard types, or between 
different user types, printing the new numeric types...

The idea of the overloading is mainly to be able to write "a+b" instead 
of "add(a,b)", which seems reasonable enough, without necessarily 
covering absolutely everything.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58309

On 16/03/2015 22:55, Bartc wrote:
> On 16/03/2015 21:55, jacob navia wrote:

>> The reasoning that operator overloading makes C more complex is wrong,
>> actually the opposite is the case. Adding specific types of numbers into
>> the language itself makes the implementations even *more* complex, and
>> forces decisions into the committee that should be actually left to the
>> users!
>
> I can see the problem you're trying to solve, but perhaps there's a
> better way than adding general operator overloads.

Here's what I believe is a simpler proposal that can achieve similar 
results: create a new compiler pragma that links an ordinary function to 
a built-in operator. It will of course need compiler support to make it 
work.

Example: first define a new type and add some conventional functions to 
deal with it:

typedef struct {
     char digits[32];
} dec_int;       // decimal integer

dec_int add_dec(dec_int a,dec_int b) {
    dec_int c;
    ...... // code to add two dec_ints
    return c;
}

Now this can be used like this:

dec_int a, b, c;

  a = add_dec(b, c);

This works now in standard C. The new bit is this pragma:

#pragma overload_operator "+" add_dec(dec_int,dec_int)dec_int;
#pragma overload_operator "+" ... other overloads for "+"
...

Now the compiler, when presented with "+" being used with two dec_int 
operands, will search that list, and add_dec, and convert:

    a = b + c;

to:

    a = add_dec(b, c);

For simplicity:

* These functions should take and return operands by value (no memory 
to worry about)

* There are no implicit casts to/from standard types; these must be 
inserted explicitly

* When searching for a suitable function candidate to match the types 
presented to "+", the matches must be exact (otherwise it becomes too 
difficult to do a 'closest' match).

This will probably achieve half the objectives of the original proposal. 
The functions used to implement the arithmetic can also already exist 
(in a library, etc, so the overloads can be superimposed on such a library).

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58256 — Re: What is "complexifying" C?

On 16 Mar 2015 22:56:27 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> jacob navia <jacob@spamsink.net> writes:
> >Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since
> >it proposes a SINGLE mechanism that would allow users to implement
> >their own number types without adding the enormous complexity of
> >integrating all those numbers into the compiler itself.
> 
>   When one writes operator overloading code such as 
>   (pseudocode with meaningless dummy implementations):
> 
> void -( _Complex x ){ x.re = -x.re; x.im = -x.im; return; }
> 
> void +( _Complex x ){ x.re = +x.re; x.im = +x.im; return; }
> 
>   one actually is writing a class (a user-defined type). One
>   could also write this with the following syntax (pseudocode):
> 
> class _Complex
> { void -(){ this.re = -this.re; this.im = -this.im; }
>   void +(){ this.re = +this.re; this.im = +this.im; }}
> 
>   . But the identity of the language C is defined by *not*
>   supporting classes, otherwise it would become C++ or
>   objective C, which both already exist.
> 

You are wrong. This is just syntactic sugar for ordinary function.
Only difference is that in case of named function no syntactic sugar
is involved. One particular thing on operator overloading is
name mangling that have to be done.
Allowing operator overloading, but not function overloading,
restricts name mangling only to operator functions, which is good.

[toc] | [prev] | [next] | [standalone]

#58258 — Re: What is "complexifying" C?

On 2015-03-16, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> jacob navia <jacob@spamsink.net> writes:
>>Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it 
>>proposes a SINGLE mechanism that would allow users to implement their 
>>own number types without adding the enormous complexity of integrating 
>>all those numbers into the compiler itself.
>
>   When one writes operator overloading code such as 
>   (pseudocode with meaningless dummy implementations):
>
> void -( _Complex x ){ x.re = -x.re; x.im = -x.im; return; }
>
> void +( _Complex x ){ x.re = +x.re; x.im = +x.im; return; }
>
>   one actually is writing a class (a user-defined type). One
>   could also write this with the following syntax (pseudocode):
>
> class _Complex
> { void -(){ this.re = -this.re; this.im = -this.im; }
>   void +(){ this.re = +this.re; this.im = +this.im; }}
>
>   . But the identity of the language C is defined by *not*
>   supporting classes, otherwise it would become C++ or
>   objective C, which both already exist.
>

Functional languages often allow operator overloading but I don't
suppose something like this would be inconceivable.

typedef struct {
	int x;
	int y;
	int z;
} vector;

vector overload+ (vector a, vector b) {
	vector c;
	c.x = a.x + b.x;
	c.y = a.y + b.y;
	c.z = a.z + b.z;

	return c;
}

Much as I like a clever use of operator overloading in C++ I dislike
their ability to be too clever.


-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58266

jacob navia wrote:
>
> The reasoning that operator overloading makes C more complex is wrong,
> actually the opposite is the case. Adding specific types of numbers into
> the language itself makes the implementations even *more* complex, and
> forces decisions into the committee that should be actually left to the
> users!

Anyone familiar with C++ and the mess C got into with complex numbers 
would certainly agree with you there!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#58288

In article <me7jgp$r9e$1@speranza.aioe.org>,
 jacob navia <jacob@spamsink.net> wrote:

> There are now following number types in C:
> 
> 1) char (signed and unsigned)
> 2) short (signed/unsigned)
> 3) int (signed/unsigned)
> 4) long (signed/unsigned)
> 5) long long (signed/unsigned)
> 
> That makes for 10 integer types
> 11) float
> 12) double
> 13) long double
> 14) float _Complex
> 15) double _Complex
> 16) long double _Complex
> 
> That makes for 16 different types of numbers. In advanced 
> standardization process we have
> 
> Decimal floats
> Fixed point numbers
> 
> We have many different types of floating extensions (with more 
> precision) or integer extensions (bignums) and a long list of possible 
> other types of numbers for different applications, like numbers defined 
> by an interval for easing error analysis, etc.
> 
> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it 
> proposes a SINGLE mechanism that would allow users to implement their 
> own number types without adding the enormous complexity of integrating 
> all those numbers into the compiler itself.
> 
> The reasoning that operator overloading makes C more complex is wrong, 
> actually the opposite is the case. Adding specific types of numbers into 
> the language itself makes the implementations even *more* complex, and 
> forces decisions into the committee that should be actually left to the 
> users!

Maybe I have a non-conforming compiler, but I have no problem with the 
following code without using operator overloading:

#include <stdio.h>
#include <stdlib.h>

long int add(long int a, long int b)
{
  return a+b;
}

int main(void)
{
  int a = 4;
  char b = 3;
  float result;

  result = add(a, b);
  printf("a+b=%f\n", result);
  return EXIT_SUCCESS;
}

Granted I'm not introducing my own type of numbers, but the standard 
promotion rules seem to cover most of the issues one might have when 
mixing types of numbers.

I've written my own set of routines for dealing with vectors, and I 
don't see how having operator overloading would have helped me much at 
all in implementing it. What operator would I overload for cross or dot 
product? What if I want to multiply a vector by the magnitude of another 
vector?

Equations written in the code end up being laid out vertically instead 
of horizontally, but it hasn't limited me in the least. (maybe it's my 
background with HP calculators and RPN. I tend to solve equations one 
operator at a time anyway.)

[toc] | [prev] | [next] | [standalone]

#58295

Le 17/03/2015 14:59, Mark Storkamp a écrit :
> I've written my own set of routines for dealing with vectors, and I
> don't see how having operator overloading would have helped me much at
> all in implementing it.

Of course not. Operator overloading is not suitable for that 
application. It is useful when you want to use new types of numbers, for 
instance when you want decimal floats, interval-defined numbers, fixed 
point numbers, etc.

[toc] | [prev] | [next] | [standalone]

#58304

On 17/03/2015 13:59, Mark Storkamp wrote:
> In article <me7jgp$r9e$1@speranza.aioe.org>,
>   jacob navia <jacob@spamsink.net> wrote:
>
>> There are now following number types in C:
>>
>> 1) char (signed and unsigned)
>> 2) short (signed/unsigned)
>> 3) int (signed/unsigned)
>> 4) long (signed/unsigned)
>> 5) long long (signed/unsigned)
>>
>> That makes for 10 integer types
>> 11) float
>> 12) double
>> 13) long double
>> 14) float _Complex
>> 15) double _Complex
>> 16) long double _Complex
>>
>> That makes for 16 different types of numbers. In advanced
>> standardization process we have
>>
>> Decimal floats
>> Fixed point numbers
>>
>> We have many different types of floating extensions (with more
>> precision) or integer extensions (bignums) and a long list of possible
>> other types of numbers for different applications, like numbers defined
>> by an interval for easing error analysis, etc.
>>
>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>> proposes a SINGLE mechanism that would allow users to implement their
>> own number types without adding the enormous complexity of integrating
>> all those numbers into the compiler itself.
>>
>> The reasoning that operator overloading makes C more complex is wrong,
>> actually the opposite is the case. Adding specific types of numbers into
>> the language itself makes the implementations even *more* complex, and
>> forces decisions into the committee that should be actually left to the
>> users!
>
> Maybe I have a non-conforming compiler, but I have no problem with the
> following code without using operator overloading:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> long int add(long int a, long int b)
> {
>    return a+b;
> }
>
> int main(void)
> {
>    int a = 4;
>    char b = 3;
>    float result;
>
>    result = add(a, b);
>    printf("a+b=%f\n", result);
>    return EXIT_SUCCESS;
> }
>
> Granted I'm not introducing my own type of numbers, but the standard
> promotion rules seem to cover most of the issues one might have when
> mixing types of numbers.
>
> I've written my own set of routines for dealing with vectors, and I
> don't see how having operator overloading would have helped me much at
> all in implementing it. What operator would I overload for cross or dot
> product? What if I want to multiply a vector by the magnitude of another
> vector?

You'd probably use "*" for both:

  p = q * r;
  p = q * magnitude(r);

(The cross-product function implementing "*" would need to return a 
vector by value.)

They do have uses, in the right language. But the way you did it 
probably looks natural for a language such as C, and it would look odd 
for it to deal easily with vectors when it can't yet do anything much 
with strings.

Similarly, it would look odd in a scripting language designed to work 
with 3D geometry, to have to write code like this:

vector p, q, r;
vector temp1, temp2;
char str[256];

vecproduct (&temp1, q, r);
addvector (&temp2, p, &temp1);
mulvector_by_scalar (&temp2, &temp2, 0.5);
vector_to_str (str, sizeof(str), &temp2);
printf("(p+q*r)/2 = %s\n");

instead of just:

println (p+q*r)/2

Sure, it would be nice to have in C, but this easy, informal style 
doesn't sit well with the rest of language.

It would also be opening a can of worms. There would also be loads of 
overloads needed to fully implement this, intermediate values to worry 
about, memory management ... that would need more ideas to be copied 
from C++ to mop all the untidy aspects.

It would be easier to just use C++ and do it properly.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web