- std::byte - 7 Updates
- std::byte - 1 Update
- a std c++ semaphore example... - 1 Update
- OT: Github - 1 Update
- how 2 compress fat bitmap - 4 Updates
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 28 11:41PM +0200 Reading http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0298r3.pdf they say: <quote> Motivation and Scope Many programs require byte-oriented access to memory. Yes, byte access to memory has been the standard in harware since ages. It predates C++, the term byte was coined by Werner Buchholz in July 1956. OK? Since then, a certain sequence of bits make a unit of addressing in byte oriented machines, that since ages are standardized as a sequence of 8 bits. Nowhere is specified what these people think about that "many programs". Not ALL of them? I mean all programs in C and C++ are using that access each day in almost all computers running today. The sizeof() unit is a byte. The C and the C++ languages are byte oriented languages. <quote> Today, such programs must use either the char, signed char, or unsigned char types for this purpose. <end quote> Yes, I always try to use unsigned char for text, signed chars when I store (eventually) small numbers in a byte. A signed byte can also contain quantities like age, that with some effort could arrive at 128, but.... I disgress. What is important is that the existing language already gives you all possible tools for doing all kinds of operations on unsigned chars. They go on: <quote> However, these types perform a "triple duty". Not only are they used for byte addressing, <end quote> ??? what has addressing to do with it? We are speaking of bits, i.e. values. <quote> but also as arithmetic types, <end quote> yes, you can do unsigned integer operations with unsigned chars. So what? <quote> and as character types. <end quote> Yes. You can even store letters in an unsigned chars. All this is already possible with known syntax and known rules. <quote> This multiplicity of roles opens the door for programmer error – such as accidentally performing arithmetic on memory that should be treated as a byte value – and confusion for both programmers and tools. <end quote> No data is provided in the document to prove this assertion. No research is mentioned about what tools are confused and why should we bear yet another syntax rule. The new proposed syntax needs a template definition: namespace std { template <class IntegerType> // constrained appropriately IntegerType to_integer(byte b); } This is doing what now is done with... nothing if you program according to existing rules about common conversions. unsigned char a,b; int c; c = a+b; The operations are done using integer operations. This is the normal way of doing this stuff. Now what does this template bring in new features? They say: <quote> As its underlying type is unsigned char, to facilitate bit twiddling operations, convenience conversion operations are provided for mapping a byte to an unsigned integer type value. They are provided through the function template. <end quote> But we HAVE already rules to do that. But why keep it simple when we can complexify things? Now, suppose that I write the following C program (that also compiles as a C++ program) 1 #include <stdio.h> 2 3 int add(unsigned char a,unsigned char b) 4 { 5 6 for (int i=0; i != b; i = - ~i) { 7 a = - ~a; 8 } 9 return a; 10 } 11 12 int main(void) 13 { 14 unsigned char a = 3; 15 unsigned char b = 2; 16 17 printf("%d %d %d %d %d\n",a,~a,-~a,~-~a,-~-~a); 18 int c = add(a,b); 19 printf("2+3=%d\n",add(a,b)); 20 printf("12+55=%d\n",add(12,55)); 21 } I am doing an addition using only logical operators because addition in binary is based in boolean operations in the actual gates of the hardware. Of course that is not a hardware binary adder but shows that there is no real distinction between arithmetic operations and logical operations in real computers. Is this complexity warranted? What does this bring? namespace std { // IntType would be constrained to be true for is_integral_v<IntType> template <class IntType> constexpr byte& operator<<=(byte& b, IntType shift) noexcept; template <class IntType> constexpr byte operator<<(byte b, IntType shift) noexcept; template <class IntType> constexpr byte& operator>>=(byte& b, IntType shift) noexcept; template <class IntType> constexpr byte operator>>(byte b, IntType shift) noexcept; constexpr byte operator|(byte l, byte r) noexcept; constexpr byte& operator|=(byte& l, byte r) noexcept; constexpr byte operator&(byte l, byte r) noexcept; constexpr byte& operator&=(byte& l, byte r) noexcept; constexpr byte operator~(byte b) noexcept; constexpr byte operator^(byte l, byte r) noexcept; constexpr byte& operator^=(byte& l, byte r) noexcept; } All this stuff does exactly what unsigned char does... And I can substitute unsigned char by "byte" in the program above and it should work isn't it? |
| Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Mar 29 12:04AM +0200 Am 28.03.2017 um 23:41 schrieb jacobnavia: > [...] > Is this complexity warranted? > What does this bring? std::byte does not define arithmetic operators (+,-,*,/,%), so you can not accidentally do arithmetic on them. But i do not understand the need for that either. I can image very few cases where arithmetic is actually harmful, and in most of these cases, a std::bitset or a struct containing bit fields would be the better choice than a quasi-numeric type like std::byte. I do however understand the need to differentiate between a byte and a character. But there's already uint8_t for that... |
| Daniel <danielaparker@gmail.com>: Mar 28 03:25PM -0700 On Tuesday, March 28, 2017 at 5:42:07 PM UTC-4, jacobnavia wrote: > All this stuff does exactly what unsigned char does... It could be argued that C++ is more in need of a character type than a byte type. Daniel |
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 29 12:27AM +0200 Le 29/03/2017 à 00:04, Hergen Lehmann a écrit : > I do however understand the need to differentiate between a byte and a > character. But there's already uint8_t for that... Well, yes! What is the semantic difference between byte and uint8_t? They say: A byte is a collection of bits, But *everything* in a computer is that: a sequence of bits! There isn't anything else in RAM... RAM (and disks, and tapes, etc) are just that: a sequence of bits. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 29 12:11AM +0100 On 28/03/2017 23:25, Daniel wrote: >> All this stuff does exactly what unsigned char does... > It could be argued that C++ is more in need of a character type than a byte > type. char. /Flibble |
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 29 01:23AM +0200 Le 29/03/2017 à 01:09, Stefan Ram a écrit : > For example, when writing a 1 to bit 0 turns on the > light, bit 1 the dish washer, and bit 2 the music. > But then, one possibly might use bitfields for such a case. Yes, there are bitfields. And if you define: struct switches { int light:1; int padding:7; int sound:1; int padding1:7; }; there is no math operations defined for that type , so all constraints supposed to be gained by "byte" are ALREADY THERE. struct switches a,b,c; c = a+b; // Error. Unless you overload addition of course, but why would you do that? |
| jacobnavia <jacob@jacob.remcomp.fr>: Mar 29 01:27AM +0200 Le 29/03/2017 à 00:04, Hergen Lehmann a écrit : > std::byte does not define arithmetic operators (+,-,*,/,%), so you can > not accidentally do arithmetic on them. The above program proves that it is indeed possible. Anyway if you define struct switches { int lighisOn:1; int soundisOn:1; }; you can't do any addition or arithmetic operations on this type. struct switches a,b,c; c=a+b; // error so, you ALREADY have the advantages of "byte". |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 28 11:09PM >But *everything* in a computer is that: a sequence of bits! There also are abstractions like numbers, strings, bank accounts, windows, circles, colors ... (at least in a higher-level programming language or in software engineering). A bit also is an abstraction, but it is an abstraction that is (at least partially) supported already by machine language. But machine language has better support for words, because words are directly addressable, while a bit often is not directly addressable. A word in machine language usually is an arithmetic entity as well. A byte abstraction without arithmetics can apply to a register where arithmetics would absolutely make no sense. For example, when writing a 1 to bit 0 turns on the light, bit 1 the dish washer, and bit 2 the music. But then, one possibly might use bitfields for such a case. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 28 01:59PM -0700 On 3/25/2017 7:53 PM, Chris M. Thomasson wrote: > kill, go ahead and take a look at the code in here: > http://pastebin.com/raw/Q7p6e7Xc > (no ads in this link to pastebin) [...] Can anybody else run this? |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 28 08:06PM On Mon, 2017-03-27, Richard wrote: >>object files and executables must go. >>My impression is trying to support that makes things a lot harder. > It's mind numbingly trivial if you use CMake :) Perhaps, but the cost of copying the source code to whereever you want to build, and building it there, is very small today. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Mar 27 08:42PM -0700 On 3/27/2017 8:26 AM, fir wrote: > even compressing each pixel into index form - thus reducing 24 bit of color into loke 6-12 bit of index would spare to half or 1/4 of oryginal size.. yet more elaborate ways of compresing (exploring the fact that there are regular patterns of colors not chaotic pixels) could be used (zip packs this 12 MB to 80 kB rar packs 12 MB to 60kB) > the question is - what algorithm to use to pack it - it could be reasonably simple to write but also maybe something more effective then if i would just turn colors to palette entries? > what do you think? Perhaps something like keeping the stride of like colors, just thinking out loud here: struct stride { uint16_t len; // 0xFFFF worth of space }; ((stride.len & 0xFFF0) >> 4) gets the stride field (stride.len & 0x000F) gets the meta data describing the strides details We have a max stride length of 0xFFF, and 0xF worth of meta data... How many total colors can you have on a map? What about classes of colors, like shades of green? |
| fir <profesor.fir@gmail.com>: Mar 28 12:50AM -0700 W dniu wtorek, 28 marca 2017 05:42:17 UTC+2 użytkownik Chris M. Thomasson napisał: > We have a max stride length of 0xFFF, and 0xF worth of meta data... > How many total colors can you have on a map? What about classes of > colors, like shades of green? ye i will try some RLE, colors as i said i be used i think at most couple of thousands, may probably try at first convert 24bit pixel into 8bit-length 16-bit index or something more elaborate -> read byte if 7th bit up - read 7 bytes al length next 16 as index if 7th bit down - read next 15 bit as index will try it later |
| fir <profesor.fir@gmail.com>: Mar 28 12:51AM -0700 W dniu poniedziałek, 27 marca 2017 23:16:59 UTC+2 użytkownik Rick C. Hodgin napisał: > about!! > Thank you, > Rick C. Hodgin gett of stupidity buffed idiot |
| fir <profesor.fir@gmail.com>: Mar 28 10:06AM -0700 W dniu poniedziałek, 27 marca 2017 23:50:09 UTC+2 użytkownik fir napisał: > = > (17 bits * 4M/16 = about 500 KB) + (94k*48bytes == 5 MB) > not effective, unles maybe 'palette' would be compressed i was thinking a bit and this in fact maybe could be some way it gives good base of 250k indexes (of 17 bits) (0.5 MB) palette is damn heavy say 100k * block size - it could be effective if this block size would be in a range of 5 to 10 bytes, raw block is 16 pixels of 24bits = 48 bytes but could be compressed as at most 16 colors in each block (and usually there would be less, sometimes like only 2,3,4, probably quite often 8 or less ) - if so such 16 pixel block could be encoded in at most 16*4bits = 8 bytes and probably most often encoded as 16*3 bits = 6 bytes, and sometimes (but probably also quite often as 16*2 bits = 4 bytes ) besides that also some palettes need to be build, i dont know how many but probably like 10k plettes or less each palette like maybe 5-15 bytes long so it would yeild maybe to 17b * 250k = 0.55 MB base 7*100k of blocks = 0.7 MB of blocks + 10k * 10 bytes - 0.1 MB of palettes - that would be like 1.35 MB of a result.. that i would be starting to get satisfied (if zip gives 12MB- > 0.8 MB imo the 12MB->1.3 MB of home easy packing would be starting to get satisfied the code would be also not to much hard to write in one evening - though im weary now and get no mood to code it now also could try this RLE but also to weary now |
| 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