- Why it is important to check what the malloc function returned - 9 Updates
- [OT] neoGFX drop list / combo box - 7 Updates
- c++ concepts - 2 Updates
- [OT] replxx: readline & libedit replacement supporting UTF-8, syntax highlighting, hints, Unix & Windows, BSD licensed - 1 Update
- [OT] DragDropToClipboard 1.0.4 Released - 2 Updates
| Juha Nieminen <nospam@thanks.invalid>: Feb 08 05:23AM >> return a struct from a function by value)? > Actually, I believe late K&R C supported it too, but the users assumed > it was hideously expensive and chose to forget. The irony is that it's malloc() that's actually hideously expensive... |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 08 09:02AM +0200 On 8.02.2018 7:23, Juha Nieminen wrote: >> Actually, I believe late K&R C supported it too, but the users assumed >> it was hideously expensive and chose to forget. > 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. Nowadays it involves (at least some) synchronization of N CPU cores and losing of memory locality which imposes an unpredictable amount of cache misses. Neither multithreading nor CPU caches were a thing to worry about back then. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 08 11:50AM On Thu, 2018-02-08, Juha Nieminen wrote: >> Actually, I believe late K&R C supported it too, but the users assumed >> it was hideously expensive and chose to forget. > The irony is that it's malloc() that's actually hideously expensive... To be fair, the normal alternative was to pass a pointer, and let the function fill in the struct piece by piece. But in this example, yes. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Feb 08 12:59PM +0100 On 08/02/18 12:50, Jorgen Grahn wrote: >> The irony is that it's malloc() that's actually hideously expensive... > To be fair, the normal alternative was to pass a pointer, and let the > function fill in the struct piece by piece. But in this example, yes. That is effectively what happens when a function returns a large struct in C today - it's just that this pointer is hidden behind the scenes. The space for the struct is allocated on the stack of the caller function. Smaller structs are usually returned in registers. The details of when a struct is returned via a hidden pointer or in a register will depend on the target ABI, and possibly the implementation and maybe even compiler flags. |
| Josef Moellers <josef.moellers@invalid.invalid>: Feb 08 05:04PM +0100 On 01.02.2018 21:55, Alf P. Steinbach wrote: > That's C code (hence the lack of cast of `malloc` result, which is > technically correct and preferable in C, opposite of C++: it wouldn't > compile as C++, hence it must be C). You shouldn't ever cast malloc()'s result! If it is a pointer, den C is satisfied. If, however, it was not declared, then C assumes it returns an "int". This is usually not a problem, especially with people who only know the x86 architectures, but eg the M68k (and, probably others too) has two sets of registers: address and data registers and int results are returned in d0 while pointer results in a0! Josef PS I know, it does not belong here. |
| "James R. Kuyper" <jameskuyper@verizon.net>: Feb 08 11:24AM -0500 On 02/08/2018 11:04 AM, Josef Moellers wrote: > You shouldn't ever cast malloc()'s result! If it is a pointer, den C is > satisfied. If, however, it was not declared, then C assumes it returns > an "int". Implicit int was dropped in C99. This is comp.lang.c++, and implicit int was never supported in C++. Casting the value returned by malloc() was a bad idea in C90, a poor idea in later versions of C, and absolutely required in C++. Using malloc() in C++ is permitted, but it is also a bad idea. |
| Vir Campestris <vir.campestris@invalid.invalid>: Feb 08 09:03PM On 08/02/2018 16:04, Josef Moellers wrote: > x86 architectures, but eg the M68k (and, probably others too) has two > sets of registers: address and data registers and int results are > returned in d0 while pointer results in a0! x86 architectures. Like the 8086, where a pointer could be 16 or 20 bits, depending on the memory model? Or the 80286, 16 or (IIRC)24? Andy -- I definitely remember the '286 memory manager giving me headaches... |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 08 05:11PM -0500 On 2/8/2018 4:03 PM, Vir Campestris wrote: > x86 architectures. > Like the 8086, where a pointer could be 16 or 20 bits, depending on the > memory model? Or the 80286, 16 or (IIRC)24? The 80286's 24-bits referred to the physical memory the machine could address, but each single process was limited to 8086 code and could only address 20-bits max itself. You could have multiple 20-bit processes running simultaneously. The 80386 was the first CPU to allow more than 20-bits of memory per process. And the Pentium Pro introduced an initially undocumented mode (now called "Appendex H") that allowed the 32-bit CPU to actually address 36-bits of physical memory, making it a 64 GB CPU. The modern 32-bit Linux and Windows Server kernels support this mode. Linus Torvalds was quoted as saying it was one reason he liked the AMD64 design, was because in 32-bit mode they had to "jump through hoops" to access more than 4 GB of RAM. -- Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9 Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj ------------------------------------------------------------------------- Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA |
| Robert Wessel <robertwessel2@yahoo.com>: Feb 08 04:17PM -0600 On Thu, 8 Feb 2018 21:03:55 +0000, Vir Campestris >x86 architectures. >Like the 8086, where a pointer could be 16 or 20 bits, depending on the >memory model? Or the 80286, 16 or (IIRC)24? Pointers on 16-bit x86 (both real and protected) were either 16 or 32 bits. In real mode those collapsed into only 20 bit worth of linear address space, in protected more it's about 30. But the address handled by the program is still 32 bits, a 16-bit segment (or selector) value, and a 16-bit offset. Now you *could* compress those addresses, especially in real mode to 20 bits, but that would have only been good for storing addresses, the processor could not use them for accessing memory. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 12:50AM Hi! I've just finished implementing the neoGFX drop list / combo box widget: https://www.youtube.com/watch?v=nhqDVFQW_kE&feature=youtu.be neoGFX -- The Ultimate C++ GUI Library -- Coming Soon! /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne 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." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 08 05:07AM -0800 On Wednesday, February 7, 2018 at 7:50:47 PM UTC-5, Mr Flibble wrote: > I've just finished implementing the neoGFX drop list / combo box widget: > https://www.youtube.com/watch?v=nhqDVFQW_kE Not quite done yet. There's no hot tracking on items in the combobox. The "Toggle Editable" feature is awesome though. Is there a callback/ event after a change so it can be written to disk? > neoGFX -- The Ultimate C++ GUI Library -- Coming Soon! You're an excellent developer, Leigh. Your neoGFX library looks very nice. I especially like the transformations on the RGB <-> HSV button. -- Rick C. Hodgin |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 05:55PM On 08/02/2018 13:07, Rick C. Hodgin wrote: > Not quite done yet. There's no hot tracking on items in the combobox. > The "Toggle Editable" feature is awesome though. Is there a callback/ > event after a change so it can be written to disk? If you want to engage with me with on topic discussion then you must first agree to stop spamming this technical Usenet newsgroup with off topic religious nonsense. /Flibble [snip] -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne 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." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Feb 08 01:07PM -0500 On 2/8/2018 12:55 PM, Mr Flibble wrote: >> event after a change so it can be written to disk? > If you want to engage with me with on topic discussion then you must > first agree to... This decision of yours is to our mutual loss. -- Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9 Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj ------------------------------------------------------------------------- Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA |
| Thiago Adams <thiago.adams@gmail.com>: Feb 08 12:17PM -0800 On Thursday, February 8, 2018 at 3:55:19 PM UTC-2, Mr Flibble wrote: > first agree to stop spamming this technical Usenet newsgroup with off > topic religious nonsense. > /Flibble (I don't want to extend this discussion, but this is also my policy and I recommend everyone to do the same until Rick stop the spam) |
| Cholo Lennon <chololennon@hotmail.com>: Feb 08 05:45PM -0300 On 08/02/18 17:17, Thiago Adams wrote: >> /Flibble > (I don't want to extend this discussion, but this is also my policy > and I recommend everyone to do the same until Rick stop the spam) IMO we have 2 problems here: 1- Religious nuts like Rick and Brian (both of them in my kill file) 2- People like Mr Flibble (who is not in my kill file) who insists in answering them. Please Mr Flibble, it has no sense to deal with that kind of bigots! (even if they want to talk about C++) Result: I still see religious sh%*#& everyday in this newsgroup. Don't feed the trolls, just ignore them, sooner or later they'll give up. Regards -- Cholo Lennon Bs.As. ARG |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 08 09:02PM On Thu, 8 Feb 2018 17:55:04 +0000 > If you want to engage with me with on topic discussion then you must > first agree to stop spamming this technical Usenet newsgroup with off > topic religious nonsense. What is the point of this posting? You have previously made the same point a number of times, but you just can't seem to resist: please don't reply to this stuff. I don't especially mind your satirical postings, some of which are quite amusing, but you managed to fill this newsgroup with off-topic nonsense yesterday by keeping on responding to the posts that this generated. Please restrict yourself to your occasional satirical postings and DO NOT REPLY to any postings, whether on topic or off topic, from those making religious postings to this newsgroup. |
| Juha Nieminen <nospam@thanks.invalid>: Feb 08 05:28AM > std::cout << n << std::endl; > return 0; > } And could we *finally* move past the C style from the 80's? We are in 2018 for f's sake. Even in C itself it's nowadays ok, and oftentimes even desirable, to initialize variables when they are declared. In other words: int n = 4; |
| David Brown <david.brown@hesbynett.no>: Feb 08 10:51AM +0100 On 08/02/18 06:28, Juha Nieminen wrote: > Even in C itself it's nowadays ok, and oftentimes even desirable, to > initialize variables when they are declared. In other words: > int n = 4; That has been allowed (and preferred style, for some of us) since at least C89, maybe earlier. And since C99 (two decades ago) you have been able to declare and initialise variables at any point in a block, just like in C++. |
| Marcin Konarski <amok@codestation.org>: Feb 08 08:49AM Sorry for the spam. I wanted to advertise library I worked on. The `replxx` library is a replacement for GNU-readline or for BSD's libedit, it is BSD licensed and its distinguished features are: - user defined live syntax highlighting - user defined hints (as you type) - UTF-8 - works on Linuxes, BSD's, Solaris and (native) Windows - C API - user defined tab-completion - command line history `replxx` is a fork of `linenoise-ng` which itself is a fork of `linenoise`. Link to replxx github repository: https://github.com/AmokHuginnsson/replxx I hope you find this little piece of code useful. Have a great day! |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 08 07:12AM +0100 On 08.02.2018 00:13, Mr Flibble wrote: > * Drag/drop selected files in Explorer to the DragDropToClipboard window > and the full paths of the files will be copied to the clipboard as > Unicode text. I guess this means that NeoGFX (whatever the name) now has good working support for drag n' drop. That's very nice, congrats. But note that copying a path to the clipboard is already in the Windows shift-rightclick menu, menu item "Copy as path". Also, for a path in the active codepage one can drag the filesystem item to a console window. And third, in the old days, before that Windows machinery (or before I discovered it, I'm not sure, but I think it was before that machinery), a reasonable UI for "copy path" was to add a program to the right click menu: it receives the path as command line and can just copy it. > * You can also copy paths by right-clicking file selections in Explorer > and selecting Copy (or use Ctrl+C keyboard shortcut) and then > left-clicking the DragDropToClipboard window. Yes, but easier to just hold down the Shift key in the first place. I know, it's insane of Microsoft to hide that menu item behind a semi-secret keyboard+mouse combo, one can't guess that off-hand. :( > * An "auto copy" mode whereby paths are automatically copied to the > clipboard when files are copied to the clipboard in Explorer (no extra > dragging or clicking required). That's really nice. :) > * regex string replacement on each path Oh noes. > * Information messages displaying how many file paths have been copied. > Screenshot: http://i42.co.uk/stuff/DragDropToClipboard.png > Video: https://www.youtube.com/watch?v=wIKR88F_4co Cheers!, - Alf |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 08 08:38AM +0200 On 8.02.2018 8:12, Alf P. Steinbach wrote: >> [...] >> * regex string replacement on each path > Oh noes. I guess regex could be used for changing C:\Foo\Bar to C:/Foo/Bar or /cygdrive/c/Foo/Bar, these are the operations I sometimes need but have not bothered to automate. |
| 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