| David Brown <david.brown@hesbynett.no>: Nov 21 10:54PM +0100 On 21/11/2019 20:30, Keith Thompson wrote: > likely to encounter a very old implementation that doesn't support > <stdint.h> or <cstdint> than to encounter one that does have those > headers but has CHAR_BIT>8.) That is certainly true if by "in the real world" you mean "platforms that support QT" :-) I've worked with a couple of devices that have 16-bit CHAR, and been indirectly connected with a project using one with 32-bit CHAR. These were DSP devices, but are current devices, with new family members being added regularly. But it is very rare that you want much software that will be portable between these sorts of chips and other more "normal" processors. Balancing that, I have a few compilers that I still have occasion to use that don't support <stdint.h> (or C++, for that matter). |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 21 06:20PM +0200 On 21.11.2019 13:53, Soviet_Mario wrote: >> I'm curious about something. Do you have a realistic expectation that >> your code might need to work under an implementation with CHAR_BIT > 8? > no, not at all. Good. I suspect that without lots of porting and testing efforts none of these software pieces would work with CHAR_BIT>8 - neither gambas, neither QT and neither your code. > code that calls the C++ static library and that expects a 8-bit wide > unsigned integral, find its matching type in the C++ code, as they need > to share bitmaps and transparency maps. This is easy, use unsigned char or std::uint8_t. > The bitmaps use 32-bit packed colors+alpha channel, so I was assuming no > difficulty in exchange. This is more tricky because the size of int or long varies much more than char. For example, long is 32 bits in 64-bit MSVC and 64 bits with 64-bit gcc on Linux. However, for your purposes std::uint32_t should work fine. > support for single bit R/W > so I decided to waste some space and to use an addressable unit of 8 > bits for a boolean value This is a common choice, ok. > static library solution would produce a binary with all the needed QT > essentials hard wired in it and no further dependencies (just a guess, > all to be verified). Qt is mostly a GUI library as far as I have understood. Of course it has all bells and whistles like threading support and datetime library and whatever, but these things are nowadays also present in standard C++. So if you are writing some back-end library with no GUI interface involved, you actually should not need Qt at all. |
| Keith Thompson <kst-u@mib.org>: Nov 22 12:37AM -0800 > Am 21.11.19 um 17:20 schrieb Paavo Helde: [...] > } > ? That would make more sense to me than uint32_t and bit-twiddling to > get the channel values. Because #pragma pack is non-standard? If you only care about implementations that support it as an extension, that's fine, but the OP seemed very concerned about portability. An array of uint8_t could also work: typedef uint8_t pixel[4]; enum { red, green, blue, alpha }; Or an array wrapped in a struct to allow assignment. (An array of 4 uint8_t elements is guaranteed to be 32 bits, but a struct containing such an array is not -- but it's a nearly safe assumption that there will be no padding between the elements or at the end.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| David Brown <david.brown@hesbynett.no>: Nov 22 10:10AM +0100 On 22/11/2019 09:37, Keith Thompson wrote: > uint8_t elements is guaranteed to be 32 bits, but a struct containing > such an array is not -- but it's a nearly safe assumption that there > will be no padding between the elements or at the end.) While it is true in theory that a struct can have extra padding at the end (beyond what is needed for an array of the struct to have proper alignment for all members), are there any compilers that have done so in practice? Another option is to cover all bases with a union: typedef union { uint32_t combined; uint8_t rgba[4]; struct { uint8_t red, green, blue, alpha; }; } pixel; _Static_assert(sizeof(pixel) == 4, "This only works on real systems!"); (Watch out for endian issues giving different orders within these parts - that's always a concern for portable code when matching external file formats.) |
| Christian Gollwitzer <auriocus@gmx.de>: Nov 22 07:26AM +0100 Am 21.11.19 um 17:20 schrieb Paavo Helde: > than char. For example, long is 32 bits in 64-bit MSVC and 64 bits with > 64-bit gcc on Linux. > However, for your purposes std::uint32_t should work fine. Why not #pragma pack(1) struct pixel { uint8_t red, green, blue, alpha; } ? That would make more sense to me than uint32_t and bit-twiddling to get the channel values. Christian |
| David Brown <david.brown@hesbynett.no>: Nov 22 09:37AM +0100 On 22/11/2019 07:26, Christian Gollwitzer wrote: > ? That would make more sense to me than uint32_t and bit-twiddling to > get the channel values. > Christian If you are using "pragma pack" (or gcc "packed" attribute), you are probably doing something wrong. It can have some uses when dealing with file formats or network packets with unaligned fields. But most of the cases I see - such as this one (and the OP's first suggestion) are misunderstandings and misuses. When you use "pragma pack", you are making code that is non-standard, non-portable, and can cause trouble interacting with other code. (What happens when you mix pointers to a packed version of your struct, and a non-packed version? Are they compatible? Will your compiler warn you of mixups? My guess is you don't know, and that is not a good thing.) They can lead to inefficiencies - on some compilers and targets, packed fields are accessed by byte. Even when the fields are accessed by their full size, packed means you can get misalignments, which can have a very significant impact on efficiency in some situations. They can lead to restrictions in the code. For some tools, you can't take the address of a packed field, or you might see problems using it because the compiler assumes pointers are properly aligned and that might not be the case for packed fields. In short, "packed" can lead to a lot of extra complications and muck-ups. Perhaps the most insidious aspect is that /usually/ you don't see problems with them. Things will work while you are writing /this/ code, and testing it with /this/ compiler - the problems will turn up later when someone else gets trouble using the code in a different project, and won't know why. So use "packed" only when you /really/ need to - when it is clearly the best solution to the problem. And only when you /really/ understand what it does, and why it might be useful. And clearly, in this case, it is utterly pointless. Just write the struct directly - it is impossible for "pack" to be of any help here. And if you don't understand that, you certainly should not be using "pack". (And you can ask here for more help in understanding, if this post is not sufficient.) |
| Soviet_Mario <SovietMario@CCCP.MIR>: Nov 21 06:07PM +0100 Il 21/11/19 17:20, Paavo Helde ha scritto: > On 21.11.2019 13:53, Soviet_Mario wrote: CUT > nowadays also present in standard C++. So if you are writing > some back-end library with no GUI interface involved, you > actually should not need Qt at all. uhm ... this might sound silly ... but I had not thought a lot about this choice. And actually I find it a darn good advice. I am using an elephant to tow a feather :\ I used it without much thought, but now that you said it, CodeBlocks would be more than enough. Ciao ! -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti Soviet_Mario - (aka Gatto_Vizzato) |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 21 05:34PM On 21/11/2019 16:20, Paavo Helde wrote: >> essentials hard wired in it and no further dependencies (just a guess, >> all to be verified). > Qt is mostly a GUI library as far as I have understood. Of course it has all bells and whistles like threading support and datetime library and whatever, but these things are nowadays also present in standard C++. So if you are writing some back-end library with no GUI interface involved, you actually should not need Qt at all. Qt has too much legacy cruft: QVector? LOL. My alternative, neoGFX, will ultimately win out as I have the distinct advantage of being able to support modern C++ as I have no legacy user-base to worry about. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Öö Tiib" <ootiib@hot.ee>: Nov 24 01:46PM -0800 On Sunday, 24 November 2019 22:53:53 UTC+2, Soviet_Mario wrote: > reading documentation supporting this, It would just ignore > inline suggestion. > Or is it undefinite behaviour ? There are no inline linkage. Functions declared inline (or constexpr that is implicitly inline) have external linkage by default. The sole "benefit" we are guaranteed to get from inline is that we may include same header that defines the inline function in multiple translation units without violating ODR. Same benefit we get with function templates. So removal of inline from non-template function when it is included from multiple translation units leads to ODR violation and undefined behavior. |
| Ralf Goertz <me@myprovider.invalid>: Nov 22 04:03PM +0100 Am Fri, 22 Nov 2019 13:44:09 +0000 > initializer_list, constructing a temporary vector with two elements in > the vector, and that this then initializes Foo, using std::vector's > move constructor. Okay I guessed that much, but why can't the compiler do the latter when there is only one pair of braces? The error message clearly indicates that an initializer list is considered. By the way my original question was why a double brace initializer list doesn't work for std::vector<std::string> pt({{"1","2"}}); (it compiles but throws a std::length_error because the arguments are taken as pointers) but works perfectly for std::vector<int> pt({{1,2}}); On the other hand std::vector<std::string> pt({{"1","2","3"}}); again works as expected (with or without the parenthesis) which I just figured out. So the two string element case fails only because the compiler picks the wrong constructor. I find that odd because the initializer list seems to be the more obvious choice… |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 22 06:56AM On Fri, 2019-11-22, Öö Tiib wrote: > manufacturer or forum or fan-club of that library. For me (if to try > to be straightly honest) the whole product feels like "dirt" or > "digital waste", sorry. The API looks ugly, but maybe the actual simulation is good? > Usenet group comp.lang.c++ is meant to > discuss standard C++ and so such odd libraries are not topical > here. I think the OP is really asking about basic C++ programming, not so much the library. It's still difficult to come up with a good reply though ... he can wrap the code in void helper() { // the code above } but that will just create and start sixLbrApps and then (I guess) immediately destroy it. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| 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