And it's not possible to use these tools and libraries as plug-in and -out?
I mean, for example, for people interested in these, and some of our
buildbots, to do "configure+build using libc++ and LLVM" in order to get
more info about the code they write in ROS,
and in such a way that it is also possible for other people who want to
build ROS with e.g. MSVC 2010, to instead "configure+build using MSVC 2010 +
older lib" ? 


-----Original Message-----
From: Ros-dev <> On Behalf Of Victor Perevertkin
Sent: 18. prosinca 2020. 05:13
To: ReactOS Development List <>
Subject: Re: [ros-dev] Status Meeting (November 2020)

Many words were said already about dropping the support for old compilers. I
agree with all of them and want to put one more argument on top of it from

There are a lot of innovations happen in compilers and tooling. Big
companies put thousands of man-hours to improve compiler toolchains and
standard libraries (LLVM and libc++ are the headliners here - everything
goes there first).
It's silly not to use all of those, it makes finding bugs easier by orders
of magnitude (modern C++ makes you write code with less bugs too, but that
has been said already).
For example, AddressSanitizer will show you out of bounds access right where
it happened, with stack trace and memory contents.

But there is one thing here, it doesn't work without the standard library
support. Of course, we can write that into our own lib (stlport?),
reinventing the wheel. But isn't it better to spend time on something
ReactOS-related, where there is no open source code available at all? (note:
I'm asking about who is going to do that)

And if we choose to incorporate libc++ into our project, which supports all
of that tooling out of the box for Windows, we have another problem
- it can't be compiled with ancient compilers.

So basically, the choice is simple - either we support building ReactOS with
old compilers (this is not only about MSVC2010, but for everything which
doesn't support modern-enough C++), or we benefit from modern tech for
dynamic and static code analysis. I prefer the latter.


Ros-dev mailing list

Ros-dev mailing list

Reply via email to