| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Nov 08 02:44AM -0800 On Thursday, 3 November 2022 at 19:31:10 UTC, Lynn McGuire wrote: > jobs even at my age of 62. > Hat tip to: > https://www.codeproject.com/script/Mailouts/View.aspx?mlid=16845 You keep on adding features to the language which have unintuitive syntax and odd rules, and don't do much to increase the number of programs you can write quickly. So what happens? Theres not much motivation to learn these features until forced to do so. So codebases tend to be mainly legacy, and C++ programmers' skills fall behind. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 08 11:29AM > don't do much to increase the number of programs you can write quickly. So what happens? > Theres not much motivation to learn these features until forced to do so. So codebases tend > to be mainly legacy, and C++ programmers' skills fall behind. For the longest time I quite strongly disagreed with the claim that C++ is becoming too big and too complicated. However, C++20 has eroded this conviction of mine somewhat. C++23 is eroding it even more. C++11 felt like a big bunch of features that the language was in dire need of, and genuinely made programming easier. C++14 and C++17 fixed and patched many of the minor problems and defects that turned out to exist in C++11, so C++17 felt like "what C++11 should have been in the first place". C++20, however, doesn't feel like this anymore. It has a few new features that genuinely help in programming, but most of it feels like just adding features for the sake of adding them. C++23 even moreso. With both there are tons of features for which I genuinely think "who exactly asked for this? Who actually needs this? Does the language truly need and benefit from this?" When you read the feature proposal papers, they feel a lot like it's just someone proposing a feature for the sake of proposing it, rather than it filling an *actual* useful need that the language is in dire need of. In many cases I don't even understand why they have been accepted. And even so, even when some feature *is* somewhat widely requested, they should still weigh in how much it *actually* contributes to the usability of the language, and how much it adds to its complexity (which is already quite high). The standardization committee seems to have a problem with saying "no" even to some sounds-like-it-could-be-useful feature proposals (not to talk about some that aren't all that useful). This feeling of adding-features-just-for-the-sake-of-adding-them is something that has really started to give me a distaste for the newer versions of the standard. Both C++20 and C++23 have actual useful features that I'm looking forward to, but they seem to be a very small minority of all features. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 08 03:54AM -0800 On Tuesday, 8 November 2022 at 13:29:19 UTC+2, Juha Nieminen wrote: > versions of the standard. Both C++20 and C++23 have actual useful > features that I'm looking forward to, but they seem to be a very small > minority of all features. I disagree on C++17. What the core language of C++14 guaranteed was quite trashed by C++17. It is impossible to write vector in it; the std::vector is magical class now. Things that were added felt like sabotage not needed features. C++17 added few library features that are sorely needed as those are all magical too and also those were added noticeably poorly on closer examination. Compilers of course compile most UBs that we have in our code-bases (as the codebases of compiler suppliers are full of same UBs) until the suppliers decide otherwise. Same trend continues in C++20 and C++23. C++ should either roll most of that broken beyond fixing garbage back ... or it makes sense to migrate to Rust, Swift, D or C in what it is possible to write software without using magical classes of standard library only. |
| Stuart Redmann <DerTopper@web.de>: Nov 08 02:26PM +0100 > I disagree on C++17. What the core language of C++14 guaranteed was > quite trashed by C++17. It is impossible to write vector in it; the > std::vector is magical class now. Could you elaborate this? Or maybe post a link? A quick web search yields nothing usable :-/ TIA, Stuart |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 08 02:52PM +0100 Am 08.11.2022 um 12:29 schrieb Juha Nieminen: > C++20, however, doesn't feel like this anymore. It has a few new features > that genuinely help in programming, but most of it feels like just adding > features for the sake of adding them. C++23 even moreso. I don't think ranges are really necessary, but they're of course techni- cally very elegant. But concepts and cororoutines really rock. Don't use them if you're overburdened with them. |
| Juha Nieminen <nospam@thanks.invalid>: Nov 08 03:16PM > I disagree on C++17. What the core language of C++14 guaranteed was > quite trashed by C++17. If you read the list of added features in C++17 (from eg. the Wikipedia article), most of them sound quite useful and practical, many making things simpler. There are a few features that could have probably been left out without anybody really missing them, but most of them seem very practical. The text message for static_assert becoming optional is handy and nice. The "namespace x::y::z" syntax for nested namespaces is really convenient. The new attributes are useful (especially [[maybe_unused]]). Initializers in 'if' and 'switch' statements may not be crucial, but sometimes they become handy. The same can be said of structured bindings and class template argument deduction. Mandatory copy elision adds an efficiency guarantee (and doesn't change the language syntax itself), so that's nice. Inline variables are actually useful, especially for header-only libraries. __has_include is a nice-to-have feature. constexpr functions are quite a swamp that should have been thought better in C++11, but given that they exist in their current form and we are stuck with them, 'if constexpr' can be a useful addition. (The same could be said of variadic templates and the new fold expressions in C++17.) (Not going to comment about the additions to the standard library because the library is not part of the core language syntax and semantics, and thus not really what I'm talking about here.) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 08 10:48PM On Tue, 2022-11-08, Juha Nieminen wrote: > of, and genuinely made programming easier. C++14 and C++17 fixed and patched > many of the minor problems and defects that turned out to exist in C++11, > so C++17 felt like "what C++11 should have been in the first place". Same here (although I haven't bought C++17 yet; I'm still at C++14). I think we can conclude it's not just me and you growing old and conservative: there /has/ been a shift in how C++ evolves, and such a shift will have drawbacks. Going back to the "pool of talented C++ developers" angle, I have sometimes wondered if this evolution has been necessary to attract developers. Maybe the youngsters are used to the constantly changing web environments, and won't touch something which hasn't changed in a decade? But I don't believe that. I believe we need a subset of programmers to deal with big programs with a long lifetime which go through lots of small, incremental changes. C++ is a good fit for that, but quick changes to the C++ language are not. One thing I've learned in recent years at work is that you don't need everyone to start out as a C++ expert. We've had to hire several newbies who didn't know C++ or had spent a few weeks with it at university. Those with talent for that kind of development learn surprisingly quickly from the existing code base, and from reviews. Even those who I assumed were damaged by too much Python. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Lynn McGuire <lynnmcguire5@gmail.com>: Nov 07 11:26PM -0600 On 11/6/2022 4:41 PM, Michael S wrote: > * - IMHO, you should not. Posters here suggested at least two better solutions > and can suggest more. BTW, are you sure that with modern memory > capacity you still need temporary files at all? Port to C++ first then improve. Improving inside the porting loop can bring in all kinds of bugs. A couple of the temporary files are related to our inline Fortran interpreter that the users use to add in their own custom calculations. There is some serious juju going on there. Thanks, Lynn |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 08 06:30PM +0100 On 7 Nov 2022 13:11, Michael S wrote: >> dynamically varying resolution down to 1/30 second, extremely unusable. > MinGW is obsolete since long ago, close to 10 years. > It is replaced by MSYS2/Mingw64. Oh my. I just don't care to write MinGW64, it's a bit of a mouthful and in general very unnecessary. Most people understand. But to be precise you're comparing the compiler/tool project MinGW with the compiler distribution and Unix-like eco-system MSYS2. MSYS2 provides one distro of MinGW64. Nuwen (that's STL at Microsoft, or if you like, prince Nuwen from the Vernor Vinge novels) another. There are others. The project that provides the basic sources that they all use is the MingW64 project, <url: https://www.mingw-w64.org/>. > of std::chrono::system_clock. But I don't suggest any of those. > I suggest std::chrono::steady_clock. It has reasonable > implementations on all x86-64 systems that I ever tested. The MinGW (that is, MinGW64) g++ implementation was not reasonable, and probably isn't today either. > the most popular C++ tools on any given platform, i.e. MSVC on > Windows, LLVM/clang (via Xcode) on Mac and gcc on Linux. > Portability to more exotic tools+OS combinations is not required. Portable code is often, and in this case would be, /less/ code. As such it is more likely correct code. The problem is when a C++ implementation doesn't manage to provide the implied usability guarantee. It's sort of like a C++ implementation with a 1 MB `bool`, so that you can't have two of them on a default machine stack. That's formally OK; it just fails to provide a /usable/ `bool`. - Alf PS: I'm sorry that I by mistake sent essentially this reply via mail, presumably to an unused spam-dump e-mail address, but. Not sure how Thunderbird managed to trick me into doing that. |
| Paavo Helde <eesnimi@osa.pri.ee>: Nov 08 01:35PM +0200 I have got a problem with a third-party library, which I am trying to compile and use as a bunch of static Linux .a libraries. Suspecting the problem would go away if I switched over to dynamic libraries instead, but I want to understand the issue. Basically there is a header which declares a static constexpr member of a struct (simplified here for brevity): // a.h #pragma once #include <array> namespace Foo { struct Bar { static constexpr std::array<int, 3> blob = {1, 2, 3}; }; } This header is included by multiple libraries. One of the libraries also contains the definition: // a.cpp #include <a.h> namespace Foo { constexpr std::array<int, 3> Bar::blob; } The nm tool reports it is defined only in a single .a file and used by 3 others. Altogether there are 18 .a files. When I now try to link my own .so, by linking it with all those static libraries, I get a multiple definition linker error about Bar::blob. As it seems these libraries contain cyclic interdependencies and rely on a specific order of static initialization, some of those libraries are listed multiple times in the linker command, but the one containing the definition is mentioned once only. Needless to say, I have not been able to reproduce the problem with simplified files, it only appears with those 18 .a files with cyclic interdependencies. Any ideas are welcome! BTW, I'm using g++ 8.3.0 |
| "Öö Tiib" <ootiib@hot.ee>: Nov 08 04:08AM -0800 On Tuesday, 8 November 2022 at 13:35:32 UTC+2, Paavo Helde wrote: > simplified files, it only appears with those 18 .a files with cyclic > interdependencies. Any ideas are welcome! > BTW, I'm using g++ 8.3.0 That g++ is claimed to have complete C++17 support. If you compile all as C++17 then it must work without definition as static data member that is declared constexpr is implicitly inline in C++17. Inline does not need to be redeclared at namespace scope. So I would erase a.cpp from project and try again or make explicit static inline constexpr, erase a.cpp and try again. |
| Paavo Helde <eesnimi@osa.pri.ee>: Nov 08 02:40PM +0200 08.11.2022 14:08 Öö Tiib kirjutas: > Inline does not need to be redeclared at namespace scope. So I > would erase a.cpp from project and try again or make explicit > static inline constexpr, erase a.cpp and try again. Thanks a lot! It looks like passing -DCPP_STANDARD=17 to the third-party library build got rid of the issue! The nm tool now lists the symbol as 'u' (unique global symbol) in all affected .a files instead of former 'U' (undefined) or R (read-only data). |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 08 04:31AM +0100 template<bool Zero = false, bool Throw = true, std::random_access_iterator Iterator, typename Consumer> requires std::convertible_to<std::iter_value_t<Iterator>, char8_t> && requires( Consumer consumer ) { { consumer( (char32_t)-1 ) }; } utf8_exception::err_t parseUtf8( Iterator begin, Iterator end, Consumer consumer ) { using namespace std; using err_t = utf8_exception::err_t; Iterator it = begin; auto further = [&]<typename ... Chars>( Chars &... chars ) -> err_t { if constexpr( !Zero ) { if( end - it < sizeof ...(Chars) ) [[unlikely]] return err_t::LENGTH_ERROR; if( ((((chars = *it++) & 0xC0) == 0x80) & ...) ) [[likely]] return err_t::NO_ERROR; else return err_t::ENCODING_ERROR; } else { if( ((((chars = *it++) & 0xC0) == 0x80) && ...) ) [[likely]] return err_t::NO_ERROR; else { err_t err; ((bool)(err = !chars ? err_t::LENGTH_ERROR : (chars & 0xC0) != 0x80 ? err_t::ENCODING_ERROR : err_t::NO_ERROR) || ...); return err; } } }; auto juice = []( char8_t c, unsigned bits ) -> char32_t { return c & 0xFF >> 8 - bits; }; auto ret = []( err_t err ) -> err_t { if constexpr( !Throw ) return err; else throw utf8_exception( err ); }; char8_t c0, c1, c2, c3; utf8_exception::err_t err; constexpr char32_t UNICODE_MAX = 0x10FFFF; for( char32_t c32; !Zero && begin != end || Zero; consumer( c32 ) ) if( (signed char)(c0 = *it++) >= 0 ) [[likely]] if constexpr( !Zero ) c32 = c0; else if( c0 ) [[likely]] c32 = c0; else break; else if( (c0 & 0xE0) == 0xC0 ) [[likely]] { if( (bool)(err = further( c1 )) ) [[unlikely]] return ret( err ); c32 = juice( c0, 5 ) << 6 | juice( c1, 6 ); if( c32 > UNICODE_MAX) [[unlikely]] return ret( err_t::ENCODING_ERROR ); } else if( (c0 & 0xF0) == 0xE0 ) [[likely]] { if( (bool)(err = further( c1, c2 )) ) [[unlikely]] return ret( err ); c32 = juice( c0, 4 ) << 12 | juice( c1, 6 ) << 6 | juice( c2, 6 ); if( c32 > UNICODE_MAX ) [[unlikely]] return ret( err_t::ENCODING_ERROR ); } else { if( (c0 & 0xF8) != 0xF0 ) [[unlikely]] return ret( err_t::ENCODING_ERROR ); if( (bool)(err = further( c1, c2, c3 )) ) [[unlikely]] return ret( err ); c32 = juice( c0, 3 ) << 18 | juice( c1, 6 ) << 12 | juice( c2, 6 ) << 6 | juice( c3, 6 ); if( c32 > UNICODE_MAX ) [[unlikely]] return ret( err_t::ENCODING_ERROR ); } return utf8_exception::err_t::NO_ERROR; } |
| 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