Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86894 > unrolled thread
| Started by | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| First post | 2022-10-12 15:57 -0700 |
| Last post | 2022-10-15 11:34 +0200 |
| Articles | 20 on this page of 106 — 22 participants |
Back to article view | Back to comp.lang.c++
CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-12 15:57 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-12 16:01 -0700
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 17:16 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:38 +0200
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-16 06:24 -0800
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-17 11:04 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-17 16:40 +0000
Re: CHAR_BIT is not eight Richard Damon <Richard@Damon-Family.org> - 2022-11-17 23:23 -0500
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 08:16 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:33 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 18:54 +0100
Re: CHAR_BIT is not eight Michael S <already5chosen@yahoo.com> - 2022-11-18 03:47 -0800
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 14:52 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-11-18 16:32 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-11-18 19:05 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-11-18 18:16 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 08:02 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 08:08 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:35 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 02:53 -0700
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:57 +0200
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 03:05 -0700
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-17 06:18 +0000
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:29 -0500
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 02:06 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 11:42 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-13 15:36 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 23:06 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 22:30 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:27 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 14:47 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-14 14:58 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 21:01 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 10:28 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-15 13:39 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 12:45 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:18 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:24 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:34 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:39 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:53 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:55 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-15 15:57 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:59 +0100
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:27 +0000
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-17 09:04 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 16:13 +0000
Re: CHAR_BIT is not eight red floyd <no.spam.here@its.invalid> - 2022-10-17 09:44 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:47 +0100
Re: CHAR_BIT is not eight Manfred <noname@add.invalid> - 2022-10-18 01:10 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-17 16:22 -0700
Re: CHAR_BIT is not eight Paul N <gw7rib@aol.com> - 2022-10-18 05:13 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-18 15:04 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-18 17:40 +0100
Re: CHAR_BIT is not eight "daniel...@gmail.com" <danielaparker@gmail.com> - 2022-10-18 12:14 -0700
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-19 15:12 +0000
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-19 15:35 +0000
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-20 16:16 +0000
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:13 +0200
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 20:11 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 20:03 +0100
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-16 07:51 +0200
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 17:03 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 16:34 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 18:51 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 18:11 +0100
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 19:18 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 22:02 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 21:19 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 21:24 +0000
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:38 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 14:48 -0700
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-16 22:39 +0100
Re: CHAR_BIT is not eight scott@slp53.sl.home (Scott Lurndal) - 2022-10-16 23:49 +0000
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 09:54 +0200
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:31 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 19:56 +0200
Re: CHAR_BIT is not eight Muttley@dastardlyhq.com - 2022-10-17 15:29 +0000
Re: CHAR_BIT is not eight Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-17 17:33 +0100
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 11:55 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-15 13:06 -0700
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-15 15:42 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-16 19:10 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:28 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-17 10:09 +0200
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:35 -0700
Re: CHAR_BIT is not eight "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-16 13:36 -0700
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-02 17:46 -0700
Re: CHAR_BIT is not eight Bo Persson <bo@bo-persson.se> - 2022-10-13 11:10 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 10:49 +0000
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-13 12:05 +0000
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-13 06:34 -0700
Re: CHAR_BIT is not eight Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 15:24 +0100
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-13 15:59 +0200
Re: CHAR_BIT is not eight Juha Nieminen <nospam@thanks.invalid> - 2022-10-14 05:54 +0000
Re: CHAR_BIT is not eight Paavo Helde <eesnimi@osa.pri.ee> - 2022-10-14 09:16 +0300
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-16 05:41 -0800
Re: CHAR_BIT is not eight Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-16 10:38 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-05 11:42 -0800
Re: CHAR_BIT is not eight Öö Tiib <ootiib@hot.ee> - 2022-12-06 01:03 -0800
Re: CHAR_BIT is not eight Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-28 20:49 -0800
Re: CHAR_BIT is not eight Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-10-14 00:17 -0700
Re: CHAR_BIT is not eight David Brown <david.brown@hesbynett.no> - 2022-10-14 15:33 +0200
Re: CHAR_BIT is not eight Vir Campestris <vir.campestris@invalid.invalid> - 2022-10-16 21:37 +0100
Re: CHAR_BIT is not eight Lynn McGuire <lynnmcguire5@gmail.com> - 2022-10-17 15:24 -0500
Re: CHAR_BIT is not eight Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-15 11:34 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-15 20:03 +0100 |
| Message-ID | <20221015200324.000038c8@reddwarf.jmc.corp> |
| In reply to | #86991 |
On Sat, 15 Oct 2022 20:11:37 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 15.10.2022 um 13:45 schrieb Mr Flibble: > > > Try using std::list with a custom allocator as I originally > > suggested; also your quote of 7KB sounds highly dubious and > > anecdotal. > > This doesn't work since the allocator allocates the items at at > different type than for which the allocator is specified. std::list > -Items encapsulates the type for which the list is speciefied in > another structure that has the forward and backward-pointers to > have only a single allocation and not a link-object and a T-object > which the link points separately. > So nearly all containers re-class that allocator with rebind_alloc<>. > AFAIK having a 1:1 custom allocator in that sense is only possible > with the containers that have random access iterators. No. Obviously rebinding from T to a list node containing T can work with a custom allocator. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-10-16 07:51 +0200 |
| Message-ID | <tig64k$335de$1@dont-email.me> |
| In reply to | #86994 |
Am 15.10.2022 um 21:03 schrieb Mr Flibble: > On Sat, 15 Oct 2022 20:11:37 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Am 15.10.2022 um 13:45 schrieb Mr Flibble: >> >>> Try using std::list with a custom allocator as I originally >>> suggested; also your quote of 7KB sounds highly dubious and >>> anecdotal. >> >> This doesn't work since the allocator allocates the items at at >> different type than for which the allocator is specified. std::list >> -Items encapsulates the type for which the list is speciefied in >> another structure that has the forward and backward-pointers to >> have only a single allocation and not a link-object and a T-object >> which the link points separately. >> So nearly all containers re-class that allocator with rebind_alloc<>. >> AFAIK having a 1:1 custom allocator in that sense is only possible >> with the containers that have random access iterators. > > No. Obviously rebinding from T to a list node containing T can work > with a custom allocator. I didn't say anything different.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-16 17:03 +0200 |
| Message-ID | <tih6ga$35lhr$1@dont-email.me> |
| In reply to | #86981 |
On 15/10/2022 13:45, Mr Flibble wrote: > On Sat, 15 Oct 2022 13:39:24 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 14/10/2022 22:01, Mr Flibble wrote: >>> On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) >>> Muttley@dastardlyhq.com wrote: >>> >>>> On Fri, 14 Oct 2022 14:47:46 +0100 >>>> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >>>>> On Fri, 14 Oct 2022 15:27:13 +0200 >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> Yes, it is always /possible/. But the complications and effort >>>>>> involved is unlikely to be worth the effort, and you'd still end >>>>>> up with something taking a massive amount of code space. (With >>>>>> "massive" being relative to the small code memories of such >>>>>> systems.) >>>>>> >>>>>> It's not uncommon in my coding to build up a few lists at the >>>>>> startup of the system - lists of "run" functions or software >>>>>> timers, etc. Modules might register such callbacks or functions >>>>>> when initialised. In "big system" C++, you might just use a >>>>>> vector for that - adding your timer objects to your vector as >>>>>> needed. It's simple and easy in the code. >>>>>> >>>>>> But in a resource-constraint embedded system, where efficiency of >>>>>> code space, ram space and run-time is important (though run-time >>>>>> efficiency is usually less important for startup code), that's >>>>>> not what you would do. You make your timer class have the >>>>>> required list link pointers in the class, have each registering >>>>>> function declare their timer object with static lifetime, and >>>>>> your registration function links them together. >>>>>> >>>>>> There's no doubt that this takes a bit more effort to write than >>>>>> an off-the-shelf std::vector. But it is vastly simpler than >>>>>> faffing around making your own allocator, avoids the use of any >>>>>> kind of dynamic memory (using neither the standard heap nor a >>>>>> home-made allocation system), and pulls in a tiny fraction of the >>>>>> amount of library code. >>>>>> >>>>>> std::array<> is free - it's just a nice wrapper around a plain >>>>>> C-style array. >>>>> >>>>> List link pointers? Again there is no reason to not use std::list >>>>> with a suitable allocator even on such resource constrained >>>>> hardware and I disagree that the resultant text size and ram >>>>> usage would be any worse than anything you could come up with by >>>>> hand. >>>> >>>> If the memory layout is hard coded at boot time why even bother >>>> pulling in std::list or any kind of container as you don't need >>>> their generic functionality which will almost certainly waste >>>> EEPROM space. With embedded development you often literally have >>>> to worry about every byte you use both in ROM and RAM and whether >>>> the mainloop is going to be fast enough to do its job. >>> >>> In C++ you don't pay for what you don't use: in the case of a C++ >>> class template only the member functions instantiated will exist in >>> the text segment. >>> >> >> There are always /lots/ of other functions that get pulled in from >> libraries. Remember, for small embedded systems the libraries are >> not shared dynamic libraries that you don't see. >> >> Just for a quick test, I made a minimal C++ main() function and >> compiled for a modern microcontroller. With an empty main(), it was >> about 8400 bytes code of common library code. Adding a >> "std::list<int>" object and using a couple of pops and pushes adds >> about 7 KB code to the program. >> >> If you are making a lot of use of the standard containers, that's >> fine - and there's a lot of overlap and sharing in this extra code. >> But in small systems, this kind of stuff can get significant - >> microcontrollers with 32 KB flash are common, and it's nice to be >> able to program them in C++. In the C++ /language/, you pay very >> little (not quite nothing) for features that you don't use, but that >> does not apply equally to the more advanced standard library classes. >> >> It's the same in C, of course - call just one little time conversion >> function and you can find half your flash is used for locale handling >> and time zones. >> >> The needs of embedded systems vary enormously - for many, the cost in >> code space or run-time efficiency for using a std::list or >> std::vector is negligible. But for others, it is very far from >> negligible. >> >> (It is relatively rare that you have to worry about /every/ byte of >> code or data space, however - though it does happen.) > > Try using std::list with a custom allocator as I originally suggested; > also your quote of 7KB sounds highly dubious and anecdotal. > Of course the example of 7 KB is anecdotal - I told you I made a quick test. It doesn't get more anecdotal than that. But no, it is not "highly dubious" - it is really what I got. Every programmer works in a particular area, or small set of areas - /nobody/ has experience and knowledge of all kinds of programming. The trick to having realistic conversations and not appearing arrogant and ignorant is to understand your limitations. You simply don't know what you are talking about when it comes to small-systems embedded programming, and some of the challenges or limitations involved that are different from the kind of programming you are used to. (And similarly there is plenty about the kind of coding /you/ do that I am ignorant about.) So it is /fine/ for you to ask "why don't you just use a std::list with a custom allocator". It is /not/ fine for you to claim people are wrong when they tell you why they don't do that. Why don't I write a custom allocator for std::list and then use that instead of the pointer-based "home made" linked list I have now? I don't do so because it is a lot of effort and will result in bigger, slower, wasteful and vastly more complicated code than the two dozen or so lines of shared C and C++ code I have at the moment that has worked fine for the last 20+ years. It's not unlikely that with a custom allocator and disabled exceptions I could probably get the overhead of std::list down to 2 or 3 KB rather than 7 KB. But that only makes it not quite as inefficient - it still is not close to the efficiency and convenience of the custom solution. And that would come after writing far more code to make the "standard" container work than it took to make a completely custom solution.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-16 16:34 +0100 |
| Message-ID | <20221016163414.000003a9@reddwarf.jmc.corp> |
| In reply to | #87014 |
On Sun, 16 Oct 2022 17:03:38 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 15/10/2022 13:45, Mr Flibble wrote: > > On Sat, 15 Oct 2022 13:39:24 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> On 14/10/2022 22:01, Mr Flibble wrote: > >>> On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) > >>> Muttley@dastardlyhq.com wrote: > >>> > >>>> On Fri, 14 Oct 2022 14:47:46 +0100 > >>>> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >>>>> On Fri, 14 Oct 2022 15:27:13 +0200 > >>>>> David Brown <david.brown@hesbynett.no> wrote: > >>>>>> Yes, it is always /possible/. But the complications and effort > >>>>>> involved is unlikely to be worth the effort, and you'd still > >>>>>> end up with something taking a massive amount of code space. > >>>>>> (With "massive" being relative to the small code memories of > >>>>>> such systems.) > >>>>>> > >>>>>> It's not uncommon in my coding to build up a few lists at the > >>>>>> startup of the system - lists of "run" functions or software > >>>>>> timers, etc. Modules might register such callbacks or functions > >>>>>> when initialised. In "big system" C++, you might just use a > >>>>>> vector for that - adding your timer objects to your vector as > >>>>>> needed. It's simple and easy in the code. > >>>>>> > >>>>>> But in a resource-constraint embedded system, where efficiency > >>>>>> of code space, ram space and run-time is important (though > >>>>>> run-time efficiency is usually less important for startup > >>>>>> code), that's not what you would do. You make your timer > >>>>>> class have the required list link pointers in the class, have > >>>>>> each registering function declare their timer object with > >>>>>> static lifetime, and your registration function links them > >>>>>> together. > >>>>>> > >>>>>> There's no doubt that this takes a bit more effort to write > >>>>>> than an off-the-shelf std::vector. But it is vastly simpler > >>>>>> than faffing around making your own allocator, avoids the use > >>>>>> of any kind of dynamic memory (using neither the standard heap > >>>>>> nor a home-made allocation system), and pulls in a tiny > >>>>>> fraction of the amount of library code. > >>>>>> > >>>>>> std::array<> is free - it's just a nice wrapper around a plain > >>>>>> C-style array. > >>>>> > >>>>> List link pointers? Again there is no reason to not use > >>>>> std::list with a suitable allocator even on such resource > >>>>> constrained hardware and I disagree that the resultant text > >>>>> size and ram usage would be any worse than anything you could > >>>>> come up with by hand. > >>>> > >>>> If the memory layout is hard coded at boot time why even bother > >>>> pulling in std::list or any kind of container as you don't need > >>>> their generic functionality which will almost certainly waste > >>>> EEPROM space. With embedded development you often literally have > >>>> to worry about every byte you use both in ROM and RAM and whether > >>>> the mainloop is going to be fast enough to do its job. > >>> > >>> In C++ you don't pay for what you don't use: in the case of a C++ > >>> class template only the member functions instantiated will exist > >>> in the text segment. > >>> > >> > >> There are always /lots/ of other functions that get pulled in from > >> libraries. Remember, for small embedded systems the libraries are > >> not shared dynamic libraries that you don't see. > >> > >> Just for a quick test, I made a minimal C++ main() function and > >> compiled for a modern microcontroller. With an empty main(), it > >> was about 8400 bytes code of common library code. Adding a > >> "std::list<int>" object and using a couple of pops and pushes adds > >> about 7 KB code to the program. > >> > >> If you are making a lot of use of the standard containers, that's > >> fine - and there's a lot of overlap and sharing in this extra code. > >> But in small systems, this kind of stuff can get significant - > >> microcontrollers with 32 KB flash are common, and it's nice to be > >> able to program them in C++. In the C++ /language/, you pay very > >> little (not quite nothing) for features that you don't use, but > >> that does not apply equally to the more advanced standard library > >> classes. > >> > >> It's the same in C, of course - call just one little time > >> conversion function and you can find half your flash is used for > >> locale handling and time zones. > >> > >> The needs of embedded systems vary enormously - for many, the cost > >> in code space or run-time efficiency for using a std::list or > >> std::vector is negligible. But for others, it is very far from > >> negligible. > >> > >> (It is relatively rare that you have to worry about /every/ byte of > >> code or data space, however - though it does happen.) > > > > Try using std::list with a custom allocator as I originally > > suggested; also your quote of 7KB sounds highly dubious and > > anecdotal. > > Of course the example of 7 KB is anecdotal - I told you I made a > quick test. It doesn't get more anecdotal than that. But no, it is > not "highly dubious" - it is really what I got. > > Every programmer works in a particular area, or small set of areas - > /nobody/ has experience and knowledge of all kinds of programming. > The trick to having realistic conversations and not appearing > arrogant and ignorant is to understand your limitations. You simply > don't know what you are talking about when it comes to small-systems > embedded programming, and some of the challenges or limitations > involved that are different from the kind of programming you are used > to. (And similarly there is plenty about the kind of coding /you/ do > that I am ignorant about.) > > So it is /fine/ for you to ask "why don't you just use a std::list > with a custom allocator". It is /not/ fine for you to claim people > are wrong when they tell you why they don't do that. > > Why don't I write a custom allocator for std::list and then use that > instead of the pointer-based "home made" linked list I have now? I > don't do so because it is a lot of effort and will result in bigger, > slower, wasteful and vastly more complicated code than the two dozen > or so lines of shared C and C++ code I have at the moment that has > worked fine for the last 20+ years. It's not unlikely that with a > custom allocator and disabled exceptions I could probably get the > overhead of std::list down to 2 or 3 KB rather than 7 KB. But that > only makes it not quite as inefficient - it still is not close to the > efficiency and convenience of the custom solution. And that would > come after writing far more code to make the "standard" container > work than it took to make a completely custom solution. So you admit that you *might* be able to get it down to 2KB; so I was correct in my analysis and it is you who is arrogant not me. I am also well aware of the constraints involved in embedded programming and your assumption that I am not is another sign of your arrogance. It is highly unlikely that your solution is more performant than std::list; a double linked list is hardly rocket science and standard library implementations are generally written by people who know what they are doing. So you can either apologize or fuck off. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-16 18:51 +0200 |
| Message-ID | <tihcrc$3683u$3@dont-email.me> |
| In reply to | #87016 |
On 16/10/2022 17:34, Mr Flibble wrote: > On Sun, 16 Oct 2022 17:03:38 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 15/10/2022 13:45, Mr Flibble wrote: >>> On Sat, 15 Oct 2022 13:39:24 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 14/10/2022 22:01, Mr Flibble wrote: >>>>> On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) >>>>> Muttley@dastardlyhq.com wrote: >>>>> >>>>>> On Fri, 14 Oct 2022 14:47:46 +0100 >>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >>>>>>> On Fri, 14 Oct 2022 15:27:13 +0200 >>>>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>>>> Yes, it is always /possible/. But the complications and effort >>>>>>>> involved is unlikely to be worth the effort, and you'd still >>>>>>>> end up with something taking a massive amount of code space. >>>>>>>> (With "massive" being relative to the small code memories of >>>>>>>> such systems.) >>>>>>>> >>>>>>>> It's not uncommon in my coding to build up a few lists at the >>>>>>>> startup of the system - lists of "run" functions or software >>>>>>>> timers, etc. Modules might register such callbacks or functions >>>>>>>> when initialised. In "big system" C++, you might just use a >>>>>>>> vector for that - adding your timer objects to your vector as >>>>>>>> needed. It's simple and easy in the code. >>>>>>>> >>>>>>>> But in a resource-constraint embedded system, where efficiency >>>>>>>> of code space, ram space and run-time is important (though >>>>>>>> run-time efficiency is usually less important for startup >>>>>>>> code), that's not what you would do. You make your timer >>>>>>>> class have the required list link pointers in the class, have >>>>>>>> each registering function declare their timer object with >>>>>>>> static lifetime, and your registration function links them >>>>>>>> together. >>>>>>>> >>>>>>>> There's no doubt that this takes a bit more effort to write >>>>>>>> than an off-the-shelf std::vector. But it is vastly simpler >>>>>>>> than faffing around making your own allocator, avoids the use >>>>>>>> of any kind of dynamic memory (using neither the standard heap >>>>>>>> nor a home-made allocation system), and pulls in a tiny >>>>>>>> fraction of the amount of library code. >>>>>>>> >>>>>>>> std::array<> is free - it's just a nice wrapper around a plain >>>>>>>> C-style array. >>>>>>> >>>>>>> List link pointers? Again there is no reason to not use >>>>>>> std::list with a suitable allocator even on such resource >>>>>>> constrained hardware and I disagree that the resultant text >>>>>>> size and ram usage would be any worse than anything you could >>>>>>> come up with by hand. >>>>>> >>>>>> If the memory layout is hard coded at boot time why even bother >>>>>> pulling in std::list or any kind of container as you don't need >>>>>> their generic functionality which will almost certainly waste >>>>>> EEPROM space. With embedded development you often literally have >>>>>> to worry about every byte you use both in ROM and RAM and whether >>>>>> the mainloop is going to be fast enough to do its job. >>>>> >>>>> In C++ you don't pay for what you don't use: in the case of a C++ >>>>> class template only the member functions instantiated will exist >>>>> in the text segment. >>>>> >>>> >>>> There are always /lots/ of other functions that get pulled in from >>>> libraries. Remember, for small embedded systems the libraries are >>>> not shared dynamic libraries that you don't see. >>>> >>>> Just for a quick test, I made a minimal C++ main() function and >>>> compiled for a modern microcontroller. With an empty main(), it >>>> was about 8400 bytes code of common library code. Adding a >>>> "std::list<int>" object and using a couple of pops and pushes adds >>>> about 7 KB code to the program. >>>> >>>> If you are making a lot of use of the standard containers, that's >>>> fine - and there's a lot of overlap and sharing in this extra code. >>>> But in small systems, this kind of stuff can get significant - >>>> microcontrollers with 32 KB flash are common, and it's nice to be >>>> able to program them in C++. In the C++ /language/, you pay very >>>> little (not quite nothing) for features that you don't use, but >>>> that does not apply equally to the more advanced standard library >>>> classes. >>>> >>>> It's the same in C, of course - call just one little time >>>> conversion function and you can find half your flash is used for >>>> locale handling and time zones. >>>> >>>> The needs of embedded systems vary enormously - for many, the cost >>>> in code space or run-time efficiency for using a std::list or >>>> std::vector is negligible. But for others, it is very far from >>>> negligible. >>>> >>>> (It is relatively rare that you have to worry about /every/ byte of >>>> code or data space, however - though it does happen.) >>> >>> Try using std::list with a custom allocator as I originally >>> suggested; also your quote of 7KB sounds highly dubious and >>> anecdotal. >> >> Of course the example of 7 KB is anecdotal - I told you I made a >> quick test. It doesn't get more anecdotal than that. But no, it is >> not "highly dubious" - it is really what I got. >> >> Every programmer works in a particular area, or small set of areas - >> /nobody/ has experience and knowledge of all kinds of programming. >> The trick to having realistic conversations and not appearing >> arrogant and ignorant is to understand your limitations. You simply >> don't know what you are talking about when it comes to small-systems >> embedded programming, and some of the challenges or limitations >> involved that are different from the kind of programming you are used >> to. (And similarly there is plenty about the kind of coding /you/ do >> that I am ignorant about.) >> >> So it is /fine/ for you to ask "why don't you just use a std::list >> with a custom allocator". It is /not/ fine for you to claim people >> are wrong when they tell you why they don't do that. >> >> Why don't I write a custom allocator for std::list and then use that >> instead of the pointer-based "home made" linked list I have now? I >> don't do so because it is a lot of effort and will result in bigger, >> slower, wasteful and vastly more complicated code than the two dozen >> or so lines of shared C and C++ code I have at the moment that has >> worked fine for the last 20+ years. It's not unlikely that with a >> custom allocator and disabled exceptions I could probably get the >> overhead of std::list down to 2 or 3 KB rather than 7 KB. But that >> only makes it not quite as inefficient - it still is not close to the >> efficiency and convenience of the custom solution. And that would >> come after writing far more code to make the "standard" container >> work than it took to make a completely custom solution. > > So you admit that you *might* be able to get it down to 2KB; so I was > correct in my analysis and it is you who is arrogant not me. Sorry, you seem to be having trouble understanding the conversation. No, your analysis was not correct - the 7 KB was not "highly dubious", but an actual measurement on real code that was compiled and linked (with a case sample size of 1). Disabling exceptions would have been simple, and it is common practice on small embedded systems - just as avoiding most standard library containers (and much of the C and C++ standard libraries) is common practice on small embedded systems. Leaving exceptions enabled is a fairer test, however, as it would be realistic for the kind of programmer who thinks std::list<> and custom allocators is a good idea for the task in hand. > I am also > well aware of the constraints involved in embedded programming and your > assumption that I am not is another sign of your arrogance. > I can only assume based on what you write - and you do not write as someone who has experience in small-systems embedded programming. > It is highly unlikely that your solution is more performant than > std::list; a double linked list is hardly rocket science and standard > library implementations are generally written by people who know what > they are doing. It would not surprise me if my solution is an order of magnitude better performing than std::list<>. (Not that I claim the difference would be significant for the use in question. std::list<> is going to be pretty efficient, but a very simple custom single linked list can be considerably more efficient.) As you say, a linked list is not rocket science - there's no need for custom allocators and standard library containers when all that's needed is a "pointer to next node" field in the node structure. > > So you can either apologize or fuck off. > You are joking, yes? You think I should apologize for your misunderstandings, your unwarranted assumptions, your accusations of dishonesty and your belief that you know better than anyone else about fields of programming that are completely beyond your experience? I'm will try to avoid posting more in this subthread unless it contributes something positive. Hopefully you'll do the same.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-16 18:11 +0100 |
| Message-ID | <20221016181139.00002528@reddwarf.jmc.corp> |
| In reply to | #87020 |
On Sun, 16 Oct 2022 18:51:56 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 16/10/2022 17:34, Mr Flibble wrote: > > On Sun, 16 Oct 2022 17:03:38 +0200 > > David Brown <david.brown@hesbynett.no> wrote: > > > >> On 15/10/2022 13:45, Mr Flibble wrote: > >>> On Sat, 15 Oct 2022 13:39:24 +0200 > >>> David Brown <david.brown@hesbynett.no> wrote: > >>> > >>>> On 14/10/2022 22:01, Mr Flibble wrote: > >>>>> On Fri, 14 Oct 2022 14:58:54 -0000 (UTC) > >>>>> Muttley@dastardlyhq.com wrote: > >>>>> > >>>>>> On Fri, 14 Oct 2022 14:47:46 +0100 > >>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >>>>>>> On Fri, 14 Oct 2022 15:27:13 +0200 > >>>>>>> David Brown <david.brown@hesbynett.no> wrote: > >>>>>>>> Yes, it is always /possible/. But the complications and > >>>>>>>> effort involved is unlikely to be worth the effort, and > >>>>>>>> you'd still end up with something taking a massive amount of > >>>>>>>> code space. (With "massive" being relative to the small code > >>>>>>>> memories of such systems.) > >>>>>>>> > >>>>>>>> It's not uncommon in my coding to build up a few lists at the > >>>>>>>> startup of the system - lists of "run" functions or software > >>>>>>>> timers, etc. Modules might register such callbacks or > >>>>>>>> functions when initialised. In "big system" C++, you might > >>>>>>>> just use a vector for that - adding your timer objects to > >>>>>>>> your vector as needed. It's simple and easy in the code. > >>>>>>>> > >>>>>>>> But in a resource-constraint embedded system, where > >>>>>>>> efficiency of code space, ram space and run-time is > >>>>>>>> important (though run-time efficiency is usually less > >>>>>>>> important for startup code), that's not what you would do. > >>>>>>>> You make your timer class have the required list link > >>>>>>>> pointers in the class, have each registering function > >>>>>>>> declare their timer object with static lifetime, and your > >>>>>>>> registration function links them together. > >>>>>>>> > >>>>>>>> There's no doubt that this takes a bit more effort to write > >>>>>>>> than an off-the-shelf std::vector. But it is vastly simpler > >>>>>>>> than faffing around making your own allocator, avoids the use > >>>>>>>> of any kind of dynamic memory (using neither the standard > >>>>>>>> heap nor a home-made allocation system), and pulls in a tiny > >>>>>>>> fraction of the amount of library code. > >>>>>>>> > >>>>>>>> std::array<> is free - it's just a nice wrapper around a > >>>>>>>> plain C-style array. > >>>>>>> > >>>>>>> List link pointers? Again there is no reason to not use > >>>>>>> std::list with a suitable allocator even on such resource > >>>>>>> constrained hardware and I disagree that the resultant text > >>>>>>> size and ram usage would be any worse than anything you could > >>>>>>> come up with by hand. > >>>>>> > >>>>>> If the memory layout is hard coded at boot time why even bother > >>>>>> pulling in std::list or any kind of container as you don't need > >>>>>> their generic functionality which will almost certainly waste > >>>>>> EEPROM space. With embedded development you often literally > >>>>>> have to worry about every byte you use both in ROM and RAM and > >>>>>> whether the mainloop is going to be fast enough to do its job. > >>>>>> > >>>>> > >>>>> In C++ you don't pay for what you don't use: in the case of a > >>>>> C++ class template only the member functions instantiated will > >>>>> exist in the text segment. > >>>>> > >>>> > >>>> There are always /lots/ of other functions that get pulled in > >>>> from libraries. Remember, for small embedded systems the > >>>> libraries are not shared dynamic libraries that you don't see. > >>>> > >>>> Just for a quick test, I made a minimal C++ main() function and > >>>> compiled for a modern microcontroller. With an empty main(), it > >>>> was about 8400 bytes code of common library code. Adding a > >>>> "std::list<int>" object and using a couple of pops and pushes > >>>> adds about 7 KB code to the program. > >>>> > >>>> If you are making a lot of use of the standard containers, that's > >>>> fine - and there's a lot of overlap and sharing in this extra > >>>> code. But in small systems, this kind of stuff can get > >>>> significant - microcontrollers with 32 KB flash are common, and > >>>> it's nice to be able to program them in C++. In the C++ > >>>> /language/, you pay very little (not quite nothing) for features > >>>> that you don't use, but that does not apply equally to the more > >>>> advanced standard library classes. > >>>> > >>>> It's the same in C, of course - call just one little time > >>>> conversion function and you can find half your flash is used for > >>>> locale handling and time zones. > >>>> > >>>> The needs of embedded systems vary enormously - for many, the > >>>> cost in code space or run-time efficiency for using a std::list > >>>> or std::vector is negligible. But for others, it is very far > >>>> from negligible. > >>>> > >>>> (It is relatively rare that you have to worry about /every/ byte > >>>> of code or data space, however - though it does happen.) > >>> > >>> Try using std::list with a custom allocator as I originally > >>> suggested; also your quote of 7KB sounds highly dubious and > >>> anecdotal. > >> > >> Of course the example of 7 KB is anecdotal - I told you I made a > >> quick test. It doesn't get more anecdotal than that. But no, it > >> is not "highly dubious" - it is really what I got. > >> > >> Every programmer works in a particular area, or small set of areas > >> - /nobody/ has experience and knowledge of all kinds of > >> programming. The trick to having realistic conversations and not > >> appearing arrogant and ignorant is to understand your limitations. > >> You simply don't know what you are talking about when it comes to > >> small-systems embedded programming, and some of the challenges or > >> limitations involved that are different from the kind of > >> programming you are used to. (And similarly there is plenty about > >> the kind of coding /you/ do that I am ignorant about.) > >> > >> So it is /fine/ for you to ask "why don't you just use a std::list > >> with a custom allocator". It is /not/ fine for you to claim people > >> are wrong when they tell you why they don't do that. > >> > >> Why don't I write a custom allocator for std::list and then use > >> that instead of the pointer-based "home made" linked list I have > >> now? I don't do so because it is a lot of effort and will result > >> in bigger, slower, wasteful and vastly more complicated code than > >> the two dozen or so lines of shared C and C++ code I have at the > >> moment that has worked fine for the last 20+ years. It's not > >> unlikely that with a custom allocator and disabled exceptions I > >> could probably get the overhead of std::list down to 2 or 3 KB > >> rather than 7 KB. But that only makes it not quite as inefficient > >> - it still is not close to the efficiency and convenience of the > >> custom solution. And that would come after writing far more code > >> to make the "standard" container work than it took to make a > >> completely custom solution. > > > > So you admit that you *might* be able to get it down to 2KB; so I > > was correct in my analysis and it is you who is arrogant not me. > > Sorry, you seem to be having trouble understanding the conversation. > No, your analysis was not correct - the 7 KB was not "highly > dubious", but an actual measurement on real code that was compiled > and linked (with a case sample size of 1). Disabling exceptions > would have been simple, and it is common practice on small embedded > systems - just as avoiding most standard library containers (and much > of the C and C++ standard libraries) is common practice on small > embedded systems. Leaving exceptions enabled is a fairer test, > however, as it would be realistic for the kind of programmer who > thinks std::list<> and custom allocators is a good idea for the task > in hand. > > > I am also > > well aware of the constraints involved in embedded programming and > > your assumption that I am not is another sign of your arrogance. > > > > I can only assume based on what you write - and you do not write as > someone who has experience in small-systems embedded programming. > > > It is highly unlikely that your solution is more performant than > > std::list; a double linked list is hardly rocket science and > > standard library implementations are generally written by people > > who know what they are doing. > > It would not surprise me if my solution is an order of magnitude > better performing than std::list<>. (Not that I claim the difference > would be significant for the use in question. std::list<> is going > to be pretty efficient, but a very simple custom single linked list > can be considerably more efficient.) As you say, a linked list is > not rocket science - there's no need for custom allocators and > standard library containers when all that's needed is a "pointer to > next node" field in the node structure. > > > > > So you can either apologize or fuck off. > > > > You are joking, yes? You think I should apologize for your > misunderstandings, your unwarranted assumptions, your accusations of > dishonesty and your belief that you know better than anyone else > about fields of programming that are completely beyond your > experience? > > I'm will try to avoid posting more in this subthread unless it > contributes something positive. Hopefully you'll do the same. You continue to prove that you are an arrogant ass who is clueless as far as writing performant code is concerned. Fuck off. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-16 19:18 +0100 |
| Message-ID | <20221016191833.00003f69@reddwarf.jmc.corp> |
| In reply to | #87020 |
On Sun, 16 Oct 2022 18:51:56 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 16/10/2022 17:34, Mr Flibble wrote:
> > On Sun, 16 Oct 2022 17:03:38 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >
> >> On 15/10/2022 13:45, Mr Flibble wrote:
> >>> On Sat, 15 Oct 2022 13:39:24 +0200
> >>> David Brown <david.brown@hesbynett.no> wrote:
> >>>
> >>>> On 14/10/2022 22:01, Mr Flibble wrote:
> >>>>> On Fri, 14 Oct 2022 14:58:54 -0000 (UTC)
> >>>>> Muttley@dastardlyhq.com wrote:
> >>>>>
> >>>>>> On Fri, 14 Oct 2022 14:47:46 +0100
> >>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> wrote:
> >>>>>>> On Fri, 14 Oct 2022 15:27:13 +0200
> >>>>>>> David Brown <david.brown@hesbynett.no> wrote:
> >>>>>>>> Yes, it is always /possible/. But the complications and
> >>>>>>>> effort involved is unlikely to be worth the effort, and
> >>>>>>>> you'd still end up with something taking a massive amount of
> >>>>>>>> code space. (With "massive" being relative to the small code
> >>>>>>>> memories of such systems.)
> >>>>>>>>
> >>>>>>>> It's not uncommon in my coding to build up a few lists at the
> >>>>>>>> startup of the system - lists of "run" functions or software
> >>>>>>>> timers, etc. Modules might register such callbacks or
> >>>>>>>> functions when initialised. In "big system" C++, you might
> >>>>>>>> just use a vector for that - adding your timer objects to
> >>>>>>>> your vector as needed. It's simple and easy in the code.
> >>>>>>>>
> >>>>>>>> But in a resource-constraint embedded system, where
> >>>>>>>> efficiency of code space, ram space and run-time is
> >>>>>>>> important (though run-time efficiency is usually less
> >>>>>>>> important for startup code), that's not what you would do.
> >>>>>>>> You make your timer class have the required list link
> >>>>>>>> pointers in the class, have each registering function
> >>>>>>>> declare their timer object with static lifetime, and your
> >>>>>>>> registration function links them together.
> >>>>>>>>
> >>>>>>>> There's no doubt that this takes a bit more effort to write
> >>>>>>>> than an off-the-shelf std::vector. But it is vastly simpler
> >>>>>>>> than faffing around making your own allocator, avoids the use
> >>>>>>>> of any kind of dynamic memory (using neither the standard
> >>>>>>>> heap nor a home-made allocation system), and pulls in a tiny
> >>>>>>>> fraction of the amount of library code.
> >>>>>>>>
> >>>>>>>> std::array<> is free - it's just a nice wrapper around a
> >>>>>>>> plain C-style array.
> >>>>>>>
> >>>>>>> List link pointers? Again there is no reason to not use
> >>>>>>> std::list with a suitable allocator even on such resource
> >>>>>>> constrained hardware and I disagree that the resultant text
> >>>>>>> size and ram usage would be any worse than anything you could
> >>>>>>> come up with by hand.
> >>>>>>
> >>>>>> If the memory layout is hard coded at boot time why even bother
> >>>>>> pulling in std::list or any kind of container as you don't need
> >>>>>> their generic functionality which will almost certainly waste
> >>>>>> EEPROM space. With embedded development you often literally
> >>>>>> have to worry about every byte you use both in ROM and RAM and
> >>>>>> whether the mainloop is going to be fast enough to do its job.
> >>>>>>
> >>>>>
> >>>>> In C++ you don't pay for what you don't use: in the case of a
> >>>>> C++ class template only the member functions instantiated will
> >>>>> exist in the text segment.
> >>>>>
> >>>>
> >>>> There are always /lots/ of other functions that get pulled in
> >>>> from libraries. Remember, for small embedded systems the
> >>>> libraries are not shared dynamic libraries that you don't see.
> >>>>
> >>>> Just for a quick test, I made a minimal C++ main() function and
> >>>> compiled for a modern microcontroller. With an empty main(), it
> >>>> was about 8400 bytes code of common library code. Adding a
> >>>> "std::list<int>" object and using a couple of pops and pushes
> >>>> adds about 7 KB code to the program.
> >>>>
> >>>> If you are making a lot of use of the standard containers, that's
> >>>> fine - and there's a lot of overlap and sharing in this extra
> >>>> code. But in small systems, this kind of stuff can get
> >>>> significant - microcontrollers with 32 KB flash are common, and
> >>>> it's nice to be able to program them in C++. In the C++
> >>>> /language/, you pay very little (not quite nothing) for features
> >>>> that you don't use, but that does not apply equally to the more
> >>>> advanced standard library classes.
> >>>>
> >>>> It's the same in C, of course - call just one little time
> >>>> conversion function and you can find half your flash is used for
> >>>> locale handling and time zones.
> >>>>
> >>>> The needs of embedded systems vary enormously - for many, the
> >>>> cost in code space or run-time efficiency for using a std::list
> >>>> or std::vector is negligible. But for others, it is very far
> >>>> from negligible.
> >>>>
> >>>> (It is relatively rare that you have to worry about /every/ byte
> >>>> of code or data space, however - though it does happen.)
> >>>
> >>> Try using std::list with a custom allocator as I originally
> >>> suggested; also your quote of 7KB sounds highly dubious and
> >>> anecdotal.
> >>
> >> Of course the example of 7 KB is anecdotal - I told you I made a
> >> quick test. It doesn't get more anecdotal than that. But no, it
> >> is not "highly dubious" - it is really what I got.
> >>
> >> Every programmer works in a particular area, or small set of areas
> >> - /nobody/ has experience and knowledge of all kinds of
> >> programming. The trick to having realistic conversations and not
> >> appearing arrogant and ignorant is to understand your limitations.
> >> You simply don't know what you are talking about when it comes to
> >> small-systems embedded programming, and some of the challenges or
> >> limitations involved that are different from the kind of
> >> programming you are used to. (And similarly there is plenty about
> >> the kind of coding /you/ do that I am ignorant about.)
> >>
> >> So it is /fine/ for you to ask "why don't you just use a std::list
> >> with a custom allocator". It is /not/ fine for you to claim people
> >> are wrong when they tell you why they don't do that.
> >>
> >> Why don't I write a custom allocator for std::list and then use
> >> that instead of the pointer-based "home made" linked list I have
> >> now? I don't do so because it is a lot of effort and will result
> >> in bigger, slower, wasteful and vastly more complicated code than
> >> the two dozen or so lines of shared C and C++ code I have at the
> >> moment that has worked fine for the last 20+ years. It's not
> >> unlikely that with a custom allocator and disabled exceptions I
> >> could probably get the overhead of std::list down to 2 or 3 KB
> >> rather than 7 KB. But that only makes it not quite as inefficient
> >> - it still is not close to the efficiency and convenience of the
> >> custom solution. And that would come after writing far more code
> >> to make the "standard" container work than it took to make a
> >> completely custom solution.
> >
> > So you admit that you *might* be able to get it down to 2KB; so I
> > was correct in my analysis and it is you who is arrogant not me.
>
> Sorry, you seem to be having trouble understanding the conversation.
> No, your analysis was not correct - the 7 KB was not "highly
> dubious", but an actual measurement on real code that was compiled
> and linked (with a case sample size of 1). Disabling exceptions
> would have been simple, and it is common practice on small embedded
> systems - just as avoiding most standard library containers (and much
> of the C and C++ standard libraries) is common practice on small
> embedded systems. Leaving exceptions enabled is a fairer test,
> however, as it would be realistic for the kind of programmer who
> thinks std::list<> and custom allocators is a good idea for the task
> in hand.
>
> > I am also
> > well aware of the constraints involved in embedded programming and
> > your assumption that I am not is another sign of your arrogance.
> >
>
> I can only assume based on what you write - and you do not write as
> someone who has experience in small-systems embedded programming.
>
> > It is highly unlikely that your solution is more performant than
> > std::list; a double linked list is hardly rocket science and
> > standard library implementations are generally written by people
> > who know what they are doing.
>
> It would not surprise me if my solution is an order of magnitude
> better performing than std::list<>. (Not that I claim the difference
> would be significant for the use in question. std::list<> is going
> to be pretty efficient, but a very simple custom single linked list
> can be considerably more efficient.) As you say, a linked list is
> not rocket science - there's no need for custom allocators and
> standard library containers when all that's needed is a "pointer to
> next node" field in the node structure.
>
> >
> > So you can either apologize or fuck off.
> >
>
> You are joking, yes? You think I should apologize for your
> misunderstandings, your unwarranted assumptions, your accusations of
> dishonesty and your belief that you know better than anyone else
> about fields of programming that are completely beyond your
> experience?
>
> I'm will try to avoid posting more in this subthread unless it
> contributes something positive. Hopefully you'll do the same.
I know Fedora isn't an embedded target but I was interested to see what
the difference using std::list makes to elf binary size (symbols
stripped):
int main()
{
}
[leigh@fedora ~]$ g++ foo.cpp
[leigh@fedora ~]$ strip a.out
[leigh@fedora ~]$ ls -l a.out
-rwxr-xr-x 1 leigh leigh 14952 Oct 16 19:09 a.out
#include <list>
int main()
{
std::list<int> l;
l.push_back(42);
}
[leigh@fedora ~]$ g++ foo.cpp
[leigh@fedora ~]$ strip a.out
[leigh@fedora ~]$ ls -l a.out
-rwxr-xr-x 1 leigh leigh 15192 Oct 16 19:10 a.out
[leigh@fedora ~]$ g++ -fno-exceptions foo.cpp
[leigh@fedora ~]$ strip a.out
[leigh@fedora ~]$ ls -l a.out
-rwxr-xr-x 1 leigh leigh 15088 Oct 16 19:10 a.out
So that is just 240 extra bytes to binary file size when using
std::list ctor, dtor and push_back; and even less bytes if we disable
exceptions.
Again, feel free to apologize or fuck off; and don't assume I don't
know what I am talking about again; it is just civilised and basic good
manners to assume the person opposite isn't a dumb fuck.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-16 22:02 +0200 |
| Message-ID | <tiho10$37h35$1@dont-email.me> |
| In reply to | #87023 |
On 16/10/2022 20:18, Mr Flibble wrote:
> On Sun, 16 Oct 2022 18:51:56 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> I'm will try to avoid posting more in this subthread unless it
>> contributes something positive. Hopefully you'll do the same.
>
> I know Fedora isn't an embedded target
Pure genius!
> but I was interested to see what
> the difference using std::list makes to elf binary size (symbols
> stripped):
>
> int main()
> {
> }
>
> [leigh@fedora ~]$ g++ foo.cpp
Right, so you are now trying to show something useful about code sizes
without /any/ optimisations? That's about as useful as a chocolate teapot.
And you are using /dynamic/ libraries, with code from the /dynamic/
libraries for C++ standard libraries and support code? Do you even know
what static linking is, or understand the concept of "bare metal"
coding? (Feel free to say "no" - most C++ programmers go through their
entire careers without knowing anything about such things. They are
only really relevant to small-systems embedded programmers.)
> [leigh@fedora ~]$ strip a.out
> [leigh@fedora ~]$ ls -l a.out
> -rwxr-xr-x 1 leigh leigh 14952 Oct 16 19:09 a.out
>
> #include <list>
>
> int main()
> {
> std::list<int> l;
> l.push_back(42);
> }
>
And now you have code that doesn't actually do anything, so the compiler
can remove it all.
>
> Again, feel free to apologize or fuck off; and don't assume I don't
> know what I am talking about again; it is just civilised and basic good
> manners to assume the person opposite isn't a dumb fuck.
>
I am not assuming anything - you are demonstrating it quite clearly,
again and again.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-16 21:19 +0100 |
| Message-ID | <20221016211903.00004393@reddwarf.jmc.corp> |
| In reply to | #87025 |
On Sun, 16 Oct 2022 22:02:39 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 16/10/2022 20:18, Mr Flibble wrote:
> > On Sun, 16 Oct 2022 18:51:56 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >
>
> >> I'm will try to avoid posting more in this subthread unless it
> >> contributes something positive. Hopefully you'll do the same.
> >
> > I know Fedora isn't an embedded target
>
> Pure genius!
>
> > but I was interested to see what
> > the difference using std::list makes to elf binary size (symbols
> > stripped):
> >
> > int main()
> > {
> > }
> >
> > [leigh@fedora ~]$ g++ foo.cpp
>
> Right, so you are now trying to show something useful about code
> sizes without /any/ optimisations? That's about as useful as a
> chocolate teapot.
See below, dumb fuck.
>
> And you are using /dynamic/ libraries, with code from the /dynamic/
> libraries for C++ standard libraries and support code? Do you even
> know what static linking is, or understand the concept of "bare
> metal" coding? (Feel free to say "no" - most C++ programmers go
> through their entire careers without knowing anything about such
> things. They are only really relevant to small-systems embedded
> programmers.)
The delta is purely the use of std::list which does not rely on any
dynamic libraries: std::allocator will likely be using the default new
operator which will likely be using std::malloc but I doubt we will
see much difference to code size if we write a custom allocator that
doesn't.
>
> > [leigh@fedora ~]$ strip a.out
> > [leigh@fedora ~]$ ls -l a.out
> > -rwxr-xr-x 1 leigh leigh 14952 Oct 16 19:09 a.out
> >
> > #include <list>
> >
> > int main()
> > {
> > std::list<int> l;
> > l.push_back(42);
> > }
> >
>
> And now you have code that doesn't actually do anything, so the
> compiler can remove it all.
And as you pointed out earlier, dumb fuck, I haven't enabled any
optimizations that would cause the code to be optimized out.
>
> >
> > Again, feel free to apologize or fuck off; and don't assume I don't
> > know what I am talking about again; it is just civilised and basic
> > good manners to assume the person opposite isn't a dumb fuck.
> >
>
> I am not assuming anything - you are demonstrating it quite clearly,
> again and again.
The only person demonstrating fucktardedness here is you. You really
should get that Dunning-Kruger Effect seen to, mate.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-10-16 21:24 +0000 |
| Message-ID | <LE_2L.65560$x5w7.64917@fx42.iad> |
| In reply to | #87026 |
Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>On Sun, 16 Oct 2022 22:02:39 +0200
>David Brown <david.brown@hesbynett.no> wrote:
How about some real data, comparing std::list to a custom
class? This c_dlist example dates back to the late 1980s, before
std::list existed and was used in embedded (operating system
and hypervisor) code well into the second decade of the 21st
century.
============ Begin custom list example ============================
#include <stdint.h>
#include <stdio.h>
#include "include/dlist.h"
class c_task : public c_dlist
{
static const size_t MAX_NAMELEN = 32ul;
char task_name[MAX_NAMELEN];
void *task_address;
uint32_t task_priority;
public:
c_task(const char *name, uint32_t priority)
: task_address(0ul), task_priority(priority)
{ init(); snprintf(task_name, sizeof(task_name), "%s", name); }
const char *get_name(void) const { return task_name; }
uint32_t get_priority(void) const { return task_priority; }
};
int
main(int argc, const char **argv, const char **envp)
{
c_dlist listhead;
c_task task1("task1", 15);
c_task task2("task2", 20);
listhead.init();
listhead.append(&task1);
listhead.append(&task2);
c_dlist_iterator di(&listhead);
while (di.next()) {
c_task *tp = (c_task *)di.curr();
printf("Task %s, priority %u\n", tp->get_name(), tp->get_priority());
}
return 0;
}
============ Compiled with -O2, here's 'main'
0000000000400500 <main>:
400500: 55 push %rbp
400501: ba 32 00 00 00 mov $0x32,%edx
400506: b8 31 00 00 00 mov $0x31,%eax
40050b: 53 push %rbx
40050c: 48 81 ec 98 00 00 00 sub $0x98,%rsp
400513: 48 8d 5c 24 10 lea 0x10(%rsp),%rbx
400518: 48 8d 74 24 50 lea 0x50(%rsp),%rsi
40051d: 66 89 54 24 64 mov %dx,0x64(%rsp)
400522: 48 c7 44 24 40 00 00 movq $0x0,0x40(%rsp)
400529: 00 00
40052b: c7 44 24 48 0f 00 00 movl $0xf,0x48(%rsp)
400532: 00
400533: 48 89 e5 mov %rsp,%rbp
400536: c7 44 24 20 74 61 73 movl $0x6b736174,0x20(%rsp)
40053d: 6b
40053e: 66 89 44 24 24 mov %ax,0x24(%rsp)
400543: ba 14 00 00 00 mov $0x14,%edx
400548: 48 c7 84 24 80 00 00 movq $0x0,0x80(%rsp)
40054f: 00 00 00 00 00
400554: c7 84 24 88 00 00 00 movl $0x14,0x88(%rsp)
40055b: 14 00 00 00
40055f: c7 44 24 60 74 61 73 movl $0x6b736174,0x60(%rsp)
400566: 6b
400567: 48 89 64 24 10 mov %rsp,0x10(%rsp)
40056c: 48 89 5c 24 08 mov %rbx,0x8(%rsp)
400571: 48 89 5c 24 50 mov %rbx,0x50(%rsp)
400576: 48 89 64 24 58 mov %rsp,0x58(%rsp)
40057b: 48 89 74 24 18 mov %rsi,0x18(%rsp)
400580: 48 89 34 24 mov %rsi,(%rsp)
400584: eb 13 jmp 400599 <main+0x99>
400586: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
40058d: 00 00 00
400590: 8b 53 38 mov 0x38(%rbx),%edx
400593: 48 89 de mov %rbx,%rsi
400596: 48 89 c3 mov %rax,%rbx
400599: 48 83 c6 10 add $0x10,%rsi
40059d: 31 c0 xor %eax,%eax
40059f: bf 40 07 40 00 mov $0x400740,%edi
4005a4: e8 27 ff ff ff callq 4004d0 <printf@plt>
4005a9: 48 39 eb cmp %rbp,%rbx
4005ac: 48 8b 03 mov (%rbx),%rax
4005af: 75 df jne 400590 <main+0x90>
4005b1: 48 81 c4 98 00 00 00 add $0x98,%rsp
4005b8: 31 c0 xor %eax,%eax
4005ba: 5b pop %rbx
4005bb: 5d pop %rbp
4005bc: c3 retq
4005bd: 0f 1f 00 nopl (%rax)
The only nonlocal branch is to the printf function.
=========Version using std::list
#include <stdint.h>
#include <stdio.h>
#include <list>
class c_task
{
static const size_t MAX_NAMELEN = 32ul;
char task_name[MAX_NAMELEN];
void *task_address;
uint32_t task_priority;
public:
c_task(const char *name, uint32_t priority)
: task_address(0ul), task_priority(priority)
{ snprintf(task_name, sizeof(task_name), "%s", name); }
const char *get_name(void) const { return task_name; }
uint32_t get_priority(void) const { return task_priority; }
};
int
main(int argc, const char **argv, const char **envp)
{
std::list<c_task> listhead;
c_task task1("task1", 15);
c_task task2("task2", 20);
listhead.push_back(task1);
listhead.push_back(task2);
std::list<c_task>::iterator it = listhead.begin();
for (; it != listhead.end(); ++it) {
c_task tp = *it;
printf("Task %s, priority %u\n", tp.get_name(), tp.get_priority());
}
return 0;
}
And here's main:
0000000000400740 <main>:
400740: 41 54 push %r12
400742: b8 31 00 00 00 mov $0x31,%eax
400747: ba 32 00 00 00 mov $0x32,%edx
40074c: 55 push %rbp
40074d: 53 push %rbx
40074e: 48 81 ec a0 00 00 00 sub $0xa0,%rsp
400755: 48 8d 7c 24 10 lea 0x10(%rsp),%rdi
40075a: 48 89 e5 mov %rsp,%rbp
40075d: 48 89 24 24 mov %rsp,(%rsp)
400761: 48 89 64 24 08 mov %rsp,0x8(%rsp)
400766: 48 c7 44 24 30 00 00 movq $0x0,0x30(%rsp)
40076d: 00 00
40076f: c7 44 24 38 0f 00 00 movl $0xf,0x38(%rsp)
400776: 00
400777: c7 44 24 10 74 61 73 movl $0x6b736174,0x10(%rsp)
40077e: 6b
40077f: 66 89 44 24 14 mov %ax,0x14(%rsp)
400784: 48 c7 44 24 60 00 00 movq $0x0,0x60(%rsp)
40078b: 00 00
40078d: c7 44 24 68 14 00 00 movl $0x14,0x68(%rsp)
400794: 00
400795: c7 44 24 40 74 61 73 movl $0x6b736174,0x40(%rsp)
40079c: 6b
40079d: 66 89 54 24 44 mov %dx,0x44(%rsp)
4007a2: e8 c9 01 00 00 callq 400970 <std::list<c_task, std::allocator<c_task> >::_M_create_node(c_task const&) [clone .isra.11]>
4007a7: 48 89 c7 mov %rax,%rdi
4007aa: 48 89 e6 mov %rsp,%rsi
4007ad: e8 4e ff ff ff callq 400700 <std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@plt>
4007b2: 48 8d 7c 24 40 lea 0x40(%rsp),%rdi
4007b7: e8 b4 01 00 00 callq 400970 <std::list<c_task, std::allocator<c_task> >::_M_create_node(c_task const&) [clone .isra.11]>
4007bc: 48 89 e6 mov %rsp,%rsi
4007bf: 48 89 c7 mov %rax,%rdi
4007c2: e8 39 ff ff ff callq 400700 <std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@plt>
4007c7: 48 8b 1c 24 mov (%rsp),%rbx
4007cb: 48 39 e3 cmp %rsp,%rbx
4007ce: 74 5b je 40082b <main+0xeb>
4007d0: 48 8b 43 10 mov 0x10(%rbx),%rax
4007d4: 48 8d 74 24 70 lea 0x70(%rsp),%rsi
4007d9: bf 50 0a 40 00 mov $0x400a50,%edi
4007de: 48 89 44 24 70 mov %rax,0x70(%rsp)
4007e3: 48 8b 43 18 mov 0x18(%rbx),%rax
4007e7: 48 89 44 24 78 mov %rax,0x78(%rsp)
4007ec: 48 8b 43 20 mov 0x20(%rbx),%rax
4007f0: 48 89 84 24 80 00 00 mov %rax,0x80(%rsp)
4007f7: 00
4007f8: 48 8b 43 28 mov 0x28(%rbx),%rax
4007fc: 48 89 84 24 88 00 00 mov %rax,0x88(%rsp)
400803: 00
400804: 48 8b 43 30 mov 0x30(%rbx),%rax
400808: 48 89 84 24 90 00 00 mov %rax,0x90(%rsp)
40080f: 00
400810: 48 8b 53 38 mov 0x38(%rbx),%rdx
400814: 31 c0 xor %eax,%eax
400816: 48 89 94 24 98 00 00 mov %rdx,0x98(%rsp)
40081d: 00
40081e: e8 9d fe ff ff callq 4006c0 <printf@plt>
400823: 48 8b 1b mov (%rbx),%rbx
400826: 48 39 eb cmp %rbp,%rbx
400829: 75 a5 jne 4007d0 <main+0x90>
40082b: 48 8b 3c 24 mov (%rsp),%rdi
40082f: 48 39 ef cmp %rbp,%rdi
400832: 75 0f jne 400843 <main+0x103>
400834: eb 1a jmp 400850 <main+0x110>
400836: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
40083d: 00 00 00
400840: 48 89 df mov %rbx,%rdi
400843: 48 8b 1f mov (%rdi),%rbx
400846: e8 95 fe ff ff callq 4006e0 <operator delete(void*)@plt>
40084b: 48 39 eb cmp %rbp,%rbx
40084e: 75 f0 jne 400840 <main+0x100>
400850: 48 81 c4 a0 00 00 00 add $0xa0,%rsp
400857: 31 c0 xor %eax,%eax
400859: 5b pop %rbx
40085a: 5d pop %rbp
40085b: 41 5c pop %r12
40085d: c3 retq
40085e: 48 8b 3c 24 mov (%rsp),%rdi
400862: 49 89 c4 mov %rax,%r12
400865: 48 39 ef cmp %rbp,%rdi
400868: 74 0d je 400877 <main+0x137>
40086a: 48 8b 1f mov (%rdi),%rbx
40086d: e8 6e fe ff ff callq 4006e0 <operator delete(void*)@plt>
400872: 48 89 df mov %rbx,%rdi
400875: eb ee jmp 400865 <main+0x125>
400877: 4c 89 e7 mov %r12,%rdi
40087a: e8 b1 fe ff ff callq 400730 <_Unwind_Resume@plt>
40087f: 90 nop
Also compiled with -O2.
David's point seems pretty valid to me.
====== same version of the std::list, but using std::list<c_task*>:
0000000000400740 <main>:
400740: 41 54 push %r12
400742: b8 31 00 00 00 mov $0x31,%eax
400747: ba 32 00 00 00 mov $0x32,%edx
40074c: bf 18 00 00 00 mov $0x18,%edi
400751: 55 push %rbp
400752: 53 push %rbx
400753: 48 83 ec 70 sub $0x70,%rsp
400757: 48 89 e5 mov %rsp,%rbp
40075a: 48 89 24 24 mov %rsp,(%rsp)
40075e: 48 89 64 24 08 mov %rsp,0x8(%rsp)
400763: 48 c7 44 24 30 00 00 movq $0x0,0x30(%rsp)
40076a: 00 00
40076c: c7 44 24 38 0f 00 00 movl $0xf,0x38(%rsp)
400773: 00
400774: c7 44 24 10 74 61 73 movl $0x6b736174,0x10(%rsp)
40077b: 6b
40077c: 66 89 44 24 14 mov %ax,0x14(%rsp)
400781: 48 c7 44 24 60 00 00 movq $0x0,0x60(%rsp)
400788: 00 00
40078a: c7 44 24 68 14 00 00 movl $0x14,0x68(%rsp)
400791: 00
400792: c7 44 24 40 74 61 73 movl $0x6b736174,0x40(%rsp)
400799: 6b
40079a: 66 89 54 24 44 mov %dx,0x44(%rsp)
40079f: e8 7c ff ff ff callq 400720 <operator new(unsigned long)@plt>
4007a4: 48 83 f8 f0 cmp $0xfffffffffffffff0,%rax
4007a8: 74 09 je 4007b3 <main+0x73>
4007aa: 48 8d 54 24 10 lea 0x10(%rsp),%rdx
4007af: 48 89 50 10 mov %rdx,0x10(%rax)
4007b3: 48 89 c7 mov %rax,%rdi
4007b6: 48 89 ee mov %rbp,%rsi
4007b9: e8 42 ff ff ff callq 400700 <std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@plt>
4007be: bf 18 00 00 00 mov $0x18,%edi
4007c3: e8 58 ff ff ff callq 400720 <operator new(unsigned long)@plt>
4007c8: 48 83 f8 f0 cmp $0xfffffffffffffff0,%rax
4007cc: 74 09 je 4007d7 <main+0x97>
4007ce: 48 8d 54 24 40 lea 0x40(%rsp),%rdx
4007d3: 48 89 50 10 mov %rdx,0x10(%rax)
4007d7: 48 89 ee mov %rbp,%rsi
4007da: 48 89 c7 mov %rax,%rdi
4007dd: e8 1e ff ff ff callq 400700 <std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@plt>
4007e2: 48 8b 1c 24 mov (%rsp),%rbx
4007e6: 48 39 eb cmp %rbp,%rbx
4007e9: 74 20 je 40080b <main+0xcb>
4007eb: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
4007f0: 48 8b 73 10 mov 0x10(%rbx),%rsi
4007f4: bf e0 09 40 00 mov $0x4009e0,%edi
4007f9: 31 c0 xor %eax,%eax
4007fb: 8b 56 28 mov 0x28(%rsi),%edx
4007fe: e8 bd fe ff ff callq 4006c0 <printf@plt>
400803: 48 8b 1b mov (%rbx),%rbx
400806: 48 39 eb cmp %rbp,%rbx
400809: 75 e5 jne 4007f0 <main+0xb0>
40080b: 48 8b 3c 24 mov (%rsp),%rdi
40080f: 48 39 ef cmp %rbp,%rdi
400812: 75 0f jne 400823 <main+0xe3>
400814: eb 1a jmp 400830 <main+0xf0>
400816: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
40081d: 00 00 00
400820: 48 89 df mov %rbx,%rdi
400823: 48 8b 1f mov (%rdi),%rbx
400826: e8 b5 fe ff ff callq 4006e0 <operator delete(void*)@plt>
40082b: 48 39 eb cmp %rbp,%rbx
40082e: 75 f0 jne 400820 <main+0xe0>
400830: 48 83 c4 70 add $0x70,%rsp
400834: 31 c0 xor %eax,%eax
400836: 5b pop %rbx
400837: 5d pop %rbp
400838: 41 5c pop %r12
40083a: c3 retq
40083b: 48 8b 3c 24 mov (%rsp),%rdi
40083f: 49 89 c4 mov %rax,%r12
400842: 48 39 ef cmp %rbp,%rdi
400845: 74 0d je 400854 <main+0x114>
400847: 48 8b 1f mov (%rdi),%rbx
40084a: e8 91 fe ff ff callq 4006e0 <operator delete(void*)@plt>
40084f: 48 89 df mov %rbx,%rdi
400852: eb ee jmp 400842 <main+0x102>
400854: 4c 89 e7 mov %r12,%rdi
400857: e8 d4 fe ff ff callq 400730 <_Unwind_Resume@plt>
=======And the same with -fno-exceptions:
0000000000400650 <main>:
400650: 55 push %rbp
400651: b8 31 00 00 00 mov $0x31,%eax
400656: ba 32 00 00 00 mov $0x32,%edx
40065b: bf 18 00 00 00 mov $0x18,%edi
400660: 53 push %rbx
400661: 48 83 ec 78 sub $0x78,%rsp
400665: 48 89 24 24 mov %rsp,(%rsp)
400669: 48 89 64 24 08 mov %rsp,0x8(%rsp)
40066e: 48 89 e5 mov %rsp,%rbp
400671: 48 c7 44 24 30 00 00 movq $0x0,0x30(%rsp)
400678: 00 00
40067a: c7 44 24 38 0f 00 00 movl $0xf,0x38(%rsp)
400681: 00
400682: c7 44 24 10 74 61 73 movl $0x6b736174,0x10(%rsp)
400689: 6b
40068a: 66 89 44 24 14 mov %ax,0x14(%rsp)
40068f: 48 c7 44 24 60 00 00 movq $0x0,0x60(%rsp)
400696: 00 00
400698: c7 44 24 68 14 00 00 movl $0x14,0x68(%rsp)
40069f: 00
4006a0: c7 44 24 40 74 61 73 movl $0x6b736174,0x40(%rsp)
4006a7: 6b
4006a8: 66 89 54 24 44 mov %dx,0x44(%rsp)
4006ad: e8 8e ff ff ff callq 400640 <operator new(unsigned long)@plt>
4006b2: 48 83 f8 f0 cmp $0xfffffffffffffff0,%rax
4006b6: 74 09 je 4006c1 <main+0x71>
4006b8: 48 8d 4c 24 10 lea 0x10(%rsp),%rcx
4006bd: 48 89 48 10 mov %rcx,0x10(%rax)
4006c1: 48 89 c7 mov %rax,%rdi
4006c4: 48 89 ee mov %rbp,%rsi
4006c7: e8 64 ff ff ff callq 400630 <std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@plt>
4006cc: bf 18 00 00 00 mov $0x18,%edi
4006d1: e8 6a ff ff ff callq 400640 <operator new(unsigned long)@plt>
4006d6: 48 83 f8 f0 cmp $0xfffffffffffffff0,%rax
4006da: 74 09 je 4006e5 <main+0x95>
4006dc: 48 8d 54 24 40 lea 0x40(%rsp),%rdx
4006e1: 48 89 50 10 mov %rdx,0x10(%rax)
4006e5: 48 89 ee mov %rbp,%rsi
4006e8: 48 89 c7 mov %rax,%rdi
4006eb: e8 40 ff ff ff callq 400630 <std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)@plt>
4006f0: 48 8b 1c 24 mov (%rsp),%rbx
4006f4: 48 39 eb cmp %rbp,%rbx
4006f7: 74 22 je 40071b <main+0xcb>
4006f9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
400700: 48 8b 73 10 mov 0x10(%rbx),%rsi
400704: 31 c0 xor %eax,%eax
400706: bf d0 08 40 00 mov $0x4008d0,%edi
40070b: 8b 56 28 mov 0x28(%rsi),%edx
40070e: e8 dd fe ff ff callq 4005f0 <printf@plt>
400713: 48 8b 1b mov (%rbx),%rbx
400716: 48 39 eb cmp %rbp,%rbx
400719: 75 e5 jne 400700 <main+0xb0>
40071b: 48 8b 3c 24 mov (%rsp),%rdi
40071f: 48 39 ef cmp %rbp,%rdi
400722: 75 0f jne 400733 <main+0xe3>
400724: eb 1a jmp 400740 <main+0xf0>
400726: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
40072d: 00 00 00
400730: 48 89 df mov %rbx,%rdi
400733: 48 8b 1f mov (%rdi),%rbx
400736: e8 d5 fe ff ff callq 400610 <operator delete(void*)@plt>
40073b: 48 39 eb cmp %rbp,%rbx
40073e: 75 f0 jne 400730 <main+0xe0>
40073e: 75 f0 jne 400730 <main+0xe0>
400740: 48 83 c4 78 add $0x78,%rsp
400744: 31 c0 xor %eax,%eax
400746: 5b pop %rbx
400747: 5d pop %rbp
400748: c3 retq
400749: 0f 1f 00 nopl (%rax)
PS: dlist header file used above:
/*
*
* $Id: dlist.h,v 1.5 2011-07-27 23:52:17 scott Exp $
*/
#if !defined(__dlist_h_)
#define __dlist_h_
/**
* Double Linked List.
*
* Implement double linked list operations. An object that
* is included on a double-linked list derives from c_dlist.
*
* Note that locking is the responsibility of the derived class.
*
* <pre>
* class c_object: public c_dlist {
* private-data.
* public:
* public-data.
* };
* </pre>
*
* class c_object constructor or ::init function must invoked the
* c_dlist::init function to initialize the list pointers. If the
* element is not on a list, the list pointers will refer to the
* element itself. The c_dlist::is_onlist method will return <i>true</i>
* if the element is on a list, false if the element is stand-alone.
*
* The c_dlist::insert function will insert a new element before
* the object, while the c_dlist::append function will insert
* a new element after the object. This example shows an object,
* </i>object_1</i> which is already on a c_dlist listhead object
* and the code fragment will insert a new object either before or
* after the object (rather than at the beginning or end of the list).
*
* <pre>
* c_object *object_1;
* c_object *object_2;
*
* object_1.append(object_2); // Link object 2 after object 1
* object_1.insert(object_2); // Link object 2 before object 1
* </pre>
*
* The c_dlist class can also be used as a list-head object by itself,
* however, with this usage, the semantics of the c_dlist::insert and
* c_dlist::append functions change subtly; c_dlist::append will add
* the named object to the beginning of the list, while c_dlist::insert
* will add the named object to the end of the list.
*
* <pre>
* c_dlist object1_list;
* c_object *object_3;
*
* object1_list.append(object_1); // Add to start of list
* object1_list.insert(object_2); // Add to end of list
* object2.append(object_3); // Insert object 3 after object 2.
*
* Objects are removed from a list by invoking the c_dlist::remove
* function on the object being removed.
*
* <pre>
* object_1.remove(); // Remove object1 from list
* </pre>
*/
class c_dlist {
c_dlist *dl_next; ///< Forward Link
c_dlist *dl_prev; ///< Backward Link
public:
void append(c_dlist *);
void init(void);
void insert(c_dlist *);
bool is_empty(void) const;
bool is_onlist(void) const;
c_dlist *flink(void);
c_dlist *blink(void);
void remove(void);
};
/**
* Initialize a list entry. An initialized entry set so that the
* prev and next pointers refer to the element itself (e.g. this).
*/
inline void
c_dlist::init(void)
{
dl_next = dl_prev = this;
}
/**
* Get next element pointer. It is recommend that client code use
* c_dlist_iterator rather than using this function directly.
*
* @returns the next element pointer.
*/
inline c_dlist *
c_dlist::flink(void)
{
return dl_next;
}
/**
* Get previous element pointer. It is recommend that client code use
* c_dlist_iterator rather than using this function directly.
*
* @returns the previous element pointer.
*/
inline c_dlist *
c_dlist::blink(void)
{
return dl_prev;
}
/**
* Insert into double-linked list. The named element is inserted
* before the current element (e.g. <i>this</i>). If the current
* element is a c_dlist being used as a listhead, using insert will
* have the effect of adding the element to the tail of the double-linked
* list.
*
* @param dp The list element to add to the list.
*/
inline void
c_dlist::insert(c_dlist *dp)
{
dp->dl_next = this;
dp->dl_prev = dl_prev;
dl_prev->dl_next = dp;
dl_prev = dp;
}
/**
* Insert into double-linked list. The named element is inserted
* after the current element (e.g. <i>this</i>). If the current
* element is a c_dlist being used as a listhead, using append will
* have the effect of adding the element to the head of the double-linked
* list.
*
* @param dp The list element to add to the list.
*/
inline void
c_dlist::append(c_dlist *dp)
{
dp->dl_next = dl_next;
dp->dl_prev = this;
dl_next->dl_prev = dp;
dl_next = dp;
}
/**
* Remove the element from a double-linked list. This function should
* be called on the object being removed. Calling the c_dlist::remove on
* a c_dlist object being used as a listhead will result in the entire
* list becoming disconnected from the listhead, which is probably not the
* desired behavior. Thus, it is not recommended to call c_dlist::remove
* on a c_dlist being used as a listhead. Remove the objects individually
* instead.
*
* This function is safe to call during a c_dlist_iterator.
*/
inline void
c_dlist::remove(void)
{
if (dl_next == this) {
return;
}
dl_next->dl_prev = dl_prev;
dl_prev->dl_next = dl_next;
dl_prev = dl_next = this;
}
/**
* Determine if element is on a list. Return true if the element is on
* a list, false if not. When called on a c_dlist being used as a listhead,
* this function will indicate whether the list is empty or not (see
* c_dlist::is_empty()).
*
* @returns true if the element is on a list or if the listhead is non-empty
*/
inline bool
c_dlist::is_onlist(void) const
{
return dl_next != this;
}
/**
* Determine if a list is empty. Return true if the c_dlist object being
* used as a listhead has no elements.
*
* @returns true if the list is empty
*/
inline bool
c_dlist::is_empty(void) const
{
return !is_onlist();
}
/**
* Double-Linked list iterator. This class can be used to iterate over
* the members of a double-linked list as represented by a c_dlist object.
*
* The iterator allows deletion of the current element.
*
* <pre>
* c_dlist object_listhead; // List of c_objects
* c_dlist_iterator di(&object_listhead);
*
* while (di.next()) {
* c_object = (c_object *)di.curr();
*
* // operate on object.
*
* // This is safe:
* c_object->remove();
* }
* </pre>
*/
class c_dlist_iterator {
c_dlist *list;
c_dlist *current;
c_dlist *current_next;
c_dlist *current_prev;
public:
c_dlist_iterator(c_dlist *);
c_dlist *curr(void);
bool next(void);
bool prev(void);
void reset(c_dlist * = NULL);
};
/**
* Create a double linked list iterator.
*
* @param dlp The list over which to iterate
*/
inline
c_dlist_iterator::c_dlist_iterator(c_dlist *dlp)
{
list = current = dlp;
current_next = current->flink();
current_prev = current->blink();
}
/**
* Return current element. Immediately after c_dlist_iterator::reset or
* after the c_dlist_iterator::c_dlist_iterator the current element is the
* list head itself. c_dlist_iterator::next must be called to get the first
* element on the list. See example in c_dlist_iterator class documentation.
*
* @returns the current element in the iteration.
*/
inline c_dlist *
c_dlist_iterator::curr(void)
{
return current;
}
/**
* Iterate to the next element in the list. Save the next and previous
* pointers to allow the element to be deleted without perturbing the
* iteration.
*
* @returns true if the element is not the list-head
*/
inline bool
c_dlist_iterator::next(void)
{
current = current_next;
current_next = current->flink();
current_prev = current->blink();
return current != list;
}
/**
* Iterate to the previous element in the list. Save the next and previous
* pointers to allow the element to be deleted without perturbing the
* iteration.
*
* @returns true if the element is not the list-head
*/
inline bool
c_dlist_iterator::prev(void)
{
current = current_prev;
current_next = current->flink();
current_prev = current->blink();
return current != list;
}
/**
* Reset the iterator to the head of the list.
*/
inline void
c_dlist_iterator::reset(c_dlist *new_listhead)
{
if (new_listhead != NULL) {
list = new_listhead;
}
current = list;
current_next = current->flink();
current_prev = current->blink();
}
#endif /* !defined(__dlist_h_) */
/* vim: sw=4 sts=4 sta ts=8:
*/
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-16 14:38 -0700 |
| Message-ID | <tihtjv$37v47$1@dont-email.me> |
| In reply to | #87031 |
On 10/16/2022 2:24 PM, Scott Lurndal wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>> On Sun, 16 Oct 2022 22:02:39 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>
> How about some real data, comparing std::list to a custom
> class? This c_dlist example dates back to the late 1980s, before
> std::list existed and was used in embedded (operating system
> and hypervisor) code well into the second decade of the 21st
> century.
[...]
> inline bool
> c_dlist_iterator::prev(void)
> {
> current = current_prev;
> current_next = current->flink();
> current_prev = current->blink();
> return current != list;
^^^^^^^^^^^^^^^^^
Humm. For some reason flink and blink remind me of the lock-free
Microsoft SList API:
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/singly-and-doubly-linked-lists
Flink and Blink. ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-10-16 14:48 -0700 |
| Message-ID | <tihu89$380fb$1@dont-email.me> |
| In reply to | #87032 |
On 10/16/2022 2:38 PM, Chris M. Thomasson wrote:
> On 10/16/2022 2:24 PM, Scott Lurndal wrote:
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>> On Sun, 16 Oct 2022 22:02:39 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>
>> How about some real data, comparing std::list to a custom
>> class? This c_dlist example dates back to the late 1980s, before
>> std::list existed and was used in embedded (operating system
>> and hypervisor) code well into the second decade of the 21st
>> century.
> [...]
>> inline bool
>> c_dlist_iterator::prev(void)
>> {
>> current = current_prev;
>> current_next = current->flink();
>> current_prev = current->blink();
>> return current != list;
> ^^^^^^^^^^^^^^^^^
> Humm. For some reason flink and blink remind me of the lock-free
> Microsoft SList API:
>
> https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/singly-and-doubly-linked-lists
>
> Flink and Blink. ;^)
Ahhh, I forgot that the lock-free version is in their:
_________________
[...]
Sequenced Singly Linked Lists
A sequenced singly linked list is an implementation of singly linked
lists that supports atomic operations. It is more efficient for atomic
operations than the implementation of singly linked lists described in
Singly Linked Lists.
[...]
_________________
funny how MS words it... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-16 22:39 +0100 |
| Message-ID | <20221016223958.00007201@reddwarf.jmc.corp> |
| In reply to | #87031 |
On Sun, 16 Oct 2022 21:24:59 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Mr Flibble <flibble@reddwarf.jmc.corp> writes: > >On Sun, 16 Oct 2022 22:02:39 +0200 > >David Brown <david.brown@hesbynett.no> wrote: > > How about some real data, comparing std::list to a custom > class? This c_dlist example dates back to the late 1980s, before > std::list existed and was used in embedded (operating system > and hypervisor) code well into the second decade of the 21st > century. You are not comparing like with like: that antiquated C thing is an intrusive list so a better comparison would be with boost::intrusive::list rather than with std::list. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-10-16 23:49 +0000 |
| Message-ID | <_L03L.70233$JZK5.54147@fx03.iad> |
| In reply to | #87033 |
Mr Flibble <flibble@reddwarf.jmc.corp> writes: >On Sun, 16 Oct 2022 21:24:59 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Mr Flibble <flibble@reddwarf.jmc.corp> writes: >> >On Sun, 16 Oct 2022 22:02:39 +0200 >> >David Brown <david.brown@hesbynett.no> wrote: >> >> How about some real data, comparing std::list to a custom >> class? This c_dlist example dates back to the late 1980s, before >> std::list existed and was used in embedded (operating system >> and hypervisor) code well into the second decade of the 21st >> century. > >You are not comparing like with like: that antiquated C thing is an >intrusive list so a better comparison would be with >boost::intrusive::list rather than with std::list. I fail to see what the added complexity buys me. "Antiquated C thing" is completely irrelevent; it is fully legal C++.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-17 09:54 +0200 |
| Message-ID | <tij1ms$3d8dh$1@dont-email.me> |
| In reply to | #87037 |
On 17/10/2022 01:49, Scott Lurndal wrote: > Mr Flibble <flibble@reddwarf.jmc.corp> writes: >> On Sun, 16 Oct 2022 21:24:59 GMT >> scott@slp53.sl.home (Scott Lurndal) wrote: >> >>> Mr Flibble <flibble@reddwarf.jmc.corp> writes: >>>> On Sun, 16 Oct 2022 22:02:39 +0200 >>>> David Brown <david.brown@hesbynett.no> wrote: >>> >>> How about some real data, comparing std::list to a custom >>> class? This c_dlist example dates back to the late 1980s, before >>> std::list existed and was used in embedded (operating system >>> and hypervisor) code well into the second decade of the 21st >>> century. >> >> You are not comparing like with like: that antiquated C thing is an >> intrusive list so a better comparison would be with >> boost::intrusive::list rather than with std::list. > > I fail to see what the added complexity buys me. "Antiquated C thing" > is completely irrelevent; it is fully legal C++. Exactly - there is no need to change straightforward working code that does all it needs to do. Even when starting from scratch, it is important to consider the trade-offs - if a custom solution is more efficient, and efficiency is a concern for the code in question, then that's a point in its favour over standard solutions. For my own use in this particular case, I don't even need a double-linked list - I just need a list that I can add to, iterate through, and very occasionally delete from. (I believe it has been obvious from my first descriptions that I had an intrusive list.)
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-17 17:31 +0100 |
| Message-ID | <20221017173110.000030b6@reddwarf.jmc.corp> |
| In reply to | #87040 |
On Mon, 17 Oct 2022 09:54:03 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 17/10/2022 01:49, Scott Lurndal wrote: > > Mr Flibble <flibble@reddwarf.jmc.corp> writes: > >> On Sun, 16 Oct 2022 21:24:59 GMT > >> scott@slp53.sl.home (Scott Lurndal) wrote: > >> > >>> Mr Flibble <flibble@reddwarf.jmc.corp> writes: > >>>> On Sun, 16 Oct 2022 22:02:39 +0200 > >>>> David Brown <david.brown@hesbynett.no> wrote: > >>> > >>> How about some real data, comparing std::list to a custom > >>> class? This c_dlist example dates back to the late 1980s, > >>> before std::list existed and was used in embedded (operating > >>> system and hypervisor) code well into the second decade of the > >>> 21st century. > >> > >> You are not comparing like with like: that antiquated C thing is an > >> intrusive list so a better comparison would be with > >> boost::intrusive::list rather than with std::list. > > > > I fail to see what the added complexity buys me. "Antiquated C > > thing" is completely irrelevent; it is fully legal C++. > > Exactly - there is no need to change straightforward working code > that does all it needs to do. Even when starting from scratch, it is > important to consider the trade-offs - if a custom solution is more > efficient, and efficiency is a concern for the code in question, then > that's a point in its favour over standard solutions. > > For my own use in this particular case, I don't even need a > double-linked list - I just need a list that I can add to, iterate > through, and very occasionally delete from. (I believe it has been > obvious from my first descriptions that I had an intrusive list.) No you didn't make it obvious that you wanted an intrusive list because if you did we wouldn't have ended up talking about std::list. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-10-17 19:56 +0200 |
| Message-ID | <tik4vq$3gbf2$1@dont-email.me> |
| In reply to | #87046 |
On 17/10/2022 18:31, Mr Flibble wrote: > On Mon, 17 Oct 2022 09:54:03 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 17/10/2022 01:49, Scott Lurndal wrote: >>> Mr Flibble <flibble@reddwarf.jmc.corp> writes: >>>> On Sun, 16 Oct 2022 21:24:59 GMT >>>> scott@slp53.sl.home (Scott Lurndal) wrote: >>>> >>>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes: >>>>>> On Sun, 16 Oct 2022 22:02:39 +0200 >>>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>> >>>>> How about some real data, comparing std::list to a custom >>>>> class? This c_dlist example dates back to the late 1980s, >>>>> before std::list existed and was used in embedded (operating >>>>> system and hypervisor) code well into the second decade of the >>>>> 21st century. >>>> >>>> You are not comparing like with like: that antiquated C thing is an >>>> intrusive list so a better comparison would be with >>>> boost::intrusive::list rather than with std::list. >>> >>> I fail to see what the added complexity buys me. "Antiquated C >>> thing" is completely irrelevent; it is fully legal C++. >> >> Exactly - there is no need to change straightforward working code >> that does all it needs to do. Even when starting from scratch, it is >> important to consider the trade-offs - if a custom solution is more >> efficient, and efficiency is a concern for the code in question, then >> that's a point in its favour over standard solutions. >> >> For my own use in this particular case, I don't even need a >> double-linked list - I just need a list that I can add to, iterate >> through, and very occasionally delete from. (I believe it has been >> obvious from my first descriptions that I had an intrusive list.) > > No you didn't make it obvious that you wanted an intrusive list because > if you did we wouldn't have ended up talking about std::list. > I wrote "You make your timer class have the required list link pointers in the class, have each registering function declare their timer object with static lifetime, and your registration function links them together". That is a quotation from the post before /you/ started talking about std::list, saying "List link pointers? Again there is no reason not to use std::list with a suitable allocator". Given that you quoted my slightly odd-sounding "list link pointers" phrase, I assume you read that the pointers were in the class. Did you also notice I said you would make the timer objects /static/, thus there is no allocation at runtime, and no use for an allocator? Maybe it wasn't obvious. I thought it was, but it's up to others to judge.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-10-17 15:29 +0000 |
| Message-ID | <tijsc6$929$1@gioia.aioe.org> |
| In reply to | #87016 |
On Sun, 16 Oct 2022 16:34:14 +0100 Mr Flibble <flibble@reddwarf.jmc.corp> wrote: >On Sun, 16 Oct 2022 17:03:38 +0200 >David Brown <david.brown@hesbynett.no> wrote: >> Why don't I write a custom allocator for std::list and then use that >> instead of the pointer-based "home made" linked list I have now? I >> don't do so because it is a lot of effort and will result in bigger, >> slower, wasteful and vastly more complicated code than the two dozen >> or so lines of shared C and C++ code I have at the moment that has >> worked fine for the last 20+ years. It's not unlikely that with a >> custom allocator and disabled exceptions I could probably get the >> overhead of std::list down to 2 or 3 KB rather than 7 KB. But that >> only makes it not quite as inefficient - it still is not close to the >> efficiency and convenience of the custom solution. And that would >> come after writing far more code to make the "standard" container >> work than it took to make a completely custom solution. > >So you admit that you *might* be able to get it down to 2KB; so I was >correct in my analysis and it is you who is arrogant not me. I am also >well aware of the constraints involved in embedded programming and your >assumption that I am not is another sign of your arrogance. > >It is highly unlikely that your solution is more performant than >std::list; a double linked list is hardly rocket science and standard >library implementations are generally written by people who know what >they are doing. > >So you can either apologize or fuck off. Proving yet again what an arrogant moron you are. Plus ca change.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-10-17 17:33 +0100 |
| Message-ID | <20221017173301.0000714a@reddwarf.jmc.corp> |
| In reply to | #87043 |
On Mon, 17 Oct 2022 15:29:10 -0000 (UTC) Muttley@dastardlyhq.com wrote: > On Sun, 16 Oct 2022 16:34:14 +0100 > Mr Flibble <flibble@reddwarf.jmc.corp> wrote: > >On Sun, 16 Oct 2022 17:03:38 +0200 > >David Brown <david.brown@hesbynett.no> wrote: > >> Why don't I write a custom allocator for std::list and then use > >> that instead of the pointer-based "home made" linked list I have > >> now? I don't do so because it is a lot of effort and will result > >> in bigger, slower, wasteful and vastly more complicated code than > >> the two dozen or so lines of shared C and C++ code I have at the > >> moment that has worked fine for the last 20+ years. It's not > >> unlikely that with a custom allocator and disabled exceptions I > >> could probably get the overhead of std::list down to 2 or 3 KB > >> rather than 7 KB. But that only makes it not quite as inefficient > >> - it still is not close to the efficiency and convenience of the > >> custom solution. And that would come after writing far more code > >> to make the "standard" container work than it took to make a > >> completely custom solution. > > > >So you admit that you *might* be able to get it down to 2KB; so I was > >correct in my analysis and it is you who is arrogant not me. I am > >also well aware of the constraints involved in embedded programming > >and your assumption that I am not is another sign of your arrogance. > > > >It is highly unlikely that your solution is more performant than > >std::list; a double linked list is hardly rocket science and standard > >library implementations are generally written by people who know what > >they are doing. > > > >So you can either apologize or fuck off. > > Proving yet again what an arrogant moron you are. Plus ca change. I believed I have shown that his figures are bullshit which makes him and by association yourself the morons. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-10-15 11:55 -0700 |
| Message-ID | <efe1c230-2ee5-48da-ad7c-88a3d8bcbe1en@googlegroups.com> |
| In reply to | #86979 |
On Saturday, October 15, 2022 at 12:39:42 PM UTC+1, David Brown wrote: > (It is relatively rare that you have to worry about /every/ byte of code > or data space, however - though it does happen.) My cryptography code is just slightly too big for the microcontroller. So I will be pinching bytes here and there.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web