- Three 8-hour days on cmake - 6 Updates
- Does std::regex need to be so large? - 2 Updates
- Are there any asm-instructions to support OOP - 1 Update
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 26 09:35PM On Wed, 2020-08-26, Frederick Gotham wrote: ... > Are the makers of 'cmake' mistakenly claiming that it can > cross-compile? I've read their manual in the chapter about We /did/ use cmake for cross-compilation at a previous workplace (because one guy knew how to use it, or claimed to). We may have used separate files for separate targets, though -- it was ten years ago, I wasn't deeply involved, and also not very impressed by that part. ... > Having spent 22 hours fiddling and tinkering around with Makefiles, > I see now that they are of no use in distributed source > code. You're studying Makefiles generated by cmake, aren't you? That's like studying C code generated by yacc -- it's not /meant/ to be readable! /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Aug 26 11:39PM +0200 On 26/08/2020 22:51, Frederick Gotham wrote: > milk in the fridge", are you going to stand there staring at me until > I formally ask you, "Good sir would you like a cup of tea?". > Please re-read my original post and fathom what I might want. Thanks for the clear answer - you just wanted to rant. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Aug 26 02:42PM -0700 On Wednesday, August 26, 2020 at 10:36:13 PM UTC+1, Jorgen Grahn wrote: > (because one guy knew how to use it, or claimed to). We may have used > separate files for separate targets, though -- it was ten years ago, > I wasn't deeply involved, and also not very impressed by that part. It works in two cases: (1) Target = Android smartphones (2) Host is MS-Windows, Target is Linux (and vice versa) I haven't heard of any other case in which 'cmake' can successfully cross-compile. Just got an email here from one of the 'cmake' maintainers, and they're having difficulty cross-compiling a Python engine for 64-Bit ARM (on an x64 host), they can do a successful build but the resultant binary doesn't work. So I think this means that I'll be dismantling all the CMakeLists.txt files I have here and just turning them into simple compilation scripts with one-liners like: aarch64-linux-gnu-gcc -c somefile.c -o somefile.o |
| Siri Cruise <chine.bleu@yahoo.com>: Aug 26 02:49PM -0700 In article <slrnrkdlds.1pog.grahn+nntp@frailea.sa.invalid>, > You're studying Makefiles generated by cmake, aren't you? That's like > studying C code generated by yacc -- it's not /meant/ to be readable! Yacc generated c files don't need to be debugged. The .y file might need debugging and error references should point thither. Build tools routinely trip over gnats to impale themselves on shards of grass. The error references don't point back to the original files. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 26 06:09PM -0400 On 8/26/20 5:35 PM, Jorgen Grahn wrote: >> code. > You're studying Makefiles generated by cmake, aren't you? That's like > studying C code generated by yacc -- it's not /meant/ to be readable! Well, he's asking a question about cmake in a forum devoted to C++ rather than, for instance, <https://discourse.cmake.org/> - what can you expect. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 26 03:21PM -0700 > Well, he's asking a question about cmake in a forum devoted to C++ > rather than, for instance, <https://discourse.cmake.org/> - what can you > expect. *And* in a forum devoted to C (multi-posted to both newsgroups). The advice I gave in comp.lang.c was to post a question on Stack Overflow. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 26 01:52PM -0700 >> colorful at 10 times faster rate. So 100 * 6 * 6 * 8 * 10 ... 288 000 >> times more processing needed. But as in everything there are GPUs that > Do you really think the graphics in his example were 288K times better? ;^) Try to get the following running at 60fps on a 1.5mhz 6809 CPU: https://www.shadertoy.com/view/XtscDl |
| Ian Collins <ian-news@hotmail.com>: Aug 27 10:11AM +1200 On 27/08/2020 08:52, Chris M. Thomasson wrote: >> Do you really think the graphics in his example were 288K times better? > ;^) Try to get the following running at 60fps on a 1.5mhz 6809 CPU: > https://www.shadertoy.com/view/XtscDl Nice! -- Ian. |
| David Brown <david.brown@hesbynett.no>: Aug 26 11:38PM +0200 On 26/08/2020 20:36, Ben Bacarisse wrote: > arrange for vectors of object to have certain properties arranged in > contiguous storage. It would probably be complex to manage, but it > might be possible. I find it hard to imagine how this might work, at least for a language to automate the process - how will it know which properties should be put in contiguous arrays, and what should be kept in individual objects? With C++ (or any other language that lets you have templates, classes, references, and similar abstraction features), the low-level programmer has to make a "vector-of-items" class that is specialised for the type of the items and has contiguous blocks for the required item properties, instead of using something like std::vector<item>. C++ has the machinery you need here - but of course it is possible that a more specialised language (or a future version of C++) could have features that make it easier. > Object locations could be stored contiguously in an instance of a > LocationArray class and linked (vie pointers or indexes) or otherwise > associated with the object or objects that have those locations. I am not sure that you can call this "bad design". Some design decisions are good from one viewpoint, and bad from another. Putting location in the object could be good for modularisation and encapsulation, which could make the coding simpler and clearer - everything you might want to know about the object is there in one place. But it might not make sense from other viewpoints. The lack of single right answers and consideration for multiple viewpoints is part of what makes programming fun! |
| 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