| Scott Newman <scott69@gmail.com>: Jun 23 11:03AM +0200 I've got a lambda which does hashing a key to a size_t and this lambda hasn't any captures. So it could be default-constructible so that I could pass its type as a temmplate-parameter via decltype(lambda). But lambdas are only copy-constructible. For the case of lambdas without a capture I consdider this as a language-weakness. |
| Sam <sam@email-scan.com>: Jun 23 07:11AM -0400 Scott Newman writes: > could pass its type as a temmplate-parameter via decltype(lambda). > But lambdas are only copy-constructible. For the case of lambdas > without a capture I consdider this as a language-weakness. This works in C++20, so install the current version of gcc, and have fun: template<typename T> struct foo : T {}; void bar() { foo<decltype( []{})> baz; } |
| Scott Newman <scott69@gmail.com>: Jun 23 01:36PM +0200 > { > foo<decltype( []{})> baz; > } This ain't a lambda. |
| guinness.tony@gmail.com: Jun 23 05:13AM -0700 On Tuesday, 23 June 2020 12:36:11 UTC+1, Scott Newman wrote: > > foo<decltype( []{})> baz; > > } > This ain't a lambda. Are you claiming that []{} is not a lambda? Good luck with that. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 23 05:07PM +0200 On 23.06.2020 13:11, Sam wrote: >> I've got a lambda which does hashing a key to a size_t and this lambda >> hasn't any captures. So it could be default-constructible so that I >> could pass its type as a temmplate-parameter via decltype(lambda). In C++17 and earlier a lambda can't be used in an unevaluated context. > { > foo<decltype( []{})> baz; > } As I see it the OP is concerned with the formal lack of a default constructor in C++17 and earlier. The current standard is C++17. For a workaround that uses only general portable C++17 or earlier functionality the OP can possibly just define a suitable default constructible type with a function call operator, like this: ------------------------------------------------------------------- #include <utility> template< class Functor > void foo() { for( int i = 1; i <= 3; ++i ) { Functor f; f(); } } #include <iostream> using std::cout, std::endl; auto main() -> int { struct Bah{ void operator()(){ cout << "Bah!" << endl; } }; foo<Bah>(); } ------------------------------------------------------------------- - Alf Links: https://en.cppreference.com/w/cpp/language/lambda |
| Cholo Lennon <chololennon@hotmail.com>: Jun 23 12:23AM -0300 On 6/22/20 4:45 PM, Lynn McGuire wrote: > on compatibility as well as resisting the urge to try to radically > improve C++ by adding a multitude of 'perfect' features to replace > imperfect or unfashionable older ways of doing things"." Quoting the last quote: "...as well as resisting the urge to try to radically improve C++ by adding a multitude of 'perfect' features to replace imperfect or unfashionable older ways of doing things" IMHO they already have failed to accomplish that idea. > And a simple user interface toolkit would be very nice. I am afraid of the cited simplicity... too simple that nobody use it, too simple that looks awful among platforms and, as a result, nobody used it, etc. -- Cholo Lennon Bs.As. ARG |
| Ian Collins <ian-news@hotmail.com>: Jun 23 05:11PM +1200 On 23/06/2020 07:00, Cholo Lennon wrote: >> no, just no. > Yeah :-P it's a mystery to me what would be the scope for "simple > graphics", something half finished perhaps? :-O ASCII art! -- Ian. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 22 10:47PM -0700 >> Yeah :-P it's a mystery to me what would be the scope for "simple >> graphics", something half finished perhaps? :-O > ASCII art! Surely you're not suggesting disallowing EBCDIC art! Turtle graphics, anybody? -- 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 */ |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 23 05:58AM On Tue, 2020-06-23, Ian Collins wrote: > On 23/06/2020 07:00, Cholo Lennon wrote: ... >> Yeah :-P it's a mystery to me what would be the scope for "simple >> graphics", something half finished perhaps? :-O > ASCII art! std::curses! Seriously, I've waited for 25--30 for GUIs to stabilize. It hasn't happened, so I don't think it ever will. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 22 11:12PM -0700 On 6/22/2020 12:00 PM, Cholo Lennon wrote: > Yeah :-P it's a mystery to me what would be the scope for "simple > graphics", something half finished perhaps? :-O > I don't want to see something like Java AWT -> Swing -> JavaFX... Being able to create a PPM. Wait, C and C++ already do that. Sarcasm... C++ needs to fully support GLSL. lol. ;^) https://glm.g-truc.net/0.9.9/index.html |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 22 11:14PM -0700 On 6/22/2020 10:47 PM, Keith Thompson wrote: >> ASCII art! > Surely you're not suggesting disallowing EBCDIC art! > Turtle graphics, anybody? I a strange sense, I would not mind. ;^) Hey man, C++ needs to support PILOT: https://en.wikipedia.org/wiki/PILOT lol. ;^) |
| Juha Nieminen <nospam@thanks.invalid>: Jun 23 06:23AM > I am afraid of the cited simplicity... too simple that nobody use it, > too simple that looks awful among platforms and, as a result, nobody > used it, etc. While I don't think a GUI / graphics library in the standard C++ library would be an excellent idea, I see one small advantage for it. Currently there are like nine billion GUI/graphical libraries out there, none of which follow *any* kind of standard (because there is no standard). It's a complete wild west out there, when it comes to such libraries. Every library developers does whatever he feels like, and almost all such libraries are the product of adding kludges on top of kludges for years until the entire interface for the library is a complete mess. But that's actually a side rant. The main problem is not the variety and poor quality of such libraries. It's the fact that there are so many, and that they do not follow any standard. Such libraries tend to be tied to a particular system and/or a particular set of compilers. Thus there are myriads of programs/projects out there that use some random GUI library, and if you try to compile them you'll find out that they need that library... which depending on your particular setup may be a real PitA to get to compile. Most usually the GUI library will have decent support for unix-like systems... but lack support for Microsoft's compilers for Windows. And even if they have a project file for Visual Studio or something... it will still be a PitA to try to compile it with mingw64 or something. (Believe me, I know from experience.) Almost 99.9% of the time all these libraries designed for unix-like systems will be held hostake by a gigantic "configure" script, without which it's almost impossible to compile the library. (Side rant: I absolutely hate, loathe, detest and wish all such libraries to burn in the deepest pits of hell, especially the ones that contain absolutely nothing that couldn't be written in standard C or C++. Believe me, there are loads and loads of such libraries out there. Libraries that could perfect well be written in 100% portable standard C or C++... but which are *still* being held hostage by a gigantic "configure" script without which it's an astonishing PitA to try to compile the library because the developers, for reasons probably not known even to them, decided to litter the entire billion-lines-of-code library with names that are only created by that configure script. Being held hostage by such a configure script usually means that you can pretty much forget trying to use the library in any environment for which the script has no direct support for, such as cross-compiling for iOS. Or just using mingw64 on Windows. This is espcially aggravating if, as said, the library does nothing that cannot be done in 100% standard C or C++.) Anyway, a *standard* C++ GUI library would mean that you don't need to burden your small project with a dependency to some random third-party library, which may make it really hard for people to compile to some particular environment. I think that's already the case with standard library utilities like <regex> and <filesystem>. Of course a GUI library would be a beast completely on its own league, and it might be more unfeasible than those. |
| Bo Persson <bo@bo-persson.se>: Jun 23 08:37AM +0200 On 2020-06-23 at 08:23, Juha Nieminen wrote: > But that's actually a side rant. The main problem is not the variety and > poor quality of such libraries. It's the fact that there are so many, > and that they do not follow any standard. One standard to rule them all? https://xkcd.com/927/ |
| Siri Cruise <chine.bleu@yahoo.com>: Jun 23 01:08AM -0700 In article <rcqlkj$19ea$1@gioia.aioe.org>, > Interesting article about the latest paper from Bjarne Stroustrup: C++: Algol meets Cobol. -- :-<> 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 |
| Manfred <noname@add.invalid>: Jun 23 01:15PM +0200 On 6/22/2020 9:00 PM, Cholo Lennon wrote: > Yeah :-P it's a mystery to me what would be the scope for "simple > graphics", something half finished perhaps? :-O > I don't want to see something like Java AWT -> Swing -> JavaFX... Agreed! |
| Bart <bc@freeuk.com>: Jun 23 12:16PM +0100 On 23/06/2020 07:23, Juha Nieminen wrote: > Almost 99.9% of the time all these libraries designed for unix-like systems > will be held hostake by a gigantic "configure" script, without which it's > almost impossible to compile the library. This has long been a bone of contention for me. Ridiculously complicated build systems dominated by a 20-40,000-line auto-generated 'configure' Bash script, sometimes bigger than the application source code. Even when the developers deign to support Windows, that is in the form of 'solution' or project files for MS tools, requiring VS to be installed, an even bigger (multi-GB) and cumbersome dependency. Although apparently the recommended solution for building on Windows, to get around the myriad Linux dependencies, is not to get rid of those dependencies, but to install half of Linux on Windows! That is, using Cygwin, MSYS, MSYS2 or WSL. This is even for applications that ought to be portable across OSes anyway. Or portable by subsituting one OS-specific module for another. > Currently there are like nine billion GUI/graphical libraries out there, > none of which follow *any* kind of standard (because there is no standard). I quite like GTK, which is a C library (one I've never managed to use except to manage the simplest test). The interface is a mere 300,000 lines of declarations, across 600 header files. The library itself is a set of 28 or 58 DLL files (I forget how many). I think there are 7000 or 9000 functions in all. So easy to quickly add a plotted graph display to your program and ship with your executable. I think what some people have in mind for a small graphics library is what used to come included with any BASIC of a 1980s microcomputer. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 23 11:26AM >> and that they do not follow any standard. > One standard to rule them all? > https://xkcd.com/927/ It's not so much about following a particular standard, but to have a way of doing it in a way that Will Just Compile as-is in any system with a new-enough compiler, without requiring any third-party libraries (which, as said, might be a real PitA to compile/integrate). Consider for example the C++11 <regex> header: There is no "standard" interface for a regex library, and the C++ committee chose one way of doing it (or, more probably, the Boost developers did). However, if you use this header, it Will Just Compile with any standard-conforming C++ compiler, without requiring any third-party library. If you use a third-party regex library then you would be putting an additional burden to anybody who would want to compile your project on their system (unless you include said library with the project in a manner that requires zero effort from part of the other person to make it work). |
| boltar@nowhere.co.uk: Jun 23 11:27AM On Tue, 23 Jun 2020 12:16:22 +0100 >This has long been a bone of contention for me. Ridiculously complicated >build systems dominated by a 20-40,000-line auto-generated 'configure' >Bash script, sometimes bigger than the application source code. It never used to be like that - back in the day you got a Makefile which needed to be manually edited to work on a particular *nix but that generally took a few minutes at most then type "make" and you were done. >I think what some people have in mind for a small graphics library is >what used to come included with any BASIC of a 1980s microcomputer. You either do graphics properly or don't bother. There's no point doing some cut down mickey mouse API that would be useless to 99% of users. Plus graphics extends beyond the actual graphics - it needs to handle multiple windows and event handling. One think that would be nice to have , not as part of the core language but certainly as a standard API would be sound handling. Its a lot simpler than graphics and would let users escape from the badly documented and hopelessly unintuitive APIs that currently exist , eg ALSA, Apples Core Audio, Pulse Audio. All utterly dreadful. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 23 11:39AM > Even when the developers deign to support Windows, that is in the form > of 'solution' or project files for MS tools, requiring VS to be > installed, an even bigger (multi-GB) and cumbersome dependency. Don't get me even started with how complicated it can be to compile one of those "unix-style" libraries for iOS (or tvOS). The big irony here is that both macOS and iOS are extremely unix-like (in fact, I believe macOS is a genuine Unix, as I think it has been ratified as conforming to the Single Unix Specification; I'm not sure about iOS, but if it isn't, it's pretty damn close), yet you wouldn't believe how complicated it can be to build one of these "unix" libraries for iOS. The main reason is that when you build for iOS you aren't building for the current host system. You are cross-compiling in macOS for an iOS target. And in this particular case it has to be cross-compiled with very specific Xcode commands, using very specific development libraries. Basically none of these configure scripts have been implemented to support anything even resembling this. Often the easiest (although it's not the only) way to compile a library for iOS is to actually add its source code to your iOS project. Problem is, if the source code won't compile without running a gigantic configure script, you are stuck. (Also, adding a billion source files scattered among a million subdirectories to your project can be a real pain, especially if not all of those source files should actually be compiled, eg. if they are some kind of test files or tools that are not part of the library proper.) > I think what some people have in mind for a small graphics library is > what used to come included with any BASIC of a 1980s microcomputer. I think it's actually a bit of an embarrassment for C++ as a language that when a beginner asks me something like "I'm trying to learn C++, how can I draw some lines on screen?" I always have to answer with "uh... well... it's... complicated". I sometimes just recommend them using javascript and a html5 canvas instead. Saves a lot of trouble. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 23 11:43AM > It never used to be like that - back in the day you got a Makefile which > needed to be manually edited to work on a particular *nix but that generally > took a few minutes at most then type "make" and you were done. Too complicated. That's why they invented automake... and cmake... and... Ok, I'll shut up now. :P |
| boltar@nowhere.co.uk: Jun 23 12:11PM On Tue, 23 Jun 2020 11:43:01 +0000 (UTC) >> needed to be manually edited to work on a particular *nix but that generally >> took a few minutes at most then type "make" and you were done. >Too complicated. That's why they invented automake... and cmake... and... Except they often didn't work why configure scripts became popular. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 23 05:22AM -0700 On Tuesday, 23 June 2020 14:43:10 UTC+3, Juha Nieminen wrote: > > took a few minutes at most then type "make" and you were done. > Too complicated. That's why they invented automake... and cmake... and... > Ok, I'll shut up now. :P Just compiling and running short snippet locally is not the reason why we program. The ridiculously complicated build systems come from what we actually need. We need to compile (and cross-compile) programs with different compilers for different platforms under different options; part of it involves installing dependencies, part of it accessing repositories, some part of it is about creating deployable packages, some part is about deploying and executing something automatically and some part of it is about generating reports of any aspect of it. Current tools have been made to simplify such needs in different ways. What is and remains missing is at least something of it being standardized at all. |
| Bart <bc@freeuk.com>: Jun 23 02:13PM +0100 >> what used to come included with any BASIC of a 1980s microcomputer. > You either do graphics properly or don't bother. There's no point doing some > cut down mickey mouse API that would be useless to 99% of users. I think there is; you'd be surprised at how simple some requirements can be; not everyone is developing the latest smartphone app with dazzling graphics. What happens at present is that many don't bother with graphics and just stay with text, which really /is/ a Mickey Mouse way of doing things. Plus > graphics extends beyond the actual graphics - it needs to handle multiple > windows and event handling. There is plotting stuff on the display, and also dealing with interaction or creating dialogs - all the GUI stuff which I find a PITA and try to avoid. But the basic plotting is simple enough. At present, other than text, one option is to plot into an image array, write to a format like PPM, and use an external tool to display. Which is not as handy as directly drawing to the screen from the program, with some minimal interaction, or perhaps there are changing or animated elements that can't be done with a PPM. > graphics and would let users escape from the badly documented and hopelessly > unintuitive APIs that currently exist , eg ALSA, Apples Core Audio, Pulse > Audio. All utterly dreadful. I've dabbled with sound with libraries like SDL, and they leave a lot to be desired. I first played with graphics 40 years ago (putting aside Tektronix termimals); first on experimental colour raster displays connected to a PDP11, then building my own stuff. I can tell you the libraries to get interesting things done needn't be complicated! I can't do any of that now as simply as I used to, because everything is so much bigger and more complicated, and OSes have got in the way. It's just not fun. I do have a little library for my script language, built on top of Win32 API (so could also be adapted to Linux - X11? - but have never bothered). There graphics programming looks like this: w:=gxcreatewindow() # defaults to 640x480, centered to 100'000 do gxpixel(w, random(0..w.dimx-1), random(0..w.dimy-1), 0) end eventloop() # keep it on the screen until close (Screenshot: https://github.com/sal55/langs/blob/master/dots.png) Slightly more elaborate than in BASIC (since it is necessary to create a window and use its handle as parameter to drawing routines). There is also more work behind the scenes to restore the display after it's been obscured, but not something this code needs to worry about. |
| Daniel P <danielaparker@gmail.com>: Jun 23 06:37AM -0700 On Tuesday, June 23, 2020 at 2:23:22 AM UTC-4, Juha Nieminen wrote: > particular environment. > I think that's already the case with standard library utilities like > <regex> and <filesystem>. <regex> doesn't make your point. Compared to other available solutions, its regular expression grammars are less expressive, it lacks support for unicode encodings, and its performance is very poor. My understanding is that the C++ committee thinks that it's unsalvageable, and wants to replace it entirely. But if it takes so much time and effort to get a good regex utility into the language, what would it take to get a good gui library? Daniel |
| boltar@nowhere.co.uk: Jun 23 02:42PM On Tue, 23 Jun 2020 14:13:38 +0100 >interaction or creating dialogs - all the GUI stuff which I find a PITA >and try to avoid. >But the basic plotting is simple enough. At present, other than text, Basic plotting is simple enough - once you've decided where to plot. Will it be a Window? If so how big will it be, will it have a title, whats the background colour, or will be be VGA graphics? And if you go with the window you need to handle creation, destruction, repaint, resize, map/unmap as the basics then there's keyboard and mouse input events. And none of this has anything to do with GUIs, its basic window system programming whether its Windows, X11 or MacOS. It ain't simple. >one option is to plot into an image array, write to a format like PPM, >and use an external tool to display. Which is not as handy as directly Ugh. Who would bother? >I can't do any of that now as simply as I used to, because everything is >so much bigger and more complicated, and OSes have got in the way. It's >just not fun. Perhaps not, but good luck having multiple programs open and visible at the same time on that terminal in 24bit alpha blended colour with overlapping windows. Nostalgia is lovely, but when you actually go back and use the old equipment - I've got some old gear at home too including various 8 bit machines - you realise just how rubbish it is compared to modern machines. |
| 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