- "LLVM 4.0.0 released" - 1 Update
- Why it is important to check what the malloc function returned - 4 Updates
- xkcd, "The History of Unicode" - 2 Updates
| legalize+jeeves@mail.xmission.com (Richard): Feb 12 06:04PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >"How to compile C++ for Windows with clang in Visual Studio 2015" >https://stackoverflow.com/questions/31351372/how-to-compile-c-for-windows-with-clang-in-visual-studio-2015#34011385 >Looks a little tricky. Yes, clang is a different compiler, so it has completely different compile flags. If you use CMake and adjust your compile flags based on the compiler, this isn't such a big deal because CMake should recognize that your compiler is clang and not MSVC. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Josef Moellers <josef.moellers@invalid.invalid>: Feb 12 08:54AM +0100 On 09.02.2018 21:57, Vir Campestris wrote: > The point is however that there are x86 architectures where > sizeof(void*) != sizeof(int). I suspect Josef has only used 32-bit x86 > in flat address mode, and has probably never heard of a selector. You mean CS, DS, SS, and ES? I'm glad I never really had to program using FAR pointers ;-) I never liked it from the start. I programmed on a CDC Cyber (6000 iirc) machine, DEC PDP-10, PDP-11 during study, then a DG NOVA architecture (16 bit only with overlays), then 68k, MIPS, Pyramid, and after that only Linux on x86 (32 and now 64 bit). But FAR pointers are something else than pointer types and scalar vs pointer types in general. And that's what casting is about. OTOH, I agree that you'll have a hard time casting an int into a FAR pointer on a '286 ;-) Josef |
| Juha Nieminen <nospam@thanks.invalid>: Feb 12 08:00AM > It wasn't in the past. Malloc() used to by an O(1) adjustment of a > couple of pointers in the allocator data structures. I don't think that's even possible. If malloc() were the only memory management operation ever made, then sure, it could be done like that. But free() is also used, and the memory blocks freed that way ought to be reused, if possible, by future malloc() calls (else you would end up pretty much effectively with a de-facto memory leak, where the program will consume more and more memory, never reusing memory that it itself is freeing.) Whenever you call malloc(), the memory allocation implemention needs to find a suitably-sized free memory block. When the allocated memory is highly fragmented from thousands of mallocs and frees, this can be quite a complicated task. And the memory fragmentation itself causes a slowdown, at least in processors that use caches (which has been so since at least the 80486, I think. Perhaps even earlier.) Techniques used in some other languages, like memory compaction, can't be used in C/C++. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Feb 12 08:30AM > processors that use caches (which has been so since at least the > 80486, I think. Perhaps even earlier.) Techniques used in some > other languages, like memory compaction, can't be used in C/C++. They can be used on pointers that are either registered or have signature. Pretty possible. But compacting memory burns lot of cycles and you have to update all pointers after that... -- press any key to continue or any other to quit... |
| "James R. Kuyper" <jameskuyper@verizon.net>: Feb 12 08:47AM -0500 On 02/08/2018 02:02 AM, Paavo Helde wrote: > On 8.02.2018 7:23, Juha Nieminen wrote: ... >> The irony is that it's malloc() that's actually hideously expensive... > It wasn't in the past. Malloc() used to by an O(1) adjustment of a > couple of pointers in the allocator data structures. Are you by any chance confusing malloc() with alloc()? |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Feb 12 05:22AM -0500 Lynn McGuire wrote this copyrighted missive and expects royalties: > xkcd, "The History of Unicode" > https://xkcd.com/1953/ Interesting! -- Debian Hint #34: If you want to track Debian sid and have a small download quota or a really slow connection, check out the debdelta package. |
| Noob <root@127.0.0.1>: Feb 12 01:04PM +0100 On 12/02/2018 11:22, Chris Ahlstrom wrote: >> xkcd, "The History of Unicode" >> https://xkcd.com/1953/ > Interesting! See also http://nymag.com/selectall/2017/11/unicode-consortium-fights-over-frowning-poop-emoji.html Unicode has been spiraling out of control. Looks like their end goal is setting mankind 4000 years back. https://en.wikipedia.org/wiki/Egyptian_hieroglyphs |
| 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