- Let's call the <=> operator "trike" because of the math term - 17 Updates
- Available C++ Libraries FAQ - 1 Update
- Std::any vs std::optional - 3 Updates
| boltar@cylonHQ.com: May 14 08:34AM On Sat, 12 May 2018 13:51:58 -0700 (PDT) >the Win32 nor the POSIX APIs qualify. I'm curious - what role did you >understand the term "language" to play in that context, or did you >simply ignore it? The posix API libraries come with every C/C++ compiler installed on every unix system since god knows when. IMO that makes them standard. >I've tried it - it's not very difficult. I've spent most of the last 22 >years writing C code that makes little or no use of POSIX-specific >features (because it has no need to) or Win32 (because it wasn't being So in other words you have written anything particularly complex since you won't have created or read directories or other filesystem operations more complex than file I/O, you won't have written any networking code, any code that involves multi process or multi threading , any memory management more complex than malloc or new, regular expressions, signals pipes, timing blah blah blah. But I'm sure it was a fantastic Hello World program that you ended up with. |
| David Brown <david.brown@hesbynett.no>: May 14 12:22PM +0200 >> simply ignore it? > The posix API libraries come with every C/C++ compiler installed on every > unix system since god knows when. IMO that makes them standard. What about every C and C++ compiler that is /not/ for a unix system? There are a great many compilers targeting other systems than *nix - most embedded systems have no use for Posix. The Posix API is /a/ standard, certainly - it is just not part of the C++ standard. > complex than malloc or new, regular expressions, signals pipes, timing blah > blah blah. > But I'm sure it was a fantastic Hello World program that you ended up with. Lots of people write code doing all sorts of things on *nix, Windows, or other systems, without using the low-level systems-specific APIs directly. People writing graphics programs in C++ on *nix will typically use something like wxwidgets or QT, along with the standard C++ libraries. They don't need to go near the Posix API in order to get threads, locks, file access, memory, networking, or whatever else they want - and as a bonus, they have a least a good step towards cross-platform support. For non-graphics work, you could use the same toolkits or one of a myriad of others. Sure, the *nix ports of QT, wxwidgets, and other libraries may use Posix calls in their implementation. But the /application/ code doesn't need it - and it does not care how the functions are implemented. |
| boltar@cylonHQ.com: May 14 10:53AM On Mon, 14 May 2018 12:22:26 +0200 >> unix system since god knows when. IMO that makes them standard. >What about every C and C++ compiler that is /not/ for a unix system? >There are a great many compilers targeting other systems than *nix - There are certain libraries that are standard on certain systems is my point. >typically use something like wxwidgets or QT, along with the standard >C++ libraries. They don't need to go near the Posix API in order to get >threads, locks, file access, memory, networking, or whatever else they Sure, if they're lego brick programmers they'll use a load of bloated high level APIs with the "networking" probably being some horrendous REST HTTP stack which takes 10 to 100x the bandwidth of something proprietary written using sockets code. But then those sorts of people usually end up gravitating towards java, python or javascript in the end anyway. >Sure, the *nix ports of QT, wxwidgets, and other libraries may use Posix >calls in their implementation. But the /application/ code doesn't need >it - and it does not care how the functions are implemented. Depends what its doing. |
| Paavo Helde <myfirstname@osa.pri.ee>: May 14 02:28PM +0300 > which takes 10 to 100x the bandwidth of something proprietary written using > sockets code. But then those sorts of people usually end up gravitating towards > java, python or javascript in the end anyway. I gather this means you have never heard about boost::asio either. How about learning a bit about a topic before starting to berate it? |
| David Brown <david.brown@hesbynett.no>: May 14 01:50PM +0200 >> What about every C and C++ compiler that is /not/ for a unix system? >> There are a great many compilers targeting other systems than *nix - > There are certain libraries that are standard on certain systems is my point. Yes, that much is true. It wasn't what you said, however. And it does not mean that you /have/ to use these libraries for programming on those systems - you certainly don't need to do so directly. > which takes 10 to 100x the bandwidth of something proprietary written using > sockets code. But then those sorts of people usually end up gravitating towards > java, python or javascript in the end anyway. And I suppose you think /real/ men use raw X api calls? Some people don't like to reinvent wheels if they can avoid it. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 14 08:46AM -0400 >> simply ignore it? > The posix API libraries come with every C/C++ compiler installed on every > unix system since god knows when. IMO that makes them standard. Well, of course: "In the late 1980s, an open operating system standardization effort now known as POSIX provided a common baseline for all operating systems; IEEE based POSIX around the common structure of the major competing variants of the Unix system, publishing the first POSIX standard in 1988. In the early 1990s, a separate but very similar effort was started by an industry consortium, the Common Open Software Environment (COSE) initiative, which eventually became the Single UNIX Specification (SUS) administered by The Open Group. Starting in 1998, the Open Group and IEEE started the Austin Group, to provide a common definition of POSIX and the Single UNIX Specification, which, by 2008, had become the Open Group Base Specification." <https://en.wikipedia.org/wiki/Unix#Standards> So it's not particularly odd that unix systems have POSIX API libraries. And, as I said above, there's nothing wrong with calling the "Open Group Base Specification" a standard. However, it's an OPERATING SYSTEM standard. C and C++ have LANGUAGE standards, which is a very different thing. There's plenty of implementations of C and C++, targeting platforms that don't conform to the Open Group Base Specification, which therefore do not provide POSIX API libraries. which doesn't prevent them from fully conforming to the relevant LANGUAGE standard, because those libraries are not LANGUAGE standard libraries. It's the distinction between operating system standard libraries and language standard libraries that you have refused to acknowledge. The meaning of "standard" has nothing to do with what's wrong with your statements. Also, you seem to have the connections between those standards somewhat backwards. The current version of the Open Group Base Specification describes a command line utility named C99 which "shall accept source code conforming to the ISO C standard" (a requirement that is far less constraining than it might appear to be - but I won't go into that). Previous versions of the standard(s) called it C89, and the standard explicitly promises that it will exist in future versions of the standard with a name that reflects (in a currently unpredictable manner) changes to the C standard. Despite nominally having been unified, the "Open Group Base Specification" has several varieties of optional features, and as a result, has the following to say about c99: "On systems providing POSIX Conformance (see XBD Conformance), c99 is required only with the C-Language Development option; XSI-conformant systems always provide c99." Therefore, a system that conforms to the Open Group Base Specification, but is not XSI-conformant, or which conforms to POSIX without the C-Language Developement option, need NOT provide C99. And the Open Group Base Specification doesn't even mention C++, so any C++ standard libraries that you happen to find on a unix system are not POSIX API libraries > complex than malloc or new, regular expressions, signals pipes, timing blah > blah blah. > But I'm sure it was a fantastic Hello World program that you ended up with. "They", not "it" - I'm not describing a single program, but many different programs. I'm not sure "fantastic" would apply, but they do a lot more than "Hello World". They run 24/7 on thousands of different systems located in the Goddard Space Flight Center, processing data transmitted to the ground that was collected by the MODIS instruments on the Terra and Aqua satellites, and by the VIIRS instruments on the Suomi NPP and NOAA-20 satellites. They read input files, reformat the data and perform calculations based upon the data, writing the reformatted and newly calculated data to output files. Portability of the files is handled mainly by a third-party library that I'm required to use, which is built on top of XDR. The directories are created and destroyed by the production system. There's no GUI code, or indeed any kind of user interface - the operators use a GUI to control the production system, but my programs interact only with the production systems, through their command lines, file I/O, and return status. There's no networking code, no multi-processing or multi-threaded code. Text processing is completely negligible and has no need of internationalization. It's just pure data processing, for which I have no need (and no permission!) to go outside the range of facilities provided by pure C or C++ and POSIX. I'm explicitly prohibited from using large parts of the POSIX API, so as to prevent my programs from interfering with use of those same facilities by the production system. But it's an awful lot of data processing. I'm well aware of the existence of many other kinds of programming very different from what I'm doing - but programming like what I'm doing is still very much alive. My programs constitute only a small fraction of all the programs that run under the production systems I described; there's hundreds of other programs built to operate under the same restrictions, written by thousands of other programmers, and there's many other production systems all over the world that are similarly designed. Were you aware of that fact? |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 14 08:53AM -0400 >> What about every C and C++ compiler that is /not/ for a unix system? >> There are a great many compilers targeting other systems than *nix - > There are certain libraries that are standard on certain systems is my point. Then why did you respond to David Brown's statement of fact that "Neither Win32 nor POSIX are language standard libraries." by saying "Define standard. win32 is the standard windows C API and posix the standard unix C API."? The fact that those are APIs defined by OS standards in no way contradicts the fact that they are NOT libraries defined by language standards. As I said before, the definition of "standard" has nothing to do with why those APIs fail to qualify as language standard libraries. |
| boltar@cylonHQ.com: May 14 01:28PM On Mon, 14 May 2018 14:28:31 +0300 >towards >> java, python or javascript in the end anyway. >I gather this means you have never heard about boost::asio either. No, and I couldn't care less about it either. I avoid boost like a would a fly covered turd on a path. |
| boltar@cylonHQ.com: May 14 01:34PM On Mon, 14 May 2018 13:50:55 +0200 >Yes, that much is true. It wasn't what you said, however. And it does >not mean that you /have/ to use these libraries for programming on those >systems - you certainly don't need to do so directly. No, but if you want efficient code it usually helps. I'm not a fan of the turtles all the way down style of programming. One reason I steer clear of java if I can help it. >And I suppose you think /real/ men use raw X api calls? Well if the shoe fits... ;) Actually I did write some games back in the day and if you want good performance then its either Xlib or openGL. >Some people don't like to reinvent wheels if they can avoid it. You don't need to reinvent the wheel, its a case of a wheel usually sufficing and being a better choice than a jet engine. |
| boltar@cylonHQ.com: May 14 01:44PM On Mon, 14 May 2018 08:46:58 -0400 >between operating system standard libraries and language standard >libraries that you have refused to acknowledge. The meaning of >"standard" has nothing to do with what's wrong with your statements. Thats all well and good, except with C++ now providing a threading model its stepped over the line from pure language to OS implementation. So IMO there's nothing wrong with going the other way and saying that the Posix API is a C and C++ standard library. >Base Specification doesn't even mention C++, so any C++ standard >libraries that you happen to find on a unix system are not POSIX API >libraries Well we'll have to agree to disagree on that. I fail to see any point in arguing further. >POSIX API, so as to prevent my programs from interfering with use of >those same facilities by the production system. But it's an awful lot of >data processing. Why use a systems programming language for pure data processing? You'd be better off with R, matlab or even fortran. >designed. Were you aware of that fact? Yes, and they don't tend to use C or C++. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 14 10:01AM -0400 > stepped over the line from pure language to OS implementation. So IMO there's > nothing wrong with going the other way and saying that the Posix API is a C and > C++ standard library. Other than the fact that neither the C standard nor the C++ standard has anything to say about the POSIX API. I suppose you consider that a minor detail, but it's completely inconsistent with what I mean when I call something a "C standard library". >> libraries that you happen to find on a unix system are not POSIX API >> libraries > Well we'll have to agree to disagree on that. No we don't - all you have to do to identify a C++ library as being part of the POSIX API is to identify the part of the POSIX standard that provides specifications for that library. If there's no such part, we're not merely in disagreement, you're simply wrong. >> data processing. > Why use a systems programming language for pure data processing? You'd be > better off with R, matlab or even fortran. I didn't make the decision, I was just hired by people who decided to use C - but many of them were very familiar with Fortran (you could tell by the way they wrote their C), and they still chose C over Fortran - knowing both languages, I think it was a good decision. Our contract with our client doesn't permit the other two languages you mention. |
| David Brown <david.brown@hesbynett.no>: May 14 04:06PM +0200 > No, but if you want efficient code it usually helps. I'm not a fan of the > turtles all the way down style of programming. One reason I steer clear of java > if I can help it. There is a happy medium to be found. Sometimes the balance is towards maximum run-time efficiency (and therefore low-level calls, and low-level languages), and sometimes towards maximum developer efficiency (and therefore high-level calls and languages). My small-system embedded usually minimise libraries or abstraction layers - my PC programming is usually in Python using libraries like wxpython. >> Some people don't like to reinvent wheels if they can avoid it. > You don't need to reinvent the wheel, its a case of a wheel usually sufficing > and being a better choice than a jet engine. There is nothing wrong with using Posix calls when you know they are available and do the job. The point is that there is /also/ nothing wrong with using libraries built at a higher level, if that is what is best for the job. |
| boltar@cylonHQ.com: May 14 02:16PM On Mon, 14 May 2018 10:01:04 -0400 >anything to say about the POSIX API. I suppose you consider that a minor >detail, but it's completely inconsistent with what I mean when I call >something a "C standard library". There are official standards and then there are de-facto standards on certain OS's. The latter as you well know is what I'm referring to. C or C++ on their own with no library support other than the official language standards are pretty useless unless you happen to know assembler. >of the POSIX API is to identify the part of the POSIX standard that >provides specifications for that library. If there's no such part, we're >not merely in disagreement, you're simply wrong. I'm not talking about any official C++ library being part of the posix standard, I'm talking about the posix libraries being standard C++ libraries since C++ is a good enough superset of C to be able to use them without any issues. The same would apply to win32 being a standard C/C++ library on windows. |
| scott@slp53.sl.home (Scott Lurndal): May 14 03:30PM >anything to say about the POSIX API. I suppose you consider that a minor >detail, but it's completely inconsistent with what I mean when I call >something a "C standard library". While understanding your point about "standard libraries", I'd point out that the POSIX API, while not explicitly calling out C++ specific bindings, understands that C++ is backwards compatible with C with respect to the existing C bindings. |
| Vir Campestris <vir.campestris@invalid.invalid>: May 14 09:09PM +0100 > The posix API libraries come with every C/C++ compiler installed on every > unix system since god knows when. IMO that makes them standard. I haven't seen a Unix system since %deity% knows when. And not all Linux systems have the libraries - some are stripped down embedded systems. For that matter I worked on Windows for many years - and Posix was never more than vaguely interesting. The only real cross-platform stuff I met was Java. Andy |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 14 04:59PM -0400 >> something a "C standard library". > There are official standards and then there are de-facto standards on certain > OS's. The latter as you well know is what I'm referring to. No, I didn't know that's what you were referring to. When referring to a defacto standard, you should say "de-facto standard library", not "language standard library" or "C standard library" or "C++ standard library" if you don't wish to be misunderstood. Until you clarified that fact in this very message, I assumed that you were in fact under the mis-apprehension that the C and C++ standards did have something to say about the POSIX API. Given your posting history, that assumption didn't strike me as particularly implausible. Incidentally, the POSIX API is NOT a defacto standard, it's a de-jure standard. It's just not a language standard, which was the original point. > ... C or C++ on their > own with no library support other than the official language standards are > pretty useless unless you happen to know assembler. I've made a career of using them (almost) precisely that way without the use of assembler. The "almost" refers to the fact that most of the input and output files from my programs are required to be in HDF4 or HDF5 format, and I'm required to use the C or C++ versions of the HDF libraries <https://www.hdfgroup.org/> to read them. HDF shelters me from needing to worry a lot about the difficulties of porting data from one platform to another - but I doubt that dealing with such difficulties was the main point of your comment. > I'm not talking about any official C++ library being part of the posix standard, > I'm talking about the posix libraries being standard C++ libraries since C++ > is a good enough superset of C to be able to use them without any issues. Perhaps - but "standard" isn't even remotely the right term to use to express that concept. "C++ compatible libraries" would cover the concept quite nicely. |
| legalize+jeeves@mail.xmission.com (Richard): May 14 10:33PM [Please do not mail me a copy of your followup] boltar@cylonHQ.com spake the secret code >The posix API libraries come with every C/C++ compiler installed on every >unix system since god knows when. IMO that makes them standard. Spoken like a true unix bigot. -- "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> |
| Nikki Locke <nikki@trumphurst.com>: May 14 10:23PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| David Brown <david.brown@hesbynett.no>: May 14 09:08AM +0200 > removing a class member? I'd like to know about it so I > can either remove the member myself or disable the > optimization. That is up to the compiler. For gcc, I don't know of any method. Note that the compiler can only remove a struct member if it does not affect the working of the code - so why should it have a way to tell you "by the way, compiler optimisations made code faster" ? Usually you will only see field removal for local data within a function - if the struct can "escape" in some way, it will be hard for the compiler to track all uses and be sure a field can safely be omitted. Within a function, the compiler will to some extent treat a local struct as a collection of individual variables, each subject to optimisations like dead store elimination, hoisting, caching loads, de-duplication, strength reductions, constant propagation, etc. This is integral to compiler optimisation, and unlikely to be controllable by a single flag. |
| Juha Nieminen <nospam@thanks.invalid>: May 14 09:06AM > Anyway, what is difference between std::any and std::variant? One major difference is that std::variant is a template class, while std::any isn't. Something that takes an object of type std::variant needs to hard-code its types (and their declaration order), unless you make that something templated. Something that takes an object of type std::any doesn't need to know what exact types it may contain, and doesn't need to be templated. One side effect of this is that sizeof(std::any) is always the same (within the same compiler), while sizeof(std::variant) depends on what types are being used. And, of course, std::any can literally contain any type. Code taking such an object as parameter cannot force it to contain only certain types. (This may be a positive or a negative, depending on the situation.) |
| woodbrian77@gmail.com: May 14 09:03AM -0700 On Monday, May 14, 2018 at 4:06:29 AM UTC-5, Juha Nieminen wrote: > And, of course, std::any can literally contain any type. Code taking > such an object as parameter cannot force it to contain only certain > types. (This may be a positive or a negative, depending on the situation.) Having read some about this proposal https://www.reddit.com/r/cpp/comments/8iw72i/p0709_r0_zerooverhead_deterministic_exceptions/ to make C++ exceptions static as opposed to dynamic, I think std::any fit slightly better in the (now) old version of C++ that had dynamic exceptions, but std::any always was "a bridge too far" imo. Brian Ebenzer Enterprises - "Whoever refreshes others will himself be refreshed." Proverbs 11:25 http://webEbenezer.net |
| 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