- "C++ Modules Might Be Dead-on-Arrival" - 6 Updates
- "Is C++ fast?" - 2 Updates
| David Brown <david.brown@hesbynett.no>: Jan 30 09:58PM +0100 On 30/01/2019 20:39, Melzzzzz wrote: >> to use a single new C++ feature. > Build tools have to change for sure. Also having modules unecessites > having .h files. I can't see why common build tools like "make" would have any problems here. Sure, you might not be able to compile everything in parallel - but "make" (or ninja, or whatever) will handle it fine. If you have enough modules for the build speed and parallel compilation to matter, there will be plenty of opportunity for parallelising. |
| David Brown <david.brown@hesbynett.no>: Jan 30 10:00PM +0100 On 30/01/2019 18:45, Bart wrote: > not having a module system, and having to construct the headers - what > are effectively the export files of the proposed scheme (I don't know > how it works either) - by hand. It is almost always possible to break your circular dependencies by using a third module that contains the parts needed by both A and B. If C++ modules can be made in a way that allows circular dependencies, great. If not, it's certainly not the end of the module idea. |
| scott@slp53.sl.home (Scott Lurndal): Jan 30 09:33PM >using a third module that contains the parts needed by both A and B. If >C++ modules can be made in a way that allows circular dependencies, >great. If not, it's certainly not the end of the module idea. Back in the late 70's/early 80's, the Burroughs MCP/IX operating system had reached a point where it needed to be re-written (being fifteen years old at that point, and hardware had gotten much more capable in the intervening years). The MCP at that point was written in assembler language, some of it over fifteen years old; to write a new, modern operating system capable of managing the greatly expanded hardware resources (amount of memory, new MMU, number of processors, I/O controllers, devices) in assembler would require a great deal of labor, be prone to error and difficult to maintain. So, a new language was proposed by the Languages department to use for the Operating system. This language, based very roughly on Modula, supported independently compiled modules using a centralized interface definition (called a MID - Module Interface Definition). Sort of a master include file, if you will. The MID needed to be compiled _before_ any module that used it; much like the proposed C++ Modules capability. The new language was called SPRITE and the new operating system (MCP/VS2.0) was written -mostly- in that language (with portions of the prior MCP living on as assembler files linked in with the SPRITE ICMs (Independently Compiled Modules). In practice, while the concept worked, the MID quickly became a bottleneck for the developers - every interface change between modules (and early in the development process, this occured very frequently) needed a MID change. Now, source code control systems at the time were uncommmon (SCCS became available for Unix systems about then, RCS came a bit later on BSD systems); the developers used a Master + patch approach; However, most changes required patching the MID as well which required careful coordination when the patches were "checked in" (eventually consolidated into the single master file for each module) because at the time (the end of the punched card era), each source code line required a unique sequence number (typically in columns 72-80, but dependent upon the language); making sure the patches being merged didn't overlap was a time-consuming process (later, partially automated as part of the resequencer that needed to be run periodically to expand the gaps between sequence numbers for future changes). That experience soured me somewhat on the idea of the type of interface definition proposed by the C++ Modules proposal. As one who routinely builds a 1.5+ million line C++ application (most of that in header files), I don't see compile time as a problem (full builds take a few minutes, typical incremental builds during development take a few seconds); nor do I believe that preventing ODR violations is valuable enough to justify adding Modules TS or P0947R0(Atom) to C++. YMMV. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0986r0.html |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 30 10:18PM > compilers from accepting code like this (albeit with warnings): > void f(){g("two"); g(&f);} > void g(float x){}; No. You don't have type check. I meant no need for prototypes. > The problem I mean is illustrated here, with a fantasy version of C that > has modules: This problem is solved in other languages. You either parse all library files as single file, or .... -- press any key to continue or any other to quit... |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jan 30 10:19PM > "make" (or ninja, or whatever) will handle it fine. If you have enough > modules for the build speed and parallel compilation to matter, there > will be plenty of opportunity for parallelising. No problems with make. Compilers must accomodate. -- press any key to continue or any other to quit... |
| David Brown <david.brown@hesbynett.no>: Jan 31 12:04AM +0100 On 30/01/2019 23:19, Melzzzzz wrote: >> modules for the build speed and parallel compilation to matter, there >> will be plenty of opportunity for parallelising. > No problems with make. Compilers must accomodate. Ah, when you said "Build tools have to change for sure", I thought you meant tools like "make". Obviously compilers have to change to support the new feature! |
| Daniel <danielaparker@gmail.com>: Jan 30 12:50PM -0800 On Wednesday, January 30, 2019 at 2:48:16 PM UTC-5, Mr Flibble wrote: > I see you made basic_json template in November last year; you been copying > my JSON library that also does that? jsoncons has had basic_json template since Feb 2014 :-) I think you're referring to the file named basic_json.hpp, earlier it was in json.hpp. Best regards, Daniel |
| Daniel <danielaparker@gmail.com>: Jan 30 01:11PM -0800 On Wednesday, January 30, 2019 at 11:57:58 AM UTC-5, Richard wrote: > >or > >json j = parse<json>(source); > Not this. Thanks for the feedback, it's appreciated. Daniel |
| 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