- png data format - 2 Updates
- cmsg cancel <o2a0v4$4bm$4@dont-email.me> - 1 Update
- Ocaml - 1 Update
- deque and vector - 1 Update
| David Brown <david.brown@hesbynett.no>: Dec 07 11:59PM +0100 On 06/12/16 23:12, ruben safir wrote: > like this > http://www.nylxs.com/messages.html?id=543540&archive_learn=2016-12-01 > All it takes is a basic assumption that your not talking to an idiot. I don't assume you are an idiot (though your posting style does not do wonders for the impression you give). I assume you want to learn and understand what you are doing - otherwise you would simply use a pre-written png library. > explain how the intel hardware is set up and who to evaluate the and > learn the problem solving mechanism, so that one can learn to evaluate > these kinds of problems in the future. The Wikipedia article is about Endianness, not Intel hardware, or png file formats. It has a clear enough explanation about what endianness means, a bit of history and examples, some reasons for choosing one endianness type over another, and example code of a way to swap endianness. What more do you want? A special section entitled "why your png decoder is not working on an Intel cpu"? |
| David Brown <david.brown@hesbynett.no>: Dec 08 12:04AM +0100 On 07/12/16 14:35, Scott Lurndal wrote: >> } >> (You also have to watch out for buffer overflows.) > I'd read it as a 32-bit int That /might/ be acceptable, assuming you have control of aligned or unaligned accesses, as well as aliasing issues. > { > return __builtin_bswap32(value); > } That's okay when you have something working and are looking for greater optimisation - or if you are familiar enough with the endianness issues that you are happy to jump straight to an endianness swap routine. But one step at a time is best until the OP is confident in what he is doing here. |
| bleachbot <bleachbot@httrack.com>: Dec 07 11:04PM +0100 |
| Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid>: Dec 07 09:40AM +0100 > | head :: tail -> if elt <= head then elt :: lst else head :: insert elt tail > as a part of an insertation-sort program. > I was trying to translate that into C++, and got this: [...] I don't really see the point in translating this using std::list/forward_list. More interesting would be a direct translation using some sort of cons-list (e.g., as in http://programminggenin.blogspot.fr/2012/10/cons-lists-in-c.html), maybe using smart pointers. (I've found such lists very useful on several occasions, and wonder why the standard library doesn't include this.) -- Alain. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 06 03:30PM -0800 On Tuesday, 6 December 2016 15:35:33 UTC+2, Scott Lurndal wrote: > Don't be silly. Some processors have 128-byte cache lines. If > one is allocating 32-bytes, there is very seldom reason to waste the > other 32 (or 96) bytes. I was saying it not about allocators but about the small arrays that Microsoft's 'std::deque' internally allocates. If the chunks that deque internally allocates are very small then that hurts its performance and usage cases where it is better than vector are rare. |
| 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