Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #87022
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Newsgroups | comp.lang.c++ |
| Subject | Re: CHAR_BIT is not eight |
| Message-ID | <20221016181139.00002528@reddwarf.jmc.corp> (permalink) |
| References | (11 earlier) <tie65c$2n1ei$1@dont-email.me> <20221015124549.000031e1@reddwarf.jmc.corp> <tih6ga$35lhr$1@dont-email.me> <20221016163414.000003a9@reddwarf.jmc.corp> <tihcrc$3683u$3@dont-email.me> |
| Organization | Jupiter Mining Corporation |
| Date | 2022-10-16 18:11 +0100 |
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
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web