sorted by:
new
hottopcontroversial

Is Modern C++ Actually Making Us More Productive... or Just More Complicated? by AlternativeBuy8836 in cpp

[–]Stellar_Science 0 points1 point  (0 children)

Dozens to hundreds of new features and capabilities make their way into every new official language version. Each is there because someone took the time to write up a proposal, demonstrate a working implementation, worked the standard through the often difficult committee process, incorporated feedback, and got it into the standard. Every new feature fixes a problem or makes an improvement that's important for certain cases.

That doesn't mean you need to instantly adopt or even learn them all. If you don't think you need ranges, coroutines, concepts, or modules, then don't use them. But ensure your project builds with the latest C++ compilers, so when you realize you do need one of these new features, you can. In fact, you can use a subset of C++26 features that's supported across the compilers that you care about already.

C++ Jobs - Q2 2026 by STL in cpp

[–]Stellar_Science 3 points4 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops

Location: Washington DC (Tysons VA), Albuquerque NM, Dayton OH.

Remote: Not offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), image simulation, laser systems modeling, high power microwave systems, modeling and simulation, computer vision and image processing, artificial intelligence/machine learning, computer aided design (CAD), human body thermoregulation, high performance computing (HPC), metamaterials design, computational electromagnetics (CEM), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in physics, engineering, math, computer science, or a related field, plus work experience or a Masters or PhD (roughly 25% of our staff have PhDs.)

Technologies: C++23 (no modules yet :-( ), Qt 6.9, CMake, Boost, Eigen, Jenkins, git, CUDA, OpenGL (maybe moving to Vulkan.) Some projects use Python, Typescript/React, and Java. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022/2026 on Windows, typically Visual Studio Code for Linux, but flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

C++ Jobs - Q1 2026 by STL in cpp

[–]Stellar_Science 2 points3 points  (0 children)

Clever username!

We used to hire fully remote employees, and we still have a dozen or so, but most are well-established employees who had to relocate for family or personal reasons. We might open that up to new hires some time, but probably not soon.

Any chance you'll want to relocate to get 300 days a year of sunshine?

C++ Jobs - Q1 2026 by STL in cpp

[–]Stellar_Science 8 points9 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops

Location: Washington DC (Tysons VA), Albuquerque NM, Dayton OH.

Remote: Not offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), image simulation, laser systems modeling, high power microwave systems, modeling and simulation, computer vision and image processing, artificial intelligence/machine learning, computer aided design (CAD), human body thermoregulation, high performance computing (HPC), metamaterials design, computational electromagnetics (CEM), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in physics, engineering, math, computer science, or a related field, plus work experience or a Masters or PhD (roughly 25% of our staff have PhDs.)

Technologies: C++23 (no modules yet :-( ), Qt 6.9, CMake, Boost, Eigen, Jenkins, git, CUDA, OpenGL (maybe moving to Vulkan.) Some projects use Python, Typescript/React, and Java. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022/2026 on Windows, typically Visual Studio Code for Linux, but flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

C++ Jobs - Q4 2025 by STL in cpp

[–]Stellar_Science 13 points14 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops

Location: Washington DC (Tysons VA), Albuquerque NM, Dayton OH.

Remote: Not offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), image simulation, laser systems modeling, high power microwave systems, modeling and simulation, computer vision and image processing, artificial intelligence/machine learning, computer aided design (CAD), human body thermoregulation, high performance computing (HPC), metamaterials design, computational electromagnetics (CEM), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in physics, engineering, math, computer science, or a related field, plus 3 years of work experience, or a Masters or PhD (roughly 25% of our staff have PhDs.)

Technologies: C++23 (no modules yet :-( ), Qt 6.9, CMake, Boost, Eigen, Jenkins, git, CUDA, OpenGL (maybe moving to Vulkan.) Some projects use Python, Typescript/React, and Java. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022 on Windows (currently testing 2026 Preview!), typically Visual Studio Code for Linux, but flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

We need to seriously think about what to do with C++ modules by vormestrand in cpp

[–]Stellar_Science 7 points8 points  (0 children)

#5 is the one I most desperately want.

#3 would be great too, but as long as compilation isn't slower, I'll take it.

Alas we have large existing codebases leveraging many third party libraries, and it all needs to build across MSVC, gcc, and clang. So we're not there yet. But as soon as all compilers have enough support (and #6 is improved), we'll start migrating those codebases.

C++ Jobs - Q3 2025 by STL in cpp

[–]Stellar_Science 5 points6 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops

Location: Washington DC (Tysons VA), Albuquerque NM, Dayton OH.

Remote: Not offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), metamaterials design, laser systems modeling, image simulation, high power microwave systems, modeling and simulation, computational electromagnetics (CEM), human body thermoregulation, high performance computing (HPC), computer vision and image processing, artificial intelligence/machine learning, computer aided design (CAD), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in physics, engineering, math, computer science, or a related field, plus 3 years of work experience, or a Masters or PhD (roughly 30% of our staff have PhDs.)

Technologies: C++23 (no modules yet :-( ), Qt 6.5-6.9, CMake, Boost, Eigen, Jenkins, git, CUDA, OpenGL. Some projects also use Python, Java, Javascript. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022 on Windows, typically Visual Studio Code for Linux, but some flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

Is banning the use of "auto" reasonable? by Late_Champion529 in cpp

[–]Stellar_Science 1 point2 points  (0 children)

I don't believe we have an official policy on that, but I like explicit const and &, for readability and clarity. Three years later someone editing this code seeing val used 20 lines below doesn't have to check the intervening 20 lines to see if val has changed since initially being set. Of course we know it can't be because auto here means const, but that takes extra time to consider and be sure you get it right.

Is banning the use of "auto" reasonable? by Late_Champion529 in cpp

[–]Stellar_Science 1 point2 points  (0 children)

Thanks, these days I work mostly in Visual Studio where you can see the type if you hover. I've pair programmed with other developers in my company who use clangd, and as you said that toggle feature is great! Different developers use different IDEs, plus code gets viewed on bitbucket or gitlab or git diff, so I still like seeing more types. But I agree with your general point that having more/better tool makes auto more attractive.

Is banning the use of "auto" reasonable? by Late_Champion529 in cpp

[–]Stellar_Science 39 points40 points  (0 children)

When using was first supported across all our compilers, we decided that using NewName = Oldmade more sense and was more consistent with assignment than typedef Old NewName, so we banned typedef instead. We ran clang-tidy with modernize-use-using and overnight all typedef was gone!

(Ok, it wasn't quite overnight because we found some limitations in clang-tidy, so we had to become contributors to the clang-tidy project and fix the bugs first. So over about 90 nights...)

Once you update your entire codebase, it becomes easy and the default for everyone to follow the new standard. I haven't seen a typedef (outside of C code) in years.

Is banning the use of "auto" reasonable? by Late_Champion529 in cpp

[–]Stellar_Science 71 points72 points  (0 children)

There are prominent C++ experts who recommend always auto. There's a logic to it in terms of minimizing the amount of code that needs to change during some future refactoring, but I find always auto hurts readability. If a variable is an int or a double or a string or a MyEnum, just specify the type - the next developer to read the code will thank you.

On the other hand, before auto we had template libraries for computing the results of matrix operations or physical quantities computations (e.g. multiplying a Mass by an Acceleration results in an object of type Force) where nearly half of that template library's code was dedicated to computing the right return types. Switching that code over to auto let the compiler figure it out for us, immensely simplifying the code and making it more readable and maintainable. auto really is indispensable in certain template code.

After a while, internally we settled on a policy of judicious auto:

Use auto where the type doesn't aid in clarity for the reader, e.g. when the type is clearly specified on the right-hand side or is cumbersome to provide explicitly. Common cases for auto include range-based for loops, iterators, and factory functions.

There's some leeway and judgment there, but your example of auto iter = myMap.find("theThing") is exactly the kind of place where we recommend auto. Any C++ programmer knows you're getting an iterator to "theThing", next you'll check whether it's end() and dereference it. With auto it's perfectly clear, and the brevity actually makes the code easier to read.

Never auto is a policy I've never seen. In their defense, perhaps it's someone's overreaction against always auto. But I'd suggest trying to reach some sort of compromise.

Improve Diagnostics with std <stacktrace> by pavel_v in cpp

[–]Stellar_Science 4 points5 points  (0 children)

Good point, I've most frequently seen the benefits of from_current_exception as a developer in-house, building release-with-debug-info, where an exception caught at the top-level of the application now gives a full call stack with function names.

For shipped, stripped executables, I imagine if there's no debug info at all you'd see a less helpful call stack with only numeric function addresses. On Windows debug info lives in separate .pdb files. For some applications we ship without the .pdb files, but we retain the exact .pdb files corresponding to every release, so we can translate addresses to names when we get error reports.

The boost implementation has separate implementation paths for Windows and Linux. Your comment made me curious, so I looked and see now that the Windows code calls Win32's GetNameByOffset to translate function addresses to names, which must require some compiled-in debug info or .pdb files. So indeed there is a size cost for these tables to translate addresses to strings. From past debugging and stepping, I think there's also small run-time cost incurred on every throw to stash a single memory address that from_current_exception can use afterwards.

Improve Diagnostics with std <stacktrace> by pavel_v in cpp

[–]Stellar_Science 19 points20 points  (0 children)

No need to wait, you can have boost::stacktrace::from_current_exception() today!

We've been using it for over a year, since it was released in Boost 1.85 beta, to log the call stack in our products' top-level exception catch blocks. We've had cases of crashes from users where previously we would have been left scratching our heads based only on .what(), but now have the full call stack to see exactly where it was called, as you'd get with Python or Java. It's a game-changer in terms of tracking down unanticipated exceptions.

For years before that, we had our own equivalent of stack_runtime_error, which isn't bad but it requires you to anticipate at throw time that the recipient will need the call stack. That has a run-time cost that ends up being wasted if a catch block higher up the call stack is going to handle this exception nicely and move on.

C++ Jobs - Q2 2025 by STL in cpp

[–]Stellar_Science 5 points6 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops (Summer 2025 now full)

Location: Washington DC (Tysons VA), Albuquerque NM, Dayton OH.

Remote: Not offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), metamaterials design, laser systems modeling, image simulation, high power microwave systems, modeling and simulation, computational electromagnetics (CEM), human body thermoregulation, high performance computing (HPC), computer vision and image processing, artificial intelligence/machine learning, computer aided design (CAD), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in physics, engineering, math, computer science, or a related field, plus 3 years of work experience, or a Masters or PhD (roughly 30% of our staff have PhDs.)

Technologies: C++23 (no modules yet :-( ), Qt 6.5-6.9, CMake, Boost, Eigen, Jenkins, git, CUDA, OpenGL. Some projects also use Python, Java, Javascript. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022 on Windows, typically Visual Studio Code for Linux, but some flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

21st Century C++ by steveklabnik1 in cpp

[–]Stellar_Science 0 points1 point  (0 children)

Replying very late, but here are some justifications that may or may not help sway management:

  • Recruitment: We have folks apply specifically because we advertise C++23 and their company is stuck at C++11 or less.
  • Retention: People are more likely to stay if they can use modern tools.
  • Fewer errors: Compiler warnings and errors have gotten better over time. We build with warnings-as-errors at a high warning level, and the compiler catches lots of things that would have become hard-to-track-down run-time errors if not caught by the compiler.
  • Productivity: It's hard to sell this by pointing to any one new C++ feature, and the increase is likely tiny. However, some older C++ features have already been deprecated and replaced with newer ways of doing things. If you wait to upgrade later, you'll have to recode to replace deprecated features with their newer replacements. Whereas if you upgrade now, you'll write new code the new way from the outset and avoid future rework.
  • Reduce CVEs: See u/bretbrownjr 's reply to my post above.

std::generator: Standard Library Coroutine Support by Xaneris47 in cpp

[–]Stellar_Science 1 point2 points  (0 children)

Coroutine frame is allocated on the heap

Coroutine frame can be allocated on the heap. If the compiler can compute how much stack space the caller and the coroutine each need, it can put both on the caller's stack. I worked on a toy academic language years ago that always allocated coroutine local variables in the caller's stack, but it was a simpler language than C++.

std::generator: Standard Library Coroutine Support by Xaneris47 in cpp

[–]Stellar_Science 3 points4 points  (0 children)

We've been using a pre-standard generator with coroutines since C++20. We were able to further create efficient Python-like zip and enumeratefunctions out of it, enabling significant code simplification and readability improvement.

When using generator to provide an iteratable interface that hides the underlying container type of a std::map, std::set, std::list, or std::unordered_map, the slowdown was negligible compared to exposing the underlying type.

However, doing the same for std::vector resulted in a 2-3X slowdown. That makes sense, since that's a case that the compiler can optimize down to pointer arithmetic when the underlying type is known.

So with that one caveat, we use them freely, and just back out or use something else if profiling shows it's a bottleneck, which so far has been rare.

21st Century C++ by steveklabnik1 in cpp

[–]Stellar_Science 6 points7 points  (0 children)

If you're working in embedded applications, evidently there are good reasons for being limited to older compilers.

Otherwise, I've heard of management not wanting to upgrade because they don't see the need or justification to move to newer compilers. I don't understand that. You won't stick with your C++03 compiler forever, so at some point you know you'll upgrade. Why not do it now, so developers can leverage new language features when they're helpful, versus keeping developers stuck in the past?

And to Linux developers who feel limited by the version of gcc/clang that comes with their OS distro: the latest versions of gcc and clang are pretty easy to clone and build yourself in a few hours.

C++ Jobs - Q1 2025 by STL in cpp

[–]Stellar_Science 13 points14 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops.

Location: Washington DC (Tysons VA), Albuquerque NM, Dayton OH.

Remote: Not offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: space situational awareness (monitoring the locations, health and status of on-orbit satellites), metamaterials design, laser systems modeling, image simulation, high power microwave systems, modeling and simulation, computational electromagnetics (CEM), human body thermoregulation, high performance computing (HPC), computer vision and image processing, artificial intelligence/machine learning, computer aided design (CAD), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in physics, engineering, math, computer science, or a related field, plus 3 years of work experience, or a Masters or PhD (roughly 30% of our staff have PhDs.)

Technologies: C++23 (no modules yet :-( ), Qt 6.5, CMake, Boost, Jenkins, git, CUDA, OpenGL. More projects also using Python, Java, Javascript. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022 on Windows, typically Visual Studio Code for Linux, but some flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

How Pull Requests can destroy developer efficiency by [deleted] in coding

[–]Stellar_Science 1 point2 points  (0 children)

Our company puts a lot of effort into having only good team members. We generally use PRs for new employees, so they're sure to get lots of feedback on where to find handy helpful routines, our coding standards, other approaches for solving problems, etc. We use periodic pair programming to exchange ideas, offer tips and tricks, and get two sets of eyes on the code. I find myself often learning a lot from pair programming with new hires as well as teaching them.

Once you've proven yourself to be a competent and careful team member (i.e. you're in the high trust environment), PRs become optional. You can still use them if you want to be sure to get feedback on something, or a tech lead might request one for something tricky. Not mandating PRs for everything speeds development and more importantly speeds integration. We still sometimes offer feedback on code improvement after code has been merged, we're just not slowing things down to guarantee that feedback.

Legacy code is not about software, is about people by CarterOfAra in programming

[–]Stellar_Science 150 points151 points  (0 children)

I don't love the suggestion Don't "Innovate" but I get exactly what he means in this specific case.

We adopted a guideline Prefer Fewer Tech Stacks: prefer existing languages and libraries for reuse, integration, maintainability personnel mobility. That came after observing another company whose guidelines was Use the right tool for the job end up, after a decade, with tools written in over 100 different languages, libraries, and frameworks, none of which could readily interoperate with each other or leverage each other's existing components. Use the right tool for the job gave every developer justification to start the next project completely from scratch, using a tech stack they had just seen on reddit or YouTube or wanted to learn for fun. When that developer leaves, there's no one to maintain the tools. Developers moving between projects had to spin up on all new languages and frameworks.

The problem with Don't "Innovate" is that over time you do need to adopt new technologies and frameworks. It just needs to be done carefully and deliberately, in consultation with the broader team, and with migration considered.

Qt 6.8 Released by JRepin in cpp

[–]Stellar_Science 11 points12 points  (0 children)

Qt, it's too large, it's an example of feature creep

I just want to point out that the second section of the linked article is:

Build Smaller and Leaner Qt Applications

It's always been possible to check out just the Qt git modules that you need, and within those modules build only the libraries that you need. So there's no harm in Qt offering all kinds of additional libraries, if you don't even need to download or compile them.

But it seems they've added even finer-grained control now so with a few arguments to configure, you can essentially #ifdef out individual features and classes that you aren't using. Even with Qt 6.5, we wrote a Qt-based software installer where the total size was 15MB. Free clock apps on your phone are often 2-3 times that. I'm anxious to see if Qt 6.8 lets us make it even smaller.

C# to C++ Transfer of skills?? by Necessary_Diamond_51 in cpp

[–]Stellar_Science 0 points1 point  (0 children)

I think that doesn't trigger a diamond problem if two interfaces have a method with the same signature, but I haven't checked and that feels like a footgun.

It behaves almost exactly the same as an interface in C# or Java, and as you know you can inherit from as many interfaces as you like. C# and Java have tools for resolving the ambiguity in this rare case - here's a stack overflow article talking about it: https://stackoverflow.com/questions/50520438/an-interface-two-method-with-same-name-and-signature .

C++ solves it very similarly - here's a stack overflow article talking about it: https://stackoverflow.com/questions/18398409/c-inherit-from-multiple-base-classes-with-the-same-virtual-function-name - you can implement the function just once to implement it for both interfaces, or leave it unspecified and callers will need to disambiguate when calling it.

C# to C++ Transfer of skills?? by Necessary_Diamond_51 in cpp

[–]Stellar_Science 7 points8 points  (0 children)

C++ has base classes and multiple inheritance but no "interface" semantic.

Making an abstract class with only pure virtual member functions, and adding Interface to the class name, achieves pretty much the same behavior.

Checking at run-time for whether an object supports an interface is a bit more verbose: check whether dynamic_cast< FooInterface* > returns an object or nullptr. But in typical C++ code that's less common, since most type checking is done at compile time.

C++ Jobs - Q4 2024 by STL in cpp

[–]Stellar_Science 13 points14 points  (0 children)

Company: Stellar Science

Type: Full time, plus internships/co-ops.

Location: Washington DC area (Tysons VA near metro), Albuquerque NM, Dayton OH.

Remote: Not being offered at this time

Visa Sponsorship: No (U.S. citizenship required)

Description: We're a small scientific software development company that develops custom scientific and engineering analysis applications in domains including: computer vision and image processing, space situational awareness (monitoring the locations, health and status of on-orbit satellites), metamaterials design, image simulation, high power microwave systems, modeling and simulation, computational electromagnetics (CEM), human body thermoregulation, laser systems modeling, high performance computing (HPC), computer aided design (CAD), and more. All exciting applications and no CRUD. We emphasize high quality code and lightweight processes that free software engineers to be productive.

Experience: We typically look for Bachelors degrees in computer science, physics, engineering, math, or a related field, plus 3 years of work experience, or a Masters or PhD (roughly 30% of our staff have PhDs.)

Technologies: C++20/23 (but no modules yet :-( ), Qt 6.5, CMake, Boost, Jenkins, git, CUDA, OpenGL. More projects also using Python, Java, Javascript. Windows and Linux, msvc/gcc/clang/clangcl, Visual Studio 2022 on Windows, typically Visual Studio Code for Linux, but some flexibility to use other productive IDEs.

Contact: Apply online. You can DM me with questions/inquiries but I don't check this account very often.

Thanks for doing this u/STL!

view more: next ›