[Please do not mail me a copy of your followup]
"James K. Lowden" <jklo...@speakeasy.net
> spake the secret code
>On Fri, 26 Feb 2016 09:31:19 CST
>嘱 Tiib <oot...@hot.ee
>> C++ has relatively good development tool support, large amount of
>> libraries (like that Qt)
>It's funny you say that. I've always found C++ libraries (outside
>Boost) to be quite scattered and of variable quality. Just to take one
>example, Stroustrup frequently cites a standard DBMS library as an
>important void. C ++ has nothing resembling the CPAN for Perl, for
>example. I'd argue Python's library support is much better.
It seems the community agrees with you about package management.
There are many parallel efforts on this front. The one I like is
>On the tool side, I suppose if you're programming in Windows you have
>pretty good project & debugging support, once you squelch the
>self-serviing warnings about using standard library functions.
Recent releases of Visual Studio have gotten better about the defaults
being more oriented towards ISO C++. For instance, the new console
project template no longer includes <tchar.h> and supplies the
TCHAR-ized version of main. Instead you get a reasonable default
project with an ISO C++ standard main function.
>helps you better with their libraries than yours, though. You can
>highlight fopen and press F1 or whatever to see the documentation, but
>afaik there's no feasible way to reproduce that support for private
While this would be nice, let's be honest and F1 in Visual Studio
these days just does a glorified web search. The content isn't even
installed locally anymore by default, although you can install
documentation for the local help viewer if you prefer to work
"disconnected". When I've asked other VS C++ developers about the
help viewer (I actually think the old one was better), most of them
said they never used the help viewer and just used google. So if your
API documentation is visible to google (and not all of them are), then
what developers are already doing is going to be just fine.
>And of course you have to be prepared with Visual Studio's
>definiton of "project", keep up with its continual churn.
I'm not sure which "churn" you're talking about here. Are you talking
about changes to project files because of files being
renamed/added/removed to a project or are you making some reference to
new version of Visual Studio changing the project file format?
If the former, I've found that CMake is a pretty good way of handling
that -- use CMake for you build and don't commit the project files
and things stay up-to-date as you edit the CMake project description.
Works great for Xcode on Mac and CLion on Linux too. Of course this
requires that you switch to using CMake as your build description.
For new projects, this is what I would recommend. For existing
projects, you have to weigh the day-to-day pain of maintaining your
existing build vs. the pain of converting to CMake and it's day-to-day
pain of maintenance.
If the latter, you should be aware that VS has kept compatible project
and solution file formats for the last 5 years, since VS 2010.
>On Linux we're still partying like it's 1995,
More like 1989, LOL.
>In my experience with large code bases -- millions of lines --
>otherwise adequate tools just fall over. Visual Studio simply did not
>function with 1000's of files in 2013.
Every day I work in VS on a solution with 121 projects, ~5800 files
and about 1M lines of code. Our solution/projects are VS 2010
oriented, but I've recently switched to the VS 2015 IDE using the 2010
toolset. ReSharper for C++ can get quite sluggish at times while
chewing on this solution, but that's the only real big delay that I'm
noticing in either VS 2010 or VS 2015. The benefits of R++ make it
worth the wait.
I used to routinely turn off intellisense in VS because it's results
were inaccurate, slower than grepping the source code, and it caused a
huge delay in processing solutions. In VS 2015, I turned it back on to
evaluate Microsoft's refactoring support and it seems much improved vs
earlier releases, but I still use R++ for navigation instead of VS
Of course, you should also be turning off virus scan and content
for your source and build trees. Both of those cause constant
of the files in your project and create disk contention for VS and
the compiler. Switching to a solid-state drive also helps :-).
>I've never seen any tool that
>could deal with giant code bases and do simple things like jump to a
>function definition or find all the places where a given function is
>called. (cscope will, but it can't distinguish between a.f () and b.f
>()). On the evidence, there's no market for tools for large
>codebases. Either no tools exist or, if they do, many firms that would
>benefit from them choose not to.
clang's tool infrastructure is attempting to address this somewhat.
clang-tidy supports both invoked-from-the-editor and invoked-as-batch
type interactions to address refactoring on a larger scale. I would
expect that the support people are using to integrate clang into vim
and so-on would also help with navigation, although I haven't tried
those myself as I work in CLion on Linux and VS on Windows. CLion
does it's own parsing and again takes a while to chew on a very large
project like LLVM+clang+clang-tools-extra. It feels like it takes
even longer than ReSharper for C++, but I don't know if that's due to
the differences in projects (LLVM+etc. vs. where I work) or due to
Java vs. C#/C++ implementations or differences in parsers or whatever.
>Some of these issues could be solved by reflection: [...]
Yeah, somewhat. However, I think modules are going to make a huge
difference for IDEs because the vast majority of the time spent
chugging in order to provide navigation and refactoring support is due
to the reparsing induced by changes to headers.
"The Direct3D Graphics Pipeline" free book
The Computer Graphics Museum <http://computergraphicsmuseum.org
The Terminals Wiki <http://terminals.classiccmp.org
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com