Elektrine
Log in Register

#cplusplus

10 posts · Last used 3d

Back to Timeline
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk I'm not sure that this is the best fix. Since C++2011, there's been a template for std::log in that takes an integral type argument and so is the best match without ambiguity. https://cplusplus.com/reference/cmath/log/ vide libstdc++ https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_global/cmath;hb=HEAD#l322 and libc++ https://github.com/llvm/llvm-project/blob/main/libcxx/include/__math/logarithms.h#L35 Illumos's C++ support in isn't up to date with respect to C++ 2011 (unsurprisingly) and a fix that would actually improve and modernize the C++ support seems to be to add these templates for log and whatnot, in some fashion, with appropriate C++ version and type guards, to head/iso/math_iso.h where all of the other C++1998 overloads already are. That would remove ambiguity for both log(1) and std::log(1). #CPlusPlus #Illumos #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk If I had an #Illumos system to do such work on, I probably could. Your patch is breaking the uniform way that the library is designed, over a whole load of headers. In this design, all of the overloads are declared inside namespace std in some iso/*_iso.h header, which headers like and and so forth then pull into the global namespace with using declarations. Ironically, it's a far more full-on C++ way of doing things because it's even declaring the C library functions in namespace std, but with "C" linkage. namespace std gets 1 "C" linkage overload and 2 "C++" linkage overloads for the various functions. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk Retaining that uniform, clean, system involves adding the stuff that's needed for more modern C++ anyway into the right iso/math_iso.h header. If I were doing that, head/iso/math_iso.h would gain something like template inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast(__v)); } inside namespace std, and #include at the top. There'd be an head/iso/type_traits.h with the well-known implementation of enable_if<> as __illumos::__enable_if<> and a suitable implementation of __illumos::__is_integral<> instantiated as appropriate. #CPlusPlus #gcc #clang #Illumos
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk All that said, the big question to answer is whether there is still in use an #Illumos C++ compiler that does not use either GNU libstdc++ or LLVM libc++. (Likely yes if a compiler bootstrap uses C++ before it has its own library built.) Because the inlined "C++" linkage stuff declared by the Illumos library has a fallback to other inline functions if using libstdc++ or libc++, the very easiest patch of all would seem to be just conditionally compile out (only) the extern "C++" {} block of head/iso/math_iso.h when either _LIBCPP_VERSION or __GLIBCXX__ is defined. That way, anything building with libstdc++ or libc++ doesn't get the Illumos "C++" linkage overloads as overloads in the global namespace, and only gets the 1 "C" linkage overload. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk You've missed two important bits. Your initial approach didn't test for _LIBCPP_VERSION or __GLIBCXX__. Your initial approach rather compiled all of this out except for one specific compiler. What I just described, in contrast, compiles everything in for all compilers except when libstdc++ or libc++ are used. It's library-sensitive, not compiler-sensitive. Because there's a stage at least in the GCC bootstrap where it is building itself with the pre-supplied compiler and library. In this mode, one does *not* want the #Illumos headers to have their C++ parts conditionally compiled out. One rather wants them to be fully natively functional the same as they are now. I also said *only* the extern "C++" {} block. Your initial approach went far beyond that and compiled out the declarations of a whole bunch of "C" linkage stuff. #CPlusPlus #gcc #clang
0
0
0
@cpponsea@vmst.io · Mar 07, 2026
Can’t wait until ACCU on Sea? 🌊 Join the C++ community online next week at C++Online 2026! 🎤 3 keynotes 🧠 35+ sessions 🤝 Real networking in a virtual venue 📺 Live + on-demand Same community spirit — fully online. 🎟 From £50 🔗https://cpponline.uk/registration/ #cpp #cplusplus #code
0
0
0
@jobsfordevelopers@mastodon.world · Feb 23, 2026
Sysdig is hiring Senior Staff Software Engineer 🔧 #cplusplus #aws #cicd #docker #awsec2 #kubernetes #awss3 #seniorengineer 🌎 Flexible; Italy ⏰ Full-time 🏢 Sysdig Job details https://jobsfordevelopers.com/jobs/senior-staff-software-engineer-at-sysdig-com-nov-28-2023-c0effd?utm_source=mastodon.world&utm_medium=social&utm_campaign=posting #jobalert #jobsearch #hiring
0
0
2
@jobsfordevelopers@mastodon.world · Feb 02, 2026
Shield AI is hiring Staff Engineer, C++ Systems Integration (R4018) 🔧 #cplusplus #python #api #grpc #rest #cicd #docker 🌎 Washington, DC ⏰ Full-time 🏢 Shield AI Job details https://jobsfordevelopers.com/jobs/staff-engineer-c-systems-integration-r-4018-at-shield-ai-nov-18-2025-038f54?utm_source=mastodon.world&utm_medium=social&utm_campaign=posting #jobalert #jobsearch #hiring
0
0
1
Boosted by Greg Bell @ferrix@mastodon.online
@meetingcpp@mastodon.online · Jan 26, 2026
Book of the Day: Data Structures and Algorithms with the C++ STL: A guide for modern C++ practitioners by John Farrier https://meetingcpp.com/mcpp/books/book.php?hash=6fbd81674112043be13241deeb9f4af9a78ba232 #cplusplus #cpp
0
0
2
Boosted by Greg Bell @ferrix@mastodon.online
@meetingcpp@mastodon.online · Dec 24, 2025
All the other cool languages have try…finally. C++ says “We have try…finally at home.” https://devblogs.microsoft.com/oldnewthing/20251222-00/?p=111890 #cpp #cplusplus
3
1
2

You've seen all posts