Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #151935 > unrolled thread
| Started by | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| First post | 2020-05-01 22:19 -0700 |
| Last post | 2020-05-18 13:25 +1200 |
| Articles | 20 on this page of 188 — 19 participants |
Back to article view | Back to comp.lang.c
pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-01 22:19 -0700
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 01:24 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 01:56 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 02:06 -0700
Re: pure C90 environment shi84516584@gmail.com - 2020-05-19 17:53 -0700
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 02:07 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 02:23 -0700
Re: pure C90 environment shi84516584@gmail.com - 2020-05-19 17:55 -0700
Re: pure C90 environment Philipp Klaus Krause <pkk@spth.de> - 2020-05-02 11:05 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 02:14 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-03 22:33 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-03 16:18 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-04 00:35 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-03 17:54 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-03 18:38 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-03 18:51 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-04 09:36 +0200
Re: pure C90 environment James Harris <james.harris.1@gmail.com> - 2020-05-04 08:48 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 01:12 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-04 15:16 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 06:21 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-04 15:40 +0200
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-04 07:12 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 14:47 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 07:08 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 08:12 -0700
Re: pure C90 environment BGB <cr88192@gmail.com> - 2020-05-05 11:36 -0500
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 11:25 -0400
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 11:39 -0400
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-19 08:45 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 17:43 +0200
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 12:35 -0400
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 20:14 +0200
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 14:42 -0400
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 12:11 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 21:46 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 13:11 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-19 14:39 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-19 13:24 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-20 09:26 +0200
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 21:11 +0000
Re: pure C90 environment James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-19 18:51 -0400
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 23:26 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-20 09:33 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 11:49 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 04:00 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 17:58 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-04 10:18 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-04 13:57 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 12:11 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 11:26 +0100
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 13:06 +0200
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-02 04:26 -0700
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 04:53 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 16:21 +0200
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-02 11:20 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 16:20 +0200
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-02 07:33 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 16:35 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 17:30 +0100
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 18:37 +0200
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 18:18 +0100
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 19:25 +0200
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-02 19:25 +0200
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-02 22:45 +0100
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 23:29 +0100
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-03 03:55 +0100
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-03 13:07 +0100
Re: pure C90 environment fir <profesor.fir@gmail.com> - 2020-05-03 05:24 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-03 05:26 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-03 14:27 +0100
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-03 22:38 +0100
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-03 22:06 +0100
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-04 00:28 +0100
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-03 02:16 -0700
Re: pure C90 environment Öö Tiib <ootiib@hot.ee> - 2020-05-03 16:23 -0700
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-04 16:41 +0200
Re: pure C90 environment Bonita Montero <Bonita.Montero@gmail.com> - 2020-05-04 16:59 +0200
Re: pure C90 environment Öö Tiib <ootiib@hot.ee> - 2020-05-04 11:01 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-02 11:13 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 03:53 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 05:14 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 06:30 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-02 12:49 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-13 03:01 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-13 14:43 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 06:30 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 05:41 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-17 13:02 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-17 22:47 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 14:03 -0700
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-18 08:54 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 06:11 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-18 06:51 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 07:12 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-18 15:47 +0100
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-18 16:25 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 07:41 -0700
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-18 17:32 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-18 17:09 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 08:52 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-18 17:05 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 09:18 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:55 +0000
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-19 01:42 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 20:35 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:12 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 10:02 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 17:42 +0000
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 18:16 +0100
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:00 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 05:09 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 15:20 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 08:18 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 17:58 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 10:45 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 19:31 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 11:58 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-19 20:44 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 13:03 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 22:34 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 15:41 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 00:03 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 16:10 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 01:46 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 22:49 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 11:26 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 04:43 -0700
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-19 16:40 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 23:11 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 11:40 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 05:48 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 06:19 -0700
Re: pure C90 environment Bart <bc@freeuk.com> - 2020-05-20 16:38 +0100
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 09:15 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 09:37 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 10:43 -0700
Re: pure C90 environment Öö Tiib <ootiib@hot.ee> - 2020-05-20 10:58 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 11:36 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-20 12:37 -0700
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 17:43 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 17:58 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 18:03 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 18:29 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 19:54 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 20:01 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 20:04 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-10 21:07 -0800
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-03-10 23:10 -0800
Re: pure C90 environment "muta...@gmail.com" <mutazilah@gmail.com> - 2021-03-11 01:21 -0800
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2021-03-11 15:26 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 17:18 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-19 09:52 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 17:39 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:17 +0000
Re: pure C90 environment Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-05-19 22:54 +0100
Re: pure C90 environment Ian Collins <ian-news@hotmail.com> - 2020-05-20 10:17 +1200
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-19 16:28 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 17:30 +0200
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-19 19:39 +0200
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 15:12 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:51 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 13:02 -0700
Re: pure C90 environment Manfred <noname@add.invalid> - 2020-05-18 15:52 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-18 17:15 +0200
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 20:10 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 13:18 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 23:21 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:21 +0200
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:12 +0200
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:21 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:48 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 19:47 +0000
Re: pure C90 environment David Brown <david.brown@hesbynett.no> - 2020-05-19 13:23 +0200
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 13:54 -0700
Re: pure C90 environment Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-05-17 16:45 -0700
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-17 17:27 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 14:44 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 08:17 -0700
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-18 21:39 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 21:58 +0000
Re: pure C90 environment Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-18 16:40 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 00:22 +0000
Re: pure C90 environment antispam@math.uni.wroc.pl - 2020-05-19 00:27 +0000
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-19 16:10 +0000
Re: pure C90 environment Paul Edwards <mutazilah@gmail.com> - 2020-05-18 14:59 -0700
Re: pure C90 environment scott@slp53.sl.home (Scott Lurndal) - 2020-05-18 20:01 +0000
Re: pure C90 environment Ian Collins <ian-news@hotmail.com> - 2020-05-18 13:25 +1200
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-05-02 18:37 +0200 |
| Message-ID | <r8k7ki$ji3$1@news.albasani.net> |
| In reply to | #151958 |
Am 02.05.2020 um 18:30 schrieb Bart: > [Off the topic of pure C90] > > On 02/05/2020 15:20, Bonita Montero wrote: >>> How expressive and how simple. >> >> Simplicity mostly contraticts expressiveness. > > Remember the strrepl thread? My scripting solution can be expressed like > this: > > function strrepl(s, old, new)= > t := "" > while n:=old in s do > t +:= s[1..n-1] + new > s := s[n+old.len..$] > od > return t+s > end > > Far more elegant than any of your C++ versions, with fewer dependencies, > /and/ it was faster. Plus build time is essentially zero. The performance largely depends on the operations in your language runtime and not in the language itself. Your language is built wich a lowlevel-language like C or a mixed language like C++ for sure, so there's no cause to assume it could be faster than any C / C++ -solutiuon. I've just got across an algorithm called "optimal mismatch", which is in fact the fastest string-search-algorithm. With this nothting from your language-runtime would help you to implement an as fast version. Scripting languages are slow when their code doesn't depend on the runtime-functions.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-05-02 18:18 +0100 |
| Message-ID | <XXhrG.101561$TB.14255@fx16.am4> |
| In reply to | #151959 |
On 02/05/2020 17:37, Bonita Montero wrote: > Am 02.05.2020 um 18:30 schrieb Bart: >> [Off the topic of pure C90] >> >> On 02/05/2020 15:20, Bonita Montero wrote: >>>> How expressive and how simple. >>> >>> Simplicity mostly contraticts expressiveness. >> >> Remember the strrepl thread? My scripting solution can be expressed >> like this: >> >> function strrepl(s, old, new)= >> t := "" >> while n:=old in s do >> t +:= s[1..n-1] + new >> s := s[n+old.len..$] >> od >> return t+s >> end >> >> Far more elegant than any of your C++ versions, with fewer >> dependencies, /and/ it was faster. Plus build time is essentially zero. > > The performance largely depends on the operations in your language > runtime and not in the language itself. Your language is built wich > a lowlevel-language like C or a mixed language like C++ for sure, > so there's no cause to assume it could be faster than any C / C++ > -solutiuon. > I've just got across an algorithm called "optimal mismatch", which > is in fact the fastest string-search-algorithm. With this nothting > from your language-runtime would help you to implement an as fast > version. Scripting languages are slow when their code doesn't depend > on the runtime-functions. Putting aside performance (I had been surprised this example competed with C and C++) you said that simplicity constradicts expressiveness. It doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-05-02 19:25 +0200 |
| Message-ID | <r8kadh$cqj$1@news.albasani.net> |
| In reply to | #151960 |
> Putting aside performance (I had been surprised this example competed > with C and C++) you said that simplicity constradicts expressiveness. Yes, mostly, especially if you get expressiveness in a flexible favour like in C++.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-05-02 19:25 +0200 |
| Message-ID | <r8kae8$cqj$2@news.albasani.net> |
| In reply to | #151960 |
> Putting aside performance (I had been surprised this example competed > with C and C++) you said that simplicity constradicts expressiveness. Yes, mostly, especially if you get expressiveness in a flexible flavour like in C++.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-05-02 22:45 +0100 |
| Message-ID | <87r1w23t9p.fsf@bsb.me.uk> |
| In reply to | #151958 |
Bart <bc@freeuk.com> writes:
> [Off the topic of pure C90]
>
> On 02/05/2020 15:20, Bonita Montero wrote:
>>> How expressive and how simple.
>>
>> Simplicity mostly contraticts expressiveness.
>
> Remember the strrepl thread? My scripting solution can be expressed like this:
>
> function strrepl(s, old, new)=
> t := ""
> while n:=old in s do
> t +:= s[1..n-1] + new
> s := s[n+old.len..$]
> od
> return t+s
> end
This can be written in C++ like this:
using std::string;
string replace(const string &str, const string &pat, const string &rep)
{
string result;
string::size_type pos = 0, start;
while ((start = str.find(pat, pos)) != string::npos) {
result += str.substr(pos, start - pos) + rep;
pos = start + pat.length();
}
return result + str.substr(pos);
}
It need not be as complicated as some of the posted code.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-05-02 23:29 +0100 |
| Message-ID | <fvmrG.240019$dx4.196112@fx05.am4> |
| In reply to | #151972 |
On 02/05/2020 22:45, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> [Off the topic of pure C90]
>>
>> On 02/05/2020 15:20, Bonita Montero wrote:
>>>> How expressive and how simple.
>>>
>>> Simplicity mostly contraticts expressiveness.
>>
>> Remember the strrepl thread? My scripting solution can be expressed like this:
>>
>> function strrepl(s, old, new)=
>> t := ""
>> while n:=old in s do
>> t +:= s[1..n-1] + new
>> s := s[n+old.len..$]
>> od
>> return t+s
>> end
>
> This can be written in C++ like this:
>
> using std::string;
>
> string replace(const string &str, const string &pat, const string &rep)
> {
> string result;
> string::size_type pos = 0, start;
> while ((start = str.find(pat, pos)) != string::npos) {
> result += str.substr(pos, start - pos) + rep;
> pos = start + pat.length();
> }
> return result + str.substr(pos);
> }
>
> It need not be as complicated as some of the posted code.
>
That's not too bad. Certainly it is smaller and simpler than anything I
remember Bonita posting.
Yet, it's not quite as clean as the dynamic code, and I had some fun
trying to figure out how to pass such a string to fwrite.
(Also, on a machine which doesn't support the SSE ops needed for fast
string search, it was still 25% slower than my interpreter running that
script.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-05-03 03:55 +0100 |
| Message-ID | <87lfm94til.fsf@bsb.me.uk> |
| In reply to | #151973 |
Bart <bc@freeuk.com> writes:
> On 02/05/2020 22:45, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> [Off the topic of pure C90]
>>>
>>> On 02/05/2020 15:20, Bonita Montero wrote:
>>>>> How expressive and how simple.
>>>>
>>>> Simplicity mostly contraticts expressiveness.
>>>
>>> Remember the strrepl thread? My scripting solution can be expressed like this:
>>>
>>> function strrepl(s, old, new)=
>>> t := ""
>>> while n:=old in s do
>>> t +:= s[1..n-1] + new
>>> s := s[n+old.len..$]
>>> od
>>> return t+s
>>> end
>>
>> This can be written in C++ like this:
>>
>> using std::string;
>>
>> string replace(const string &str, const string &pat, const string &rep)
>> {
>> string result;
>> string::size_type pos = 0, start;
>> while ((start = str.find(pat, pos)) != string::npos) {
>> result += str.substr(pos, start - pos) + rep;
>> pos = start + pat.length();
>> }
>> return result + str.substr(pos);
>> }
>>
>> It need not be as complicated as some of the posted code.
>>
>
> That's not too bad. Certainly it is smaller and simpler than anything
> I remember Bonita posting.
>
> Yet, it's not quite as clean as the dynamic code,
Your code appears to have some string operations built-in. It's even
simpler written in a language that has lots of string operations
built-in. In Perl it's just
s/$old/$new/g
> and I had some fun trying to figure out how to pass such a string to
> fwrite.
Well, it's an odd thing to do, so I am not surprised by that.
> (Also, on a machine which doesn't support the SSE ops needed for fast
> string search, it was still 25% slower than my interpreter running
> that script.)
All the "simple" versions posted are little more then drivers for the
underlying operations of string searching and copying. On my system,
your code is slow simply because the "in" operator is not implemented as
well as it could be for that target. And my C version is slow on your
system because strstr is not well implemented in the C implementation
you use. On my machine, the C++ code is slower than the C code but
faster than yours. All that does is reflect the implementation of the
underlying operations.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-05-03 13:07 +0100 |
| Message-ID | <kuyrG.215050$MU3.101940@fx38.am4> |
| In reply to | #151974 |
On 03/05/2020 03:55, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Yet, it's not quite as clean as the dynamic code,
>
> Your code appears to have some string operations built-in.
This one of my gripes against C++, because it provides a complex toolkit
for adding such operations instead of just providing them. The result is
a very difficult language, and 'built-in' features that are very
cumbersome to use.
It's even
> simpler written in a language that has lots of string operations
> built-in. In Perl it's just
>
> s/$old/$new/g
It's not quite that simple. 12,000 files and 500MB later, I found I
needed to do this:
$newtext = $text;
$newtext =~ s/lived/LIVEDFOREVER/g;
Like that, it was still somewhat slower than my interpreter
(Fastest times this morning for 100 iterations of the test input were
2.48 seconds Perl, 2.15 seconds for my interpreter, where it is /not/
built-in, requiring more bytecode to be executed.)
>> and I had some fun trying to figure out how to pass such a string to
>> fwrite.
>
> Well, it's an odd thing to do, so I am not surprised by that.
Part of the task is the write the result to a file (and not by the crude
way of writing to a console and capturing the output, mixed up with any
messages such as timing results). The original used fwrite. Maybe there
is a way of directly writing a 'string' object to a file, but I didn't
know what that was either.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-05-03 05:24 -0700 |
| Message-ID | <fa0576a9-5d34-414b-814f-0cf17194b97f@googlegroups.com> |
| In reply to | #151976 |
W dniu niedziela, 3 maja 2020 14:07:55 UTC+2 użytkownik Bart napisał: > On 03/05/2020 03:55, Ben Bacarisse wrote: > > Bart <bc@freeuk.com> writes: > > >> Yet, it's not quite as clean as the dynamic code, > > > > Your code appears to have some string operations built-in. > > This one of my gripes against C++, because it provides a complex toolkit > for adding such operations instead of just providing them. The result is > a very difficult language, and 'built-in' features that are very > cumbersome to use. > kinda funny this 'feature' of c++ of abilioty to 'selfdefine' a language inside of it is probably the main and only good point in it hovever it was obviously done bad but generally its interesting kind of feature (once i already was writing this, maybe in some future i will write more)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-05-03 05:26 -0700 |
| Message-ID | <6d1bbbd4-f9a7-4b7d-a9c8-d1b974e71730@googlegroups.com> |
| In reply to | #151976 |
On Sunday, 3 May 2020 13:07:55 UTC+1, Bart wrote:
>
> Part of the task is the write the result to a file (and not by the crude
> way of writing to a console and capturing the output, mixed up with any
> messages such as timing results). The original used fwrite. Maybe there
> is a way of directly writing a 'string' object to a file, but I didn't
> know what that was either.
std::string str = strrepl( ... )
std::ofstream ofs;
ofs.open ("test.txt", std::ofstream::out);
ofs << str;
ofs.close();
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-05-03 14:27 +0100 |
| Message-ID | <xFzrG.52800$QY1.18980@fx30.am4> |
| In reply to | #151978 |
On 03/05/2020 13:26, Malcolm McLean wrote:
> On Sunday, 3 May 2020 13:07:55 UTC+1, Bart wrote:
>>
>> Part of the task is the write the result to a file (and not by the crude
>> way of writing to a console and capturing the output, mixed up with any
>> messages such as timing results). The original used fwrite. Maybe there
>> is a way of directly writing a 'string' object to a file, but I didn't
>> know what that was either.
>
> std::string str = strrepl( ... )
> std::ofstream ofs;
> ofs.open ("test.txt", std::ofstream::out);
>
> ofs << str;
>
> ofs.close();
>
You want this to be a built-in one-liner. That's easy to add as a
regular function in any language, but it should be part of the library.
Eg, I use:
writestrfile("test.txt", str)
writefile("test.txt", str, strlen(str)) # adapts to C too
Perl:
write_file("test.txt", $str)
Some make it harder than others:
http://rosettacode.org/wiki/Write_entire_file
Having it as one function allows chaining:
writestrfile("out",reverse(readstrfile("bible.txt")))
->
.nemA .lla uoy htiw eb tsirhC suseJ droL ruo fo ecarg ehT 12:22 veR
Or, reading/writing lists of lines rather than one string:
writetextfile("out",reverse(readtextfile("bible.txt")))
These two are a bit harder in C because you have intermediate results to
manage. It /ought/ to be possible in C++, but the prospect of figuring
how to do it (after searching innumerable libraries for see it's already
there), or dealing with :: and <> and declaration syntax, or having to
write an entire app in such a clunky language, is really not attractive.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-05-03 22:38 +0100 |
| Message-ID | <874ksw4s25.fsf@bsb.me.uk> |
| In reply to | #151980 |
Bart <bc@freeuk.com> writes:
> On 03/05/2020 13:26, Malcolm McLean wrote:
>> On Sunday, 3 May 2020 13:07:55 UTC+1, Bart wrote:
>>>
>>> Part of the task is the write the result to a file (and not by the crude
>>> way of writing to a console and capturing the output, mixed up with any
>>> messages such as timing results). The original used fwrite. Maybe there
>>> is a way of directly writing a 'string' object to a file, but I didn't
>>> know what that was either.
>>
>> std::string str = strrepl( ... )
>> std::ofstream ofs;
>> ofs.open ("test.txt", std::ofstream::out);
>>
>> ofs << str;
>>
>> ofs.close();
>>
>
> You want this to be a built-in one-liner.
My driver for these tests used
std::ofstream(argv[4]) << str;
You don't need MM's four lines, but this thread has got to the point
where it needs to be seen by real C++ experts.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-05-03 22:06 +0100 |
| Message-ID | <87a72o4tjs.fsf@bsb.me.uk> |
| In reply to | #151976 |
Bart <bc@freeuk.com> writes: > On 03/05/2020 03:55, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Yet, it's not quite as clean as the dynamic code, >> >> Your code appears to have some string operations built-in. > > This one of my gripes against C++, because it provides a complex > toolkit for adding such operations instead of just providing them. The language does provide them. The code I posted uses them alone and no user-defined operations. > The > result is a very difficult language, and 'built-in' features that are > very cumbersome to use. I posted the code because I think it shows that C++'s strings are not "very cumbersome" to use. >> It's even >> simpler written in a language that has lots of string operations >> built-in. In Perl it's just >> >> s/$old/$new/g > > It's not quite that simple. The test is rigged (unintentionally, I am sure). I can rig the test the other way: how does your language do the substitution for every line of any number of input files? > 12,000 files and 500MB later, I can recommend a good book, but that might be too last century for you. > I found I needed to do this: > > $newtext = $text; > $newtext =~ s/lived/LIVEDFOREVER/g; > > Like that, it was still somewhat slower than my interpreter On your system, using whatever Perl you found and using whatever libraries that happens to use. On my system, with a recent Linux 64-bit version of Perl it's about twice the speed of your interpreter. Neither statement says anything of any importance. >>> and I had some fun trying to figure out how to pass such a string to >>> fwrite. >> >> Well, it's an odd thing to do, so I am not surprised by that. > > Part of the task is the write the result to a file (and not by the > crude way of writing to a console and capturing the output, mixed up > with any messages such as timing results). Why would anyone do that? Much better to write to std::cout and, if your system software is half decent, the timing text can be kept separate. (Of course, for the purposes of comparison, my C++ driver copies the "named file in, named file out" method from when I started programming in the 70s.) > The original used > fwrite. Maybe there is a way of directly writing a 'string' object to > a file, but I didn't know what that was either. The original was in C. No one expects you to know C++, but your experience of twisting the language's arm to write a std::string using fwrite does not add anything technical to the discussion. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-05-04 00:28 +0100 |
| Message-ID | <vsIrG.304914$mk2.280191@fx21.am4> |
| In reply to | #151993 |
On 03/05/2020 22:06, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 03/05/2020 03:55, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>
>>>> Yet, it's not quite as clean as the dynamic code,
>>>
>>> Your code appears to have some string operations built-in.
>>
>> This one of my gripes against C++, because it provides a complex
>> toolkit for adding such operations instead of just providing them.
>
> The language does provide them. The code I posted uses them alone and
> no user-defined operations.
From what I can find out the 'string' type used is an instantiation of
a 'basic_string' template, where it seems it is implemented using the
C++ templates, classes, methods and overloads.
It's 'built-in' in that the library is (I guess) expected to be included
in a C++ installation. But those operations are not an intrinsic part of
C++.
There's no particularly problem in a language being partly implemented
in itself, but here it is not that transparent.
Eg. C++ uses 'std::cout' to print stuff, I use a 'print' statement. To
see the difference in approach, try writing 'std::cout >> "hello";'
instead of "std::cout << "hello";'.
>> The
>> result is a very difficult language, and 'built-in' features that are
>> very cumbersome to use.
>
> I posted the code because I think it shows that C++'s strings are not
> "very cumbersome" to use.
I was trying to be kind. A lot of C++ is spectacularly bad, this bit was
much better than what I usually see.
(Although you could probably have replaced 'string::size_type' with just
'int'? Or some 64-bit version.
This is something I can't see the point of, taking what is just an
integer type, a size/count/offset, and using a dedicated type do the job.
In my code, I just use 'int' or 'word' (i64/u64). C and C++ would have
to use [u]int64_t to cover most bases.
C++ didn't stop me copying those string::size_type variables to ordinary
ints, so if doesn't provide the safeguards of a more strongly typed
language, then why bother.)
>> It's not quite that simple.
>
> The test is rigged (unintentionally, I am sure). I can rig the test the
> other way: how does your language do the substitution for every line of
> any number of input files?
Does s///g do that too?
As I said I don't have built-in string replace let alone file replace;
I'd have to code it in the language. (Which is routine, not very
exciting code; see below.)
>> 12,000 files and 500MB later,
>
> I can recommend a good book, but that might be too last century for you.
That was the installation size needed to try out your code (which, for
some reason also included a full version of gcc). I still don't get what
s///* is, or how it works, but I managed to get it to do the job.
------------------------------------------
import sys
import files
import oslib
const inpath="./files/"
const outpath="./files2/"
proc start=
if ncmdparams<>4 then
fprintln "Usage: qq # <filespec> <old> <new>",
extractbasefile(cmdparams[1])
stop 1
fi
(filespec, oldstr, newstr) := cmdparams[2..4]
files := dirlist(inpath+filespec)
if not files then
println "No files found"
stop 1
fi
forall file in files do
println "Converting",inpath+file,,":"
filerepl(inpath+file, oldstr, newstr, outpath+file)
od
println "Done"
end
proc filerepl(filename, oldstr, newstr, newfile="")=
if newfile = "" then newfile := filename fi
writestrfile(newfile, strrepl(readstrfile(filename), oldstr, newstr))
end
function strrepl(s, old, newstr)=
t := ""
while n := old in s do
t +:= s[1..n-1]+newstr
s := s[n+old.len..$]
od
return t+s
end
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-05-03 02:16 -0700 |
| Message-ID | <8fdfedb0-e3cb-4db0-ab38-1e6ce777afc7@googlegroups.com> |
| In reply to | #151973 |
On Saturday, 2 May 2020 23:29:40 UTC+1, Bart wrote:
> On 02/05/2020 22:45, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> [Off the topic of pure C90]
> >>
> >> On 02/05/2020 15:20, Bonita Montero wrote:
> >>>> How expressive and how simple.
> >>>
> >>> Simplicity mostly contraticts expressiveness.
> >>
> >> Remember the strrepl thread? My scripting solution can be expressed like this:
> >>
> >> function strrepl(s, old, new)=
> >> t := ""
> >> while n:=old in s do
> >> t +:= s[1..n-1] + new
> >> s := s[n+old.len..$]
> >> od
> >> return t+s
> >> end
> >
> > This can be written in C++ like this:
> >
> > using std::string;
> >
> > string replace(const string &str, const string &pat, const string &rep)
> > {
> > string result;
> > string::size_type pos = 0, start;
> > while ((start = str.find(pat, pos)) != string::npos) {
> > result += str.substr(pos, start - pos) + rep;
> > pos = start + pat.length();
> > }
> > return result + str.substr(pos);
> > }
> >
> > It need not be as complicated as some of the posted code.
> >
>
> That's not too bad. Certainly it is smaller and simpler than anything I
> remember Bonita posting.
>
I suspect it works well in a test environment, not so well in deployment.
The reason is that the buffer needs to grow on every match. If the program
has made only one allocation, the string will be before an empty region
of memory. So realloc() can just adjust the block length.
In deployment, it is more likely to be give a small free region on the
initial request from a fragmented memory pool. So reallocations will involve copying.
It is however a reasonable way to write strepl. Let the built-in allocation
and string functions take the strain.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-05-03 16:23 -0700 |
| Message-ID | <ec585c4f-2696-403b-83c4-76d853169d42@googlegroups.com> |
| In reply to | #151975 |
On Sunday, 3 May 2020 12:16:55 UTC+3, Malcolm McLean wrote:
> On Saturday, 2 May 2020 23:29:40 UTC+1, Bart wrote:
> > On 02/05/2020 22:45, Ben Bacarisse wrote:
> > > Bart <bc@freeuk.com> writes:
> > >
> > >> [Off the topic of pure C90]
> > >>
> > >> On 02/05/2020 15:20, Bonita Montero wrote:
> > >>>> How expressive and how simple.
> > >>>
> > >>> Simplicity mostly contraticts expressiveness.
> > >>
> > >> Remember the strrepl thread? My scripting solution can be expressed like this:
> > >>
> > >> function strrepl(s, old, new)=
> > >> t := ""
> > >> while n:=old in s do
> > >> t +:= s[1..n-1] + new
> > >> s := s[n+old.len..$]
> > >> od
> > >> return t+s
> > >> end
> > >
> > > This can be written in C++ like this:
> > >
> > > using std::string;
> > >
> > > string replace(const string &str, const string &pat, const string &rep)
> > > {
> > > string result;
> > > string::size_type pos = 0, start;
> > > while ((start = str.find(pat, pos)) != string::npos) {
> > > result += str.substr(pos, start - pos) + rep;
> > > pos = start + pat.length();
> > > }
> > > return result + str.substr(pos);
> > > }
> > >
> > > It need not be as complicated as some of the posted code.
> > >
> >
> > That's not too bad. Certainly it is smaller and simpler than anything I
> > remember Bonita posting.
> >
> I suspect it works well in a test environment, not so well in deployment.
>
> The reason is that the buffer needs to grow on every match. If the program
> has made only one allocation, the string will be before an empty region
> of memory. So realloc() can just adjust the block length.
> In deployment, it is more likely to be give a small free region on the
> initial request from a fragmented memory pool. So reallocations will involve copying.
It is unlikely (but not forbidden by standard) that string is reallocating
its buffer on every append. It is unlikely because in typical library
implementations the containers tend to grow their capacity exponentially
when running out of space.
To reduce even those reallocations we can result.reserve(good_prediction)
right at start.
>
> It is however a reasonable way to write strepl. Let the built-in allocation
> and string functions take the strain.
Leaving the built-in algorithms to work can be fine. I have seen
how clumsy maintenance did add reserve() that did actually damage
performance and caused noticeable slow-down.
I myself would most likely just use boost ...
#include <boost/algorithm/string.hpp>
... and then ...
boost::replace_all(str, pat, rep);
... as first thing. It is likely good enough.
If it is like vast majority of code then it does alter overall
performance of whatever I'm writing by very little and it
disappears into rest of the thousands of lines of code.
If it however matters ... then it will swim up one day as
potential performance improvement.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-05-04 16:41 +0200 |
| Message-ID | <r8p9i4$m8b$1@news.albasani.net> |
| In reply to | #151997 |
> It is unlikely because in typical library implementations the containers > tend to grow their capacity exponentially when running out of space. That's nonsense or more precisely: no one would accept a container that wastes so much space. If you want this behaviour from a container you would have to do it yourself by tuning the capacity. Memory allocation usually has alignment-requirements which affect the allocation-granularity. Runtimes might round up the capacity of a con- tainer to this granularity if the containers are tied to this allocation -behaviour; but they're not guaranteed to do that.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-05-04 16:59 +0200 |
| Message-ID | <r8pakh$m13$1@news.albasani.net> |
| In reply to | #152025 |
I just wrote a small experiment:
#include <iostream>
#include <string>
#include <cstring>
using namespace std;
int main()
{
string str;
char appendStr[] = "hello world";
size_t alLen = strlen( appendStr );
for( size_t i = 1; i <= 100; ++i )
str += appendStr,
cout << str.capacity() - i * alLen << ", ";
}
The output is for MSVC 2019:
4, 9, 14, 3, 15, 4, 28, 17, 6, 47, 36, 25, 14, 3, 70, 59, 48, 37, 26,
15, 4, 110, 99, 88, 77, 66, 55, 44, 33, 22, 11, 0, 165, 154, 143, 132,
121, 110, 99, 88, 77, 66, 55, 44, 33, 22, 11, 0, 253, 242, 231, 220,
209, 198, 187, 176, 165, 154, 143, 132, 121, 110, 99, 88, 77, 66, 55,
44, 33, 22, 11, 0, 385, 374, 363, 352, 341, 330, 319, 308, 297, 286,
275, 264, 253, 242, 231, 220, 209, 198, 187, 176, 165, 154, 143, 132,
121, 110, 99, 88,
The difference follows a zigzag-pattern as you can see in this
diagram: http://www.imageno.com/849ycqf4vdtrpic.html
So the allocation grows with the bucket-steps of the allocator,
is then eaten up by the append-operations and when the buffer
of a certain size-class is full, a new block with a new size
-class is allocated.
With libstdc++ that's the same, but the allocation-granularity
is more coarse: http://www.imageno.com/wj20m655enyipic.html
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-05-04 11:01 -0700 |
| Message-ID | <34c63f24-b9d0-47c6-bdef-2098c0f399ba@googlegroups.com> |
| In reply to | #152029 |
On Monday, 4 May 2020 17:59:35 UTC+3, Bonita Montero wrote:
> I just wrote a small experiment:
>
> #include <iostream>
> #include <string>
> #include <cstring>
>
> using namespace std;
>
> int main()
> {
> string str;
> char appendStr[] = "hello world";
> size_t alLen = strlen( appendStr );
> for( size_t i = 1; i <= 100; ++i )
> str += appendStr,
> cout << str.capacity() - i * alLen << ", ";
> }
>
> The output is for MSVC 2019:
>
> 4, 9, 14, 3, 15, 4, 28, 17, 6, 47, 36, 25, 14, 3, 70, 59, 48, 37, 26,
> 15, 4, 110, 99, 88, 77, 66, 55, 44, 33, 22, 11, 0, 165, 154, 143, 132,
> 121, 110, 99, 88, 77, 66, 55, 44, 33, 22, 11, 0, 253, 242, 231, 220,
> 209, 198, 187, 176, 165, 154, 143, 132, 121, 110, 99, 88, 77, 66, 55,
> 44, 33, 22, 11, 0, 385, 374, 363, 352, 341, 330, 319, 308, 297, 286,
> 275, 264, 253, 242, 231, 220, 209, 198, 187, 176, 165, 154, 143, 132,
> 121, 110, 99, 88,
>
> The difference follows a zigzag-pattern as you can see in this
> diagram: http://www.imageno.com/849ycqf4vdtrpic.html
> So the allocation grows with the bucket-steps of the allocator,
> is then eaten up by the append-operations and when the buffer
> of a certain size-class is full, a new block with a new size
> -class is allocated.
> With libstdc++ that's the same, but the allocation-granularity
> is more coarse: http://www.imageno.com/wj20m655enyipic.html
Interesting. What I meant with exponential was that in most
implementations the containers increase the previous capacity
two-fold when running out of it. So if I modify your program
a bit ...:
#include <iostream>
#include <string>
#include <cstring>
using namespace std;
int main()
{
string str;
string appendStr = "hello world";
size_t cap = -1;
for( size_t i = 0; i < 1000; ++i )
{
if (str.capacity() != cap)
{
cap = str.capacity();
cout << "(" << i << ") " << cap << ", ";
}
str += appendStr;
}
}
... then I typically get something like that:
(0) 15, (2) 30, (3) 60, (6) 120, (11) 240, (22) 480, (44) 960,
(88) 1920, (175) 3840, (350) 7680, (699) 15360,
The "more coarse" was likely result of the initial capacity
being different between different compilers?
Other thing that standard says nothing but is quite common is
that the std::unordered_ containers tend also to grow about
two-fold but keep the bucket count prime.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-05-02 11:13 +0100 |
| Message-ID | <vJbrG.141064$Jj2.25730@fx11.am4> |
| In reply to | #151935 |
On 02/05/2020 06:19, Paul Edwards wrote: > For decades I have been working on creating a > public domain operating system called PDOS/386. > You can see the project here: > > http://pdos.sourceforge.net/ I assume this is open source software. If so, I'm having trouble locating the source code (ie. .c and .h files). Is this it here: https://sourceforge.net/p/pdos/gitcode/ci/pdos-stage1/tree/ ? But looking at it further, that's just one of many directories. Could someone with, say, a Windows PC and a number of C compilers (but not Turbo C which I saw mentioned), build any of this stuff and run it, or do you need vintage hardware? Is the 'int' size in those sources 16-bit or 32-bit? If the result of building is some special binary format suitable for bootstrapping an OS on actual hardware, how do you get a C compiler to do that; will they need to support those formats?
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web