Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #138493 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2018-12-04 12:17 +0000 |
| Last post | 2018-12-25 15:54 +0000 |
| Articles | 20 on this page of 140 — 29 participants |
Back to article view | Back to comp.lang.c
Big integers Bart <bc@freeuk.com> - 2018-12-04 12:17 +0000
Re: Big integers fir <profesor.fir@gmail.com> - 2018-12-04 05:58 -0800
Re: Big integers Chad <cdalten@gmail.com> - 2018-12-04 08:22 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-04 17:04 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-04 17:19 +0000
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-04 08:38 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-04 17:35 +0000
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-04 18:13 +0000
Re: Big integers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-04 10:50 -0800
Re: Big integers Rosario19 <Ros@invalid.invalid> - 2018-12-06 17:56 +0100
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-04 10:22 -0800
Re: Big integers Eli the Bearded <*@eli.users.panix.com> - 2018-12-04 18:58 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-04 11:32 -0800
Re: Big integers Eli the Bearded <*@eli.users.panix.com> - 2018-12-04 22:45 +0000
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-04 14:57 -0800
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-04 12:14 -0800
Re: Big integers chris.m.thomasson.1@gmail.com - 2018-12-04 16:58 -0800
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 03:14 +0000
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:27 -0800
Re: Big integers Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-04 20:03 -0500
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:25 -0800
Re: Big integers jacob navia <jacob@jacob.remcomp.fr> - 2018-12-04 23:45 +0100
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-04 23:29 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 00:30 +0000
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:28 -0800
Re: Big integers Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-12-05 17:50 +0000
Re: Big integers jacobnavia <jacob@jacob.remcomp.fr> - 2018-12-05 20:03 +0100
Re: Big integers Keith Thompson <kst-u@mib.org> - 2018-12-05 13:46 -0800
Re: Big integers jacobnavia <jacob@jacob.remcomp.fr> - 2018-12-06 06:41 +0100
Re: Big integers Keith Thompson <kst-u@mib.org> - 2018-12-05 22:40 -0800
Re: Big integers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-04 09:08 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-04 19:41 +0000
Re: Big integers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-04 12:00 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-08 11:28 +0000
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-05 15:19 +1300
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 11:58 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-05 14:35 +0100
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 14:35 +0000
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-05 07:39 -0800
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-05 07:45 -0800
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 17:51 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-05 22:19 +0100
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:55 -0800
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-05 15:19 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 16:13 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-06 09:35 +0100
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-07 14:26 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-07 19:56 -0800
Re: Big integers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-09 12:01 -0500
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-10 14:47 -0800
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 00:50 +0000
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-10 17:37 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-14 21:18 -0800
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-05 07:57 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 15:59 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 22:59 +0000
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-05 15:31 -0800
Re: Big integers Robert Wessel <robertwessel2@yahoo.com> - 2018-12-05 20:03 -0600
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-05 23:42 +0000
Re: Big integers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-05 20:15 -0500
Re: Big integers Ike Naar <ike@iceland.freeshell.org> - 2018-12-10 07:26 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 18:38 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-10 19:10 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 21:23 +0000
Re: Big integers Ike Naar <ike@iceland.freeshell.org> - 2018-12-10 22:47 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-05 22:15 +0100
Re: Big integers Bart <bc@freeuk.com> - 2018-12-06 13:43 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-06 07:50 -0800
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 15:19 +0000
Re: Big integers luser droog <luser.droog@gmail.com> - 2018-12-10 23:19 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-11 08:45 +0100
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-11 11:15 +0000
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-11 04:36 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-11 14:35 +0100
Re: Modules again (was: Big integers) Bart <bc@freeuk.com> - 2018-12-11 12:53 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 14:45 +0100
Re: Modules again Bart <bc@freeuk.com> - 2018-12-11 16:08 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:37 +0100
Re: Modules again Thiago Adams <thiago.adams@gmail.com> - 2018-12-11 08:59 -0800
Re: Modules again Bart <bc@freeuk.com> - 2018-12-11 17:49 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:44 +0100
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 18:02 +0000
Re: Modules again Thiago Adams <thiago.adams@gmail.com> - 2018-12-11 10:10 -0800
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 18:54 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 13:14 -0500
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 18:54 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 14:42 -0500
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:54 +0100
Re: Modules again Keith Thompson <kst-u@mib.org> - 2018-12-11 14:53 -0800
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-12 08:24 +0100
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:51 +0100
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 23:24 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 18:44 -0500
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 18:45 -0500
Re: Modules again Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-12 06:39 +0000
Re: Modules again James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-12 07:59 -0500
Re: Modules again mark.bluemel@gmail.com - 2018-12-12 05:43 -0800
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-12 14:20 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-12 17:10 +0100
Re: Modules again James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-12 13:39 -0800
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-12 14:19 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-12 10:28 -0500
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-06 08:10 +1300
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 20:57 +0000
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-06 10:16 +1300
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 23:15 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-05 23:44 +0000
Re: Big integers Robert Wessel <robertwessel2@yahoo.com> - 2018-12-05 02:51 -0600
Re: Big integers antispam@math.uni.wroc.pl - 2018-12-07 15:26 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-07 16:27 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-07 16:36 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-07 17:01 +0000
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-07 17:55 +0000
Re: Big integers antispam@math.uni.wroc.pl - 2018-12-07 19:26 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-07 21:39 +0000
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-08 10:51 +1300
Re: Big integers Anton Shepelev <anton.txt@gmail.com> - 2018-12-08 00:43 +0300
Re: Big integers Bart <bc@freeuk.com> - 2018-12-08 01:08 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-08 15:13 +0100
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-08 15:15 +0100
Re: Big integers Bart <bc@freeuk.com> - 2018-12-08 14:48 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-10 05:10 -0800
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-10 05:22 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-10 15:27 +0100
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-10 15:59 +0000
Re: Big integers antispam@math.uni.wroc.pl - 2018-12-11 21:14 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 14:56 +0000
Re: Big integers Ike Naar <ike@iceland.freeshell.org> - 2018-12-10 17:46 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 18:24 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-10 11:12 -0800
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-10 11:23 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 21:44 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-11 10:20 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-11 13:15 -0800
Re: Big integers Keith Thompson <kst-u@mib.org> - 2018-12-08 12:14 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-09 13:31 +0100
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-08 15:52 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-16 19:29 +0000
Re: Big integers "Tristan B. Kildaire" <deavmi@disroot.org> - 2018-12-25 12:59 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-25 15:54 +0000
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-12-10 07:26 +0000 |
| Message-ID | <slrn3u5kq0s592.3ac.ike@iceland.freeshell.org> |
| In reply to | #138563 |
On 2018-12-05, Bart <bc@freeuk.com> wrote: > On 05/12/2018 15:59, Bart wrote: >> On 05/12/2018 14:35, Bart wrote: >> >>> I think, because this seems to be a sore point, I will remove all such >>> controversial matters from the header. >>> >>> I might also change 'Bigint' to be an opaque pointer rather than a >>> struct (and possibly using only an array rather than struct+array). >> >> I've changed the types used completely. Updated sources via links in OP. >> No more stdint.h either (I never liked having to include that file). >> >> (Some more testing needed; > > I've made some tweaks, and tested on 100 random numbers and random > binary ops up to 10K digits, and 100,000 combinations up to 1K digits. > Comparisons were made with Python 3.4 using its built-in [binary] > arithmetic. > > However, I had to use only positive numbers, because Python gives weird > results when dividing negative ones (// is integer division): > > -10 // 20 is apparently -1, not 0. > -30 // 20 is 2, not 1 > You call the Python // operator 'integer division', but it's commonly called 'floor division', in other words: divide, then round down. Keeping that in mind, the result is not so weird.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-10 18:38 +0000 |
| Message-ID | <qoyPD.391860$6N5.196053@fx29.am4> |
| In reply to | #138634 |
On 10/12/2018 07:26, Ike Naar wrote: > On 2018-12-05, Bart <bc@freeuk.com> wrote: >> However, I had to use only positive numbers, because Python gives weird >> results when dividing negative ones (// is integer division): >> >> -10 // 20 is apparently -1, not 0. >> -30 // 20 is 2, not 1 (Actually, -2 rather than -1...) >> > > You call the Python // operator 'integer division', but it's commonly > called 'floor division', in other words: divide, then round down. > Keeping that in mind, the result is not so weird. > OK, so they decided to make the results of: -(30//20) and (-30//20) different, while the results of: -(30/20) and (-30/20) are exactly the same, as are the results of: -(Decimal(30)//Decimal(20)) and (-Decimal(30)//Decimal(20)) Not weird, inconsistent or confusing at all! Especially as the "//" operator in that last example is still the "floor division" operator.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-12-10 19:10 +0000 |
| Message-ID | <QSyPD.760096$SN2.54116@fx38.iad> |
| In reply to | #138647 |
Bart <bc@freeuk.com> writes:
>On 10/12/2018 07:26, Ike Naar wrote:
>> On 2018-12-05, Bart <bc@freeuk.com> wrote:
>
>>
>> You call the Python // operator 'integer division', but it's commonly
>> called 'floor division', in other words: divide, then round down.
>> Keeping that in mind, the result is not so weird.
>>
>
>OK, so they decided to make the results of:
>
> -(30//20) and (-30//20)
>
>different, while the results of:
>
> -(30/20) and (-30/20)
>
>are exactly the same, as are the results of:
>
> -(Decimal(30)//Decimal(20)) and (-Decimal(30)//Decimal(20))
>
>Not weird, inconsistent or confusing at all!
Your last statement is correct. They ('/' and '//') are two distinct operators
and shouldn't be expected to behave the same way. Therefore,
the only confusion is yours in conflating the two operators
in order to attempt to make a spurious point.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-10 21:23 +0000 |
| Message-ID | <iPAPD.526677$p%6.285822@fx26.am4> |
| In reply to | #138648 |
On 10/12/2018 19:10, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> OK, so they decided to make the results of:
>>
>> -(30//20) and (-30//20)
>>
>> different, while the results of:
>>
>> -(30/20) and (-30/20)
>>
>> are exactly the same, as are the results of:
>>
>> -(Decimal(30)//Decimal(20)) and (-Decimal(30)//Decimal(20))
>>
>> Not weird, inconsistent or confusing at all!
>
> Your last statement is correct. They ('/' and '//') are two distinct operators
> and shouldn't be expected to behave the same way. Therefore,
> the only confusion is yours in conflating the two operators
> in order to attempt to make a spurious point.
Look again. The first example and the last both use "//". But the first
rounds the results towards -infinity, the other towards zero:
from decimal import *
print(-30//20)
print(Decimal(-30)//Decimal(20)) # - can be outside too
This prints -2 and -1. Both use //; both divide minus thirty by twenty.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-12-10 22:47 +0000 |
| Message-ID | <slrn3kfoq0tr8n.iki.ike@iceland.freeshell.org> |
| In reply to | #138647 |
On 2018-12-10, Bart <bc@freeuk.com> wrote:
> On 10/12/2018 07:26, Ike Naar wrote:
>> On 2018-12-05, Bart <bc@freeuk.com> wrote:
>
>>> However, I had to use only positive numbers, because Python gives weird
>>> results when dividing negative ones (// is integer division):
>>>
>>> -10 // 20 is apparently -1, not 0.
>>> -30 // 20 is 2, not 1
>
> (Actually, -2 rather than -1...)
>>
>> You call the Python // operator 'integer division', but it's commonly
>> called 'floor division', in other words: divide, then round down.
>> Keeping that in mind, the result is not so weird.
>
> OK, so they decided to make the results of:
>
> -(30//20) and (-30//20)
>
> different, while the results of:
>
> -(30/20) and (-30/20)
>
> are exactly the same, as are the results of:
>
> -(Decimal(30)//Decimal(20)) and (-Decimal(30)//Decimal(20))
>
> Not weird, inconsistent or confusing at all!
>
> Especially as the "//" operator in that last example is still the "floor
> division" operator.
We're drifting off-topic (this is a newsgroup about C, not about Python),
but is seems unlikely that someone who has read the documentation of the
Python decimal package should be confused.
One should not confuse an operator acting on integers with an operator acting
on decimals, even if those operators have similar syntax.
From https://docs.python.org/3/library/decimal.html :
" There are some small differences between arithmetic on Decimal objects and arithmetic on integers and floats. When the remainder
operator % is applied to Decimal objects, the sign of the result is the sign of the dividend rather than the sign of the divisor:
>>> (-7) % 4
1
>>> Decimal(-7) % Decimal(4)
Decimal('-3')
The integer division operator // behaves analogously, returning the integer part of the true quotient (truncating towards zero) rather
than its floor, so as to preserve the usual identity x == (x // y) * y + x % y:
"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-05 22:15 +0100 |
| Message-ID | <pu9f58$gt0$1@dont-email.me> |
| In reply to | #138538 |
On 05/12/2018 15:35, Bart wrote:
> On 05/12/2018 13:35, David Brown wrote:
>> On 05/12/18 12:58, Bart wrote:
>
>>> You mean, /I/ shouldn't use int32 so that someone else can?
>>
>> You should not use "int32" in a /header/, in case other people want to
>> use it. What you do in the /implementation/ is up to you.
>>
>> To most of us, there is absolutely no point in having types like "int32"
>> as typedefs for "int32_t" - it is an entirely negative thing. It merely
>> introduces a non-standard name with no functionality, severing to
>> confuse, complicate and irritate. So /users/ of your library are not
>> remotely interested in having a type "int32" defined here.
>>
>> I realise that you think "int32_t" is so hideously ugly that you don't
>> want to use it in your own code, and prefer a typedef to "int32". I
>> can't say I can comprehend that attitude, but I can appreciate that this
>> is your opinion. So if you want to use "int32" in your implementation
>> code, go ahead. The emphasis in the C code should be what suits /you/
>> best, while the emphasis in the header file is what suits /others/ best.
>>
>> I would actually severely question the choice of types here altogether.
>
> I think, because this seems to be a sore point, I will remove all such
> controversial matters from the header.
Don't make changes because people here make complaints or suggestions.
/Read/ the complaints and suggestions, think about them, understanding
them, and then make an informed decision about what is best for the
software /you/ are writing. Obviously I think you should take my advice
and suggestions - but I want you to do it because you have understood
what I meant, and agree with me, and not just to shut me up!
>
> I might also change 'Bigint' to be an opaque pointer rather than a
> struct (and possibly using only an array rather than struct+array).
>
That is definitely something to consider. It is an unfortunate
limitation of C that some private information - such as the contents of
BigInt - need to be made visible in the header if you want local
allocation. When the details of the struct are in the header, users
might rely on them, making it more difficult to change the
implementation later. An opaque pointer type avoids that, but means
that everything has to be heap allocated in practice.
If you are doing that, you might want to have your BigInt something like:
typedef struct {
uint_least32_t dataAllocated;
uint_least32_t dataUsed;
bool minus;
uint_least32_t data[];
} BigInt;
That makes the data array a flexible array member. When you allocate a
new BigInt on the heap, add extra size to store the data. Keep track of
the allocated size in "dataAllocated" - then you know whether or not you
have space to grow a BigInt during a calculation. Typically you will
allocate with dataAllocated as 1 + 4*n, so that your resulting structure
is in 16-byte lumps - malloc() on x86 will generally give you memory
rounded up to 16-byte (or perhaps 32-byte) lumps.
This has the advantage that allocating and freeing a BigInt is just one
malloc and one free, avoiding the significant time and space overhead of
an extra allocation, and making freeing a BigInt as simple as calling
"free".
>> First, in any API you should strive to minimise extra functions.
>> "bn_print" is useful - "bn_println" is not.
>
> (My test programs only use the latter! However here, the most general
> function is 'bn_tostring'.)
>
>> You could also separate the count of the blocks allocated from the
>> number of digits used. This can make it easier to do in-place
>> operations (like "x += y") with fewer allocations and copies. And you
>> really want in-place operations for a library like this:
>>
>> a = bn_add(a, b);
>>
>> will be slow an leaky, while:
>>
>> bn_add_to(&a, b);
>>
>> would be faster and safe.
>>
>>
>> Finally, I would want a "small number optimisation" feature - a fixed
>> size of data, perhaps 4 uint32_t or a single uint64_t - within the
>> BigInt struct itself. Numbers that are small enough to be stored there
>> would be there, and be very much faster to use.
>
> Thanks for the comments.
>
> My own original requirement was for something to provide the underlying
> algorithms, and take care of all the fiddly work.
>
> Those other things can either be built on top, or if the library is
> simple enough, it can be adapted. For example:
>
> void bn_add_to(Bigint* pa, Bigint b){
> Bigint c;
> c = bn_add(*pa, b);
> bn_free(*pa);
> *pa = c;
> }
Of course that is possible. But generally a "bn_add_to" function can be
much more efficient than an "bn_add" function, with fewer memory
accesses and no allocation or free (except if you are very unlucky with
the carry). You then use the bn_add_to function to implement bn_add,
not the other way around.
>
> While in the language where this was originally used, you can write this:
>
> a +:= b # a, b both big integers
>
> even though the underlying add routine has a similar interface to bn_add.
>
> (Here, this isn't a true in-place addition. It is simulated like the
> bn_add_to example. One reason is that in this language when you do this:
>
> a := b
>
> a and b will share the same numeric data. You don't want subsequent
> in-place changes to a to be reflected in b.)
You need to be careful how you handle duplicates and references like
this. It is possible to use copy-on-write and other optimisations, but
then the code and interface gets more complex (and you'll wish you were
using C++ and not C).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-06 13:43 +0000 |
| Message-ID | <mI9OD.246677$2T2.235462@fx42.am4> |
| In reply to | #138532 |
On 05/12/2018 13:35, David Brown wrote: [big integer library optimisations] > Finally, I would want a "small number optimisation" feature - a fixed > size of data, perhaps 4 uint32_t or a single uint64_t - within the > BigInt struct itself. Numbers that are small enough to be stored there > would be there, and be very much faster to use. With the array-based representation now used, small-numbers (those with one wide 'digit' or one 'limb') don't need a special format. If the number of digits is 1, then that's your small number, in the range 0 to 1e9-1. (if you mean detecting numbers below 2**63, and storing them as signed 64-bit binary, then the conversions to and from decimal would be too expensive.) So, as it is, detecting two operands both with a single wide digit, and providing dedicated code, can be done fairly easily. But the other overheads are such that the benefit is small. (Allocating and deallocating bigints, and having a clunky function-based interface doesn't help here.) Here, perhaps basing it around an 'add_to' function, which can cut out some allocation, might help. But 'sub-to' is a little more awkward (the number can get smaller) and so are mul-to and div_to. Removing the 'memset' used to clear new allocations, not really needed, helped just as much. And using a small-object heap allocator in place of malloc() and free() helped a lot more. However this is not practical in such a self-contained library. There is only one call to malloc and one to free, so people can plug in their own allocators easily. What would really speed it up would be new algorithms...
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-12-06 07:50 -0800 |
| Message-ID | <360115e8-0b88-48ec-94ed-c4b99cc7a4ad@googlegroups.com> |
| In reply to | #138578 |
On Thursday, December 6, 2018 at 11:43:54 AM UTC-2, Bart wrote: > On 05/12/2018 13:35, David Brown wrote: > > > [big integer library optimisations] > > > Finally, I would want a "small number optimisation" feature - a fixed > > size of data, perhaps 4 uint32_t or a single uint64_t - within the > > BigInt struct itself. Numbers that are small enough to be stored there > > would be there, and be very much faster to use. > > With the array-based representation now used, small-numbers (those with > one wide 'digit' or one 'limb') don't need a special format. If the > number of digits is 1, then that's your small number, in the range 0 to > 1e9-1. > > (if you mean detecting numbers below 2**63, and storing them as signed > 64-bit binary, then the conversions to and from decimal would be too > expensive.) > > So, as it is, detecting two operands both with a single wide digit, and > providing dedicated code, can be done fairly easily. But the other > overheads are such that the benefit is small. (Allocating and > deallocating bigints, and having a clunky function-based interface > doesn't help here.) > > Here, perhaps basing it around an 'add_to' function, which can cut out > some allocation, might help. But 'sub-to' is a little more awkward (the > number can get smaller) and so are mul-to and div_to. > > Removing the 'memset' used to clear new allocations, not really needed, > helped just as much. > > And using a small-object heap allocator in place of malloc() and free() > helped a lot more. However this is not practical in such a > self-contained library. > > There is only one call to malloc and one to free, so people can plug in > their own allocators easily. > > What would really speed it up would be new algorithms... I think you need functions where you pass the memory. Maybe everything is on the stack. Maybe you have already checked you have enough memory.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-05 15:19 +0000 |
| Message-ID | <87o9a06lxq.fsf@bsb.me.uk> |
| In reply to | #138526 |
Bart <bc@freeuk.com> writes: > On 05/12/2018 02:19, Ian Collins wrote: >> On 05/12/2018 01:17, Bart wrote: > >>> * Keeps use of typedefs to a minimum (used to declare some aliases for >>> int32_t etc, and to make the one struct used, into a type) >> >> Looks tidy, but I would keep those aliases out of the header - the _t >> names were partly picked to minimise the risk of name clashes. > > You mean, /I/ shouldn't use int32 so that someone else can? Because C does not have definable name spaces, it's usual to prefix exposed identifiers in some way so as help users avoid clashes. You didn't define an extern called 'add' but bn_add and the same caution is advisable for types. Some libraries or modules even allow the prefix to be changed so that name clashes can always be avoided, but this is only practical when the code is not shared. And if you do need to expose a typedef name, it's often best to use a name that describes its abstract purpose rather than its bit width. On an unrelated matter, the functions extern Bigint bn_makeint (int64 a); extern int64 bn_int (Bigint a); should, logically, use intmax_t. There's not reason to insist on exactly 64 bits, 2's complement an no padding. You want to offer a conversion from the largest integer type available. > I will look at getting rid of both stdint.h and the typedefs, although > the use of 'long long int' and 'unsigned int' will make things much > less tidy. Why would you get rid of stdint.h? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2018-12-10 23:19 -0800 |
| Message-ID | <d74d25f4-17a3-49f7-a282-731052938415@googlegroups.com> |
| In reply to | #138541 |
On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse wrote: > Some libraries or modules even allow the prefix to be changed so that > name clashes can always be avoided, but this is only practical when the > code is not shared. > Wow! How do you do that?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-11 08:45 +0100 |
| Message-ID | <punpu7$vfo$1@dont-email.me> |
| In reply to | #138657 |
On 11/12/18 08:19, luser droog wrote: > On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse wrote: > >> Some libraries or modules even allow the prefix to be changed so that >> name clashes can always be avoided, but this is only practical when the >> code is not shared. >> > > Wow! How do you do that? > Macros, and stringification, I expect.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-11 11:15 +0000 |
| Message-ID | <87h8fkuxeg.fsf@bsb.me.uk> |
| In reply to | #138658 |
David Brown <david.brown@hesbynett.no> writes: > On 11/12/18 08:19, luser droog wrote: >> On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse wrote: >> >>> Some libraries or modules even allow the prefix to be changed so that >>> name clashes can always be avoided, but this is only practical when the >>> code is not shared. >> >> Wow! How do you do that? The simplest way is to declare everything using a macro #define MAKE_NAME(n) mylib ## _ ## n which the user of the code edits. It can be made a bit more automatic (so that it can be done without an edit) but it's dubious if it's worth the effort because it only works in rather limited situations and is needed in even fewer. > Macros, and stringification, I expect. Yes, though I would not use the term "stringification" because suggests using # which makes a string token from a macro argument. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-12-11 04:36 -0800 |
| Message-ID | <75fcb94b-8dbe-4168-999b-981857ae54c5@googlegroups.com> |
| In reply to | #138659 |
On Tuesday, December 11, 2018 at 11:16:00 AM UTC, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > > > On 11/12/18 08:19, luser droog wrote: > >> On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse wrote: > >> > >>> Some libraries or modules even allow the prefix to be changed so that > >>> name clashes can always be avoided, but this is only practical when the > >>> code is not shared. > >> > >> Wow! How do you do that? > > The simplest way is to declare everything using a macro > > #define MAKE_NAME(n) mylib ## _ ## n > > which the user of the code edits. It can be made a bit more automatic > (so that it can be done without an edit) but it's dubious if it's worth > the effort because it only works in rather limited situations and is > needed in even fewer. > > > Macros, and stringification, I expect. > > Yes, though I would not use the term "stringification" because suggests > using # which makes a string token from a macro argument. > So C namespaces are better than C++. Changing a C++ namespace name requires going through the code and changing every "namespace" and "using namespace" declaration.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-11 14:35 +0100 |
| Message-ID | <puoef7$kdi$1@dont-email.me> |
| In reply to | #138660 |
On 11/12/18 13:36, Malcolm McLean wrote:
> On Tuesday, December 11, 2018 at 11:16:00 AM UTC, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 11/12/18 08:19, luser droog wrote:
>>>> On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse wrote:
>>>>
>>>>> Some libraries or modules even allow the prefix to be changed so that
>>>>> name clashes can always be avoided, but this is only practical when the
>>>>> code is not shared.
>>>>
>>>> Wow! How do you do that?
>>
>> The simplest way is to declare everything using a macro
>>
>> #define MAKE_NAME(n) mylib ## _ ## n
>>
>> which the user of the code edits. It can be made a bit more automatic
>> (so that it can be done without an edit) but it's dubious if it's worth
>> the effort because it only works in rather limited situations and is
>> needed in even fewer.
I would guess it is common to make the "mylib" part a macro too, defined
from the command line. So if you have have a library for big integers,
you might have something like:
#ifndef BI_PREFIX
#error You need to specify BI_PREFIX on the command line!
#endif
#define BI_(n) BI_PREFIX ## _ ## n
typedef struct { ... } BI_(bigint);
extern int BI_(add)(BI_(bigint) * x,
const BI_(bigint) * a, cont BI_(bigint) * b);
and so on.
Then you compile with "gcc -DBI_PREFIX=bi" or something similar. That
way you don't need to change the code at all to get a different prefix.
Yes, it's a little ugly - but you'd only use it if you really needed it,
and it's only the external names that need this. In the implementation,
you can use normal static names.
>>
>>> Macros, and stringification, I expect.
>>
>> Yes, though I would not use the term "stringification" because suggests
>> using # which makes a string token from a macro argument.
>>
> So C namespaces are better than C++.
> Changing a C++ namespace name requires going through the code and changing
> every "namespace" and "using namespace" declaration.
>
If you need the same flexibility in a C++ program, you can use macros
for the namespace names too.
But since you can use "using" for namespaces in C++, you can use longer
names without the ugliness and verbosity of long prefixes in C names,
and thus you have little chance of conflict. A prefix of "bi_" in C has
a serious risk of conflicting with other libraries or code - a C++
namespace of "barts_bigint_lib" is more likely to be unique.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-11 12:53 +0000 |
| Subject | Re: Modules again (was: Big integers) |
| Message-ID | <jrOPD.613862$aX1.44917@fx21.am4> |
| In reply to | #138659 |
On 11/12/2018 11:15, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 11/12/18 08:19, luser droog wrote:
>>> On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse wrote:
>>>
>>>> Some libraries or modules even allow the prefix to be changed so that
>>>> name clashes can always be avoided, but this is only practical when the
>>>> code is not shared.
>>>
>>> Wow! How do you do that?
>
> The simplest way is to declare everything using a macro
>
> #define MAKE_NAME(n) mylib ## _ ## n
>
> which the user of the code edits.
So, to use this method inside a library that exports functions f, g, h,
every use of those functions must be written as MAKENAME(f) etc? That
must really help the readability of the code:
if (MAKENAME(f)(MAKENAME(g)+1))==0) ...
Especially when applied also to types:
MAKENAME(int32) MAKENAME(F)(MAKENAME(float32) {
MAKENAME(int32) result;
....
The MAKENAME macro itself has to be kept private as it could clash with
MAKENAME used from other libraries (writing MAKENAME(MAKENAME)(f) is not
practical!).
And, as functions within the library change between static and
non-static, that MAKENAME must be added and removed.
With the modules that use that library, if the library is A.h/A.c but
they want the prefix to be b_, then they set 'mylib' to 'b', and
functions are then called as 'b_f()'. They just need to be aware of any
other entities that happen to have the unadorned name 'b_f'.
---------------------------
I looked briefly at how it works in my language (as I rarely make use of
the namespace feature), and this stuff just works effortlessly.
One module can export functions f,g,h, and so can another, and they
don't clash (examples snipped).
Yet C is the language that has world-wide dominance.
It's a funny world.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-11 14:45 +0100 |
| Subject | Re: Modules again |
| Message-ID | <puof1p$o4h$1@dont-email.me> |
| In reply to | #138661 |
On 11/12/18 13:53, Bart wrote:
> On 11/12/2018 11:15, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 11/12/18 08:19, luser droog wrote:
>>>> On Wednesday, December 5, 2018 at 9:19:24 AM UTC-6, Ben Bacarisse
>>>> wrote:
>>>>
>>>>> Some libraries or modules even allow the prefix to be changed so that
>>>>> name clashes can always be avoided, but this is only practical when
>>>>> the
>>>>> code is not shared.
>>>>
>>>> Wow! How do you do that?
>>
>> The simplest way is to declare everything using a macro
>>
>> #define MAKE_NAME(n) mylib ## _ ## n
>>
>> which the user of the code edits.
>
> So, to use this method inside a library that exports functions f, g, h,
> every use of those functions must be written as MAKENAME(f) etc? That
> must really help the readability of the code:
>
> if (MAKENAME(f)(MAKENAME(g)+1))==0) ...
>
You use local typedefs or macros inside the implementation in order to
make code more readable. You need the non-conflicting prefixes in the
header, and in the actual name of the exported functions, but not in the
internal names. So your implementation might have:
#define bi_f MAKENAME(f)
#define bi_g MAKENAME(g)
if (bi_f(bi_g + 1) == 0) ...
And you are back to exactly the same readability as before.
Static functions and variables, as well as types defined in the
implementation files, don't need any kind of unique names.
> Especially when applied also to types:
>
> MAKENAME(int32) MAKENAME(F)(MAKENAME(float32) {
> MAKENAME(int32) result;
> ....
>
> The MAKENAME macro itself has to be kept private as it could clash with
> MAKENAME used from other libraries (writing MAKENAME(MAKENAME)(f) is not
> practical!).
>
Use a sensible name appropriate to the library - but long enough to be
likely to be unique.
> And, as functions within the library change between static and
> non-static, that MAKENAME must be added and removed.
>
So don't do that. Design your library, and think about what should be
exported or not.
But the recommendation I gave above about local #define's for the names
avoids the problem anyway.
> With the modules that use that library, if the library is A.h/A.c but
> they want the prefix to be b_, then they set 'mylib' to 'b', and
> functions are then called as 'b_f()'. They just need to be aware of any
> other entities that happen to have the unadorned name 'b_f'.
>
Yes.
> ---------------------------
>
> I looked briefly at how it works in my language (as I rarely make use of
> the namespace feature), and this stuff just works effortlessly.
>
Namespaces, as found in C++, are a better solution than prefixes for
exported functions. I would like namespaces to be added to C. And I
would expect any large newer language to support a similar concept.
But configurable prefixes like this are rarely used and (as Ben said)
even more rarely needed. Someone wanted to know how they could be
implemented, so we are telling them - no one is suggesting it is a
particularly elegant idea.
> One module can export functions f,g,h, and so can another, and they
> don't clash (examples snipped).
>
> Yet C is the language that has world-wide dominance.
Yes, but I think it is despite a lack of namespaces, rather than because
of it.
>
> It's a funny world.
>
It is conceivable that there are other more important differences
between your language and C, that outweigh the advantages of your
namespaces.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-11 16:08 +0000 |
| Subject | Re: Modules again |
| Message-ID | <8iRPD.272385$xH4.268753@fx33.am4> |
| In reply to | #138663 |
On 11/12/2018 13:45, David Brown wrote:
> On 11/12/18 13:53, Bart wrote:
>> So, to use this method inside a library that exports functions f, g, h,
>> every use of those functions must be written as MAKENAME(f) etc? That
>> must really help the readability of the code:
>>
>> if (MAKENAME(f)(MAKENAME(g)+1))==0) ...
>>
>
> You use local typedefs or macros inside the implementation in order to
> make code more readable. You need the non-conflicting prefixes in the
> header, and in the actual name of the exported functions, but not in the
> internal names. So your implementation might have:
>
> #define bi_f MAKENAME(f)
> #define bi_g MAKENAME(g)
>
> if (bi_f(bi_g + 1) == 0) ...
>
> And you are back to exactly the same readability as before.
At some cost though if you need a macro for every function. And this is
inside the library so that you are hard-coding the prefix for hundreds
of functions.
>> And, as functions within the library change between static and
>> non-static, that MAKENAME must be added and removed.
>>
>
> So don't do that. Design your library, and think about what should be
> exported or not.
Software develops, things change, functions that are used locally may
turn out to need to be exported, etc.
And if the library comprises several modules, those local functions will
nevertheless have global names that could clash with exports elsewhere.
> It is conceivable that there are other more important differences
> between your language and C, that outweigh the advantages of your
> namespaces.
I don't even directly use my namespaces. If there are multiple exports
of "abc", but only one is visible in any one module, then I just write
"abc". I don't need to write "lib.abc" unless I have to disambiguate,
which is rare.
Actually I use the advantages without being aware of them: I loosely
coupled two separate programs into one executable. Each program exported
some function/variable/type names used in both (as I tend to use the
same names for certain things). Yet most did not clash, because the
modules were separate.
In another program, there is a group of modules doing one task (a code
generator for x64) and another group of modules doing a similar task (a
code generator for C); both have the same framework with the same
function names, which have to be exported to each other. No prefixes are
used nor qualified names.
But no clashes; only the entry points visible to the rest of the
programs have to be unique.
These are names within the same executable unit (.exe or dll), where the
actual exported symbol names need to be 'decorated' (in a simple manner
not crazily like C++).
But it is possible, with dynamic libraries, to have 'global' names that
are identical. I haven't done this fully yet, but I think it is possible
to have, say, two versions of printf from two libraries, called from the
same program:
lib1.printf("hello ...")
lib2.printf("world") # probably using different stdout handles
In both cases they will export "printf".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-11 21:37 +0100 |
| Subject | Re: Modules again |
| Message-ID | <pup773$r5s$1@dont-email.me> |
| In reply to | #138664 |
On 11/12/2018 17:08, Bart wrote: > On 11/12/2018 13:45, David Brown wrote: >> On 11/12/18 13:53, Bart wrote: > >>> So, to use this method inside a library that exports functions f, g, h, >>> every use of those functions must be written as MAKENAME(f) etc? That >>> must really help the readability of the code: >>> >>> if (MAKENAME(f)(MAKENAME(g)+1))==0) ... >>> >> >> You use local typedefs or macros inside the implementation in order to >> make code more readable. You need the non-conflicting prefixes in the >> header, and in the actual name of the exported functions, but not in the >> internal names. So your implementation might have: >> >> #define bi_f MAKENAME(f) >> #define bi_g MAKENAME(g) >> >> if (bi_f(bi_g + 1) == 0) ... >> >> And you are back to exactly the same readability as before. > > At some cost though if you need a macro for every function. And this is > inside the library so that you are hard-coding the prefix for hundreds > of functions. > Yes, it is some cost - but not a big cost. And remember that this is only if you find it more convenient to use such short-cut definitions, and also only if you are writing a library with this kind of configurable prefix in the first place. And for those that think it is too much effort writing such definitions, it would not be difficult to write a little script that reads the "normal" C file and generates these lines of #define automatically. I am not suggesting that the whole shebang is nice or elegant - merely that it can be done like this if you want configurable library prefixes without making the main implementation code unreadable. Proper namespace support in the language would make it all unnecessary. >>> And, as functions within the library change between static and >>> non-static, that MAKENAME must be added and removed. >>> >> >> So don't do that. Design your library, and think about what should be >> exported or not. > > Software develops, things change, functions that are used locally may > turn out to need to be exported, etc. > > And if the library comprises several modules, those local functions will > nevertheless have global names that could clash with exports elsewhere. > Yes, that is certainly a factor.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-12-11 08:59 -0800 |
| Subject | Re: Modules again |
| Message-ID | <281140f7-42ee-4b11-a93c-042970e5f942@googlegroups.com> |
| In reply to | #138663 |
On Tuesday, December 11, 2018 at 11:45:38 AM UTC-2, David Brown wrote: ... > Namespaces, as found in C++, are a better solution than prefixes for > exported functions. I would like namespaces to be added to C. And I > would expect any large newer language to support a similar concept. To include namespace, I think you must include name mangling. If you bring name mangling you can bring function overloading. If you bring function overloading you can bring... ... One alternative would be to have some predefined name mangling like add "namespace_" as suffix.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-11 17:49 +0000 |
| Subject | Re: Modules again |
| Message-ID | <OMSPD.272386$xH4.153825@fx33.am4> |
| In reply to | #138665 |
On 11/12/2018 16:59, Thiago Adams wrote: > On Tuesday, December 11, 2018 at 11:45:38 AM UTC-2, David Brown wrote: > ... >> Namespaces, as found in C++, are a better solution than prefixes for >> exported functions. I would like namespaces to be added to C. And I >> would expect any large newer language to support a similar concept. > > To include namespace, I think you must include name mangling. > If you bring name mangling you can bring function overloading. No. You can have one without the other. BTW I'm not proposing adding anything to C any more. It's not really practical. I was showing earlier how such problems /can/ be solved fairly easily within a language in a way that needs little intervention in source code that stays readable. (Although that doesn't resolve all issues: if a global name is 'mangled' using the name of the module (eg its file name), then a change of module name would mean recompiling the source of any dependencies. And cross-language references become harder because the scheme used has to be known to the other language.)
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web