- CHAR_BIT is not eight - 21 Updates
- Define object in header file - 2 Updates
- I will cut off cross-posting - 1 Update
- creating a new local variable after a goto - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 15 11:34AM +0200 Am 13.10.2022 um 00:57 schrieb Frederick Virchanza Gotham: > Since I started programming in C/C++ back in the early 2000's, I never encountered a compiler with CHAR_BIT anything other than 8. > Well just now in the past 15 minutes, I was trying to get the code for the 'base58' algorithm to compile for the Texas Instruments F2809 microcontroller using the 'cl2000' compiler. When you write for an architecutre that is so exoic you usually don't need portable code. When you write for non-exotic architectures you usually don't need portability to such exotic architectures. So you usually don't need to care for CHAR_BIT. I've stopped using CHAR_BIT for that and I simply write * 8 if i need the number of bits; I think that's more readable. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 15 11:35AM +0200 >> I suppose there's a good reason why the language standards don't assume >> that 'char' is 8 bits, after all. > A number of current Texas Instruments DSPs have 16 bit chars. And you need portable code for that architectures ? |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Oct 15 02:53AM -0700 On Saturday, October 15, 2022 at 10:35:32 AM UTC+1, Bonita Montero wrote: > Am 13.10.2022 um 10:08 schrieb Mut: > > A number of current Texas Instruments DSPs have 16 bit chars. > And you need portable code for that architectures ? I need to write a cryptography header file to be used on two kinds of microcontroller (Arduino with CHAR_BIT==8, Texas Instruments with CHAR_BIT==16), and also on a Desktop PC x86_64. I've decided to deal with 32-Bit chunks at a time using uint_least32_t. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 15 11:57AM +0200 Am 15.10.2022 um 11:53 schrieb Frederick Virchanza Gotham: > I need to write a cryptography header file to be used on two kinds of microcontroller (Arduino with CHAR_BIT==8, Texas Instruments with CHAR_BIT==16), and also on a Desktop PC x86_64. You need cryptography on a DSP ??? |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Oct 15 03:05AM -0700 On Saturday, October 15, 2022 at 10:57:33 AM UTC+1, Bonita Montero wrote: > > I need to write a cryptography header file to be used on two kinds of microcontroller (Arduino with CHAR_BIT==8, Texas Instruments with CHAR_BIT==16), and also on a Desktop PC x86_64. > You need cryptography on a DSP ??? Yeah I program a commercial product that is sold in two varieties (one being more expensive than the other). The hardware in both varieties is the same, it's only the firmware that's different. So if you buy the cheap one and then want to upgrade to the more expensive one, you get sent a code in an email. You enter the code into the device, it decrypts it and checks that it's correct and then unlocks the features. |
| Muttley@dastardlyhq.com: Oct 15 10:28AM On Fri, 14 Oct 2022 21:01:20 +0100 >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. Same as in C obv. My issue is that it may well be built in a generic way that will include a lot of functions that are not required if you did it manually at the start. eg pop_front(), insert() etc. |
| David Brown <david.brown@hesbynett.no>: Oct 15 01:39PM +0200 On 14/10/2022 22:01, Mr Flibble wrote: > 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.) |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 15 12:45PM +0100 On Sat, 15 Oct 2022 13:39:24 +0200 > 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. /Flibble |
| Muttley@dastardlyhq.com: Oct 15 03:18PM On Sat, 15 Oct 2022 12:45:49 +0100 >> 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. You really Don't Get It do you? Stick to application programming. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 15 04:24PM +0100 On Sat, 15 Oct 2022 15:18:27 -0000 (UTC) > >suggested; also your quote of 7KB sounds highly dubious and > >anecdotal. > You really Don't Get It do you? Stick to application programming. Of course I get it, the question is do you? The only way I can see using a few methods from std::list taking 7KB of space is the overhead of exception handling; perhaps Mr Brown should try it again but with exceptions disabled and a custom allocator that allocates from an explicit memory pool. /Flibble |
| Muttley@dastardlyhq.com: Oct 15 03:34PM On Sat, 15 Oct 2022 16:24:08 +0100 >of exception handling; perhaps Mr Brown should try it again but with >exceptions disabled and a custom allocator that allocates from an >explicit memory pool. I've tried to explain it to you, so has he. You've obviously never done embedded dev, yet as usual you seem to assume you're an expert on the matter. Believe what you like. Something to bear in mind is not all compilers and linkers build in the same way as VC or gcc. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 15 04:39PM +0100 On Sat, 15 Oct 2022 15:34:03 -0000 (UTC) > done embedded dev, yet as usual you seem to assume you're an expert > on the matter. Believe what you like. Something to bear in mind is > not all compilers and linkers build in the same way as VC or gcc. I have done embedded dev and I am well aware of its constraints; all you have got are words completely devoid of any calories. /Flibble |
| Muttley@dastardlyhq.com: Oct 15 03:53PM On Sat, 15 Oct 2022 16:39:05 +0100 >> on the matter. Believe what you like. Something to bear in mind is >> not all compilers and linkers build in the same way as VC or gcc. >I have done embedded dev and I am well aware of its constraints; all Suuuuuuure you have. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 15 04:55PM +0100 On Sat, 15 Oct 2022 15:53:06 -0000 (UTC) > >> not all compilers and linkers build in the same way as VC or gcc. > >I have done embedded dev and I am well aware of its constraints; all > Suuuuuuure you have. You are just showing your ignorance of leveraging C++ in an embedded environment. /Flibble |
| Muttley@dastardlyhq.com: Oct 15 03:57PM On Sat, 15 Oct 2022 16:55:32 +0100 >> Suuuuuuure you have. >You are just showing your ignorance of leveraging C++ in an embedded >environment. "Leveraging"? Run out of arguments and now resorting to buzzwords are we? :) |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 15 04:59PM +0100 On Sat, 15 Oct 2022 15:57:19 -0000 (UTC) > >environment. > "Leveraging"? Run out of arguments and now resorting to buzzwords are > we? :) If you think the word "leveraging" is a buzzword then I can only draw the conclusion that either English isn't your native language or you are incredibly dumb. /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 15 08:11PM +0200 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 15 08:13PM +0200 > embedded dev, yet as usual you seem to assume you're an expert on the matter. > Believe what you like. Something to bear in mind is not all compilers and > linkers build in the same way as VC or gcc. Are there any C++20-compliant compilers other than MSVC, g++ and clang ? Even Intel has moved to clang and partitially LLVM. |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Oct 15 11:55AM -0700 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. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 15 08:03PM +0100 On Sat, 15 Oct 2022 20:11:37 +0200 > 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 |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 15 01:06PM -0700 On 10/15/2022 11:55 AM, Frederick Virchanza Gotham 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. Did you actually write the cipher? Or did you get the code from GitHub? |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 15 01:40PM +0200 Am 14.10.22 um 23:40 schrieb Chris M. Thomasson: > Perhaps I am misunderstanding your main point, however, there are some > nice "header only" libraries. GLM comes to mind: Of course, but when the OP has a compiler that does _not_ support the required features this is not an option. Marcel |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 15 12:47PM -0700 On 10/15/2022 4:40 AM, Marcel Mueller wrote: >> nice "header only" libraries. GLM comes to mind: > Of course, but when the OP has a compiler that does _not_ support the > required features this is not an option. Touche Marcel. I am guilty of an error comprised of posting without properly reading prior context. Sorry everybody. ;^o |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 15 03:27PM +0200 Am 13.10.2022 um 01:34 schrieb olcott: That's as believable as when Amine Moulay Ramdane says that he stop writing toughts that are not related to computing in comp.programming .threads. You have nearly the same motivation. |
| Manfred <noname@add.invalid>: Oct 15 01:56AM +0200 On 10/14/2022 5:45 AM, Lynn McGuire wrote: > Thanks ! > And that method is deprecated already. > Lynn Here's the cppreference link to the properties that have been mentioned: https://en.cppreference.com/w/cpp/language/classes#Properties_of_classes https://en.cppreference.com/w/cpp/language/classes#POD_class |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment