The preprocessor is the difficult part of parsing C++? Are you serious?
Preprocessing is string replacement. It's about as simple as it gets. The C/C++ text preprocessor could be implemented entirely without context tracking or really anything more sophisticated than a handful of regular expressions and a couple of driver loops (just saying theoretically - that's not how it's really done in real compilers). Skip out the esoteric things like variadic macros and a first year CS student could write the preprocessor in BASIC.
C++ is difficult to parse - and, therefore, difficult to provide syntax completion hints for - because the syntax grammar itself is a nightmarish mess. There are so many corner cases and ambiguities that the parser has to do an obscene amount of backtracking and state management just to know how to interpret a line of code.
C# (and many other languages, including Java, VB.Net, et. al.) do not provide such messy grammars. That is the fundamental reason why parsing them is easier.
The presence of cached metadata in .Net assemblies is also a red herring; Visual C++ does something very similar (ever seen the .NCB file in your solution folder?).
Incremental parsing is a difficult thing to do to begin with, and doing it in a terrible language like C++ is even harder. VS2010 has a totally rewritten incremental C++ parser, which is the source of the improvements in Intellisense in that release.
Intellisense and C++
Quote:Original post by ApochPiQ
C++ is difficult to parse - and, therefore, difficult to provide syntax completion hints for - because the syntax grammar itself is a nightmarish mess. There are so many corner cases and ambiguities that the parser has to do an obscene amount of backtracking and state management just to know how to interpret a line of code.
Noteworthy reference.
The nightmarish part comes from supporting arbitrary non-standard under-specified once-in-a-blue-moon exceptions.
With advent of standardized C++, this legacy code might slowly fade out of existence, at least for most major platforms. It's still hard work, but somewhat simpler, since one can aim for standard up-front, rather than incrementally adding workarounds.
Quote:Preprocessing is string replacement. It's about as simple as it gets.
Interestingly enough, I've found that to be where the most time is spent.
Includes may need to scan through hundreds if not thousands of headers. That is a lot of blocking IO. Next, all the symbols must be expanded and transformed. There are a lot of symbols and a lot of text replacements. While fairly trivial, it's a time consuming task, having a lot to do with
Try an experiment (varies depending on headers included). Tell your compiler to output pre-processed file. Then measure compilation of the original vs. compilation of pre-processed output.
The difference, especially when using boost or similar can be a factor of 10.
ccache exists to solve this problem, and it can considerably reduce build times. In part since most compilers forget entire state between compilation units, so common headers are fully pre-processed each time, with same parameters.
Oh, you're absolutely right that the preprocessor (especially #include mazes) is probably the front-runner for the most time consuming part of parsing C++ - the advent of precompiled headers should more than attest to that fact.
I'm not saying that preprocessing is fast; just simple.
Another great and relevant experiment, as tried by a guy I work with: build a large C++ project on a machine with a single standard platter hard drive. Then rebuild it cleanly on an identically specced machine with a RAID 0 of SSDs.
I'm not saying that preprocessing is fast; just simple.
Another great and relevant experiment, as tried by a guy I work with: build a large C++ project on a machine with a single standard platter hard drive. Then rebuild it cleanly on an identically specced machine with a RAID 0 of SSDs.
Quote:Original post by ApochPiQ
Oh, you're absolutely right that the preprocessor (especially #include mazes) is probably the front-runner for the most time consuming part of parsing C++ - the advent of precompiled headers should more than attest to that fact.
I'm not saying that preprocessing is fast; just simple.
Another great and relevant experiment, as tried by a guy I work with: build a large C++ project on a machine with a single standard platter hard drive. Then rebuild it cleanly on an identically specced machine with a RAID 0 of SSDs.
I think part of what makes dealing with real-time code hinting difficult -is- the fact that the preprocessor is time consuming (regardless of implementation complexity or simplicity) but people aren't going to stop typing just because you still have a bunch of stuff to parse.
Quote:Original post by M2tM
I think part of what makes dealing with real-time code hinting difficult -is- the fact that the preprocessor is time consuming (regardless of implementation complexity or simplicity) but people aren't going to stop typing just because you still have a bunch of stuff to parse.
Intellisense for modules not being actively edited is not generated in real time. It is cached in files like the browse information (.ncb) and browser source cache (.bsc) project resources.
Quote:Original post by ApochPiQ
Then rebuild it cleanly on an identically specced machine with a RAID 0 of SSDs.
Which is, regardless of whenever it yields any significant speed savings or not, extremely stupid. The number of times you can write to a SSD is, albeit high, limited. Considering how much memory modern machines have, a better idea is to use a RAM-mounted tmpfs as the project's build directory - you get freed from whatever IO-limitations you would have *and* you don't induce any unnecessary wear on your SSD.
I haven't upgraded to VS 2010 yet, but if its code hinting is anything like 2008, then I can't recommend Visual Assist X enough. At least in 2008 it makes C++ intellisense MUCH more accurate, on top of a host of other features (automated refactoring OMG so useful)... it's really worth every penny. I can hardly use Visual Studio without it anymore :)
That said, I understand 2010 is supposed to have improved parsing for intellisense, so I don't know if it'd be as important for that version.
That said, I understand 2010 is supposed to have improved parsing for intellisense, so I don't know if it'd be as important for that version.
Quote:Original post by phresnel
The amount of macros used in good C++ code is negligible. And thus, they don't participate relevantly in compilation time.
It's not the code you write, it's all of the headers you pull in from libraries, windows (if you're using windows), etc. there's a lot of conditional compilation in *those* at least. Take a look in windows.h, just for a laugh.
Quote:Original post by phresnel
The point is that you pretended, after some contextual inlining, that C# does not have to be compiled to reap meta information from it, which is wrong. Period.
I don't think I said that. My point was that it's just much cleaner especially in terms of conditional compilation. The point I made was the same point that the guys actually writing the intellisense feature have said. If I'm contradicting you, I'm not contradicting them, and they're the experts.
Quote:Original post by phresnel
Tbh, I am unsure why you constantly change your intentions and consensus from post to post, and counter derive untrue things afterhand about non existent posts, like me implying things about what you've said but which you did not say in reality. Get some sleep and stop becoming personal.
I didn't. I'm not being personal. I'm simply pointing out that if you want to know what's up with intellisense and why it was hard to implement for them up to 2008, then read what they guys who were responsible for implementing it have said. 2010 is almost up to standard, but it's still not as good as the .NET equivalent. I don't think I've said anything particularly controversial here. All I've done is disagreed with you as you seem to be implying that it's no more difficult to parse C++ over C# and therefore the reason intellisense is inferior for that language over C# is a mystery. Well, it's not really a mystery, as the guys who write the feature have explained why they had problems with it.
My only complaint with VS2010's Intellisense for C++ is that it no longer shows the argument list when you are writing out a function that has already been declared earlier (function prototypes or in a class definition in a header). I've very quickly learnt to live without this as that stability, reliability and performance has been greatly improved and the C# style red squiggly lines (not sure of the technical term, heh) means I rarely see compiler errors when building anymore :)
For larger projects I've found that building the SDF file from scratch is light years faster than NCB files in 2008... I converted some 2003 projects over to 2008 when it first came out and it took an age to build the database.
Still, if anyone has a solution for my little issue above it would be quite appreciated, but doesn't really matter much anymore.
For larger projects I've found that building the SDF file from scratch is light years faster than NCB files in 2008... I converted some 2003 projects over to 2008 when it first came out and it took an age to build the database.
Still, if anyone has a solution for my little issue above it would be quite appreciated, but doesn't really matter much anymore.
Quote:Original post by BurnhardQuote:Original post by phresnelQuote:Original post by Burnhard
C# does, but you can't build macros with them, so they don't have a huge effect on source files in a deeply nested structure many layers of includes away.
The amount of macros used in good C++ code is negligible. And thus, they don't participate relevantly in compilation time.
It's not the code you write, it's all of the headers you pull in from libraries, windows (if you're using windows), etc. there's a lot of conditional compilation in *those* at least. Take a look in windows.h, just for a laugh.
You were missing your own quotation, though, which was a bit unclear, but goes more into macro-expansion than #include-preprocessing.
Anyways, I don't #include <windows.h>, because I only pull in what I need and also normalize the include hierarchy where applicable. And because I don't use windows. But still, it's slow, mostly because of deep template code and lookup issues.
Quote:Quote:Original post by phresnel
The point is that you pretended, after some contextual inlining, that C# does not have to be compiled to reap meta information from it, which is wrong. Period.
I don't think I said that.
Yes you did:
Quote:Burnhard
Also remember that C++ intellisense is hard to do for VS (in fact it was often totally broken in earlier versions). It has to do a partial compile in the background in order to generate its symbol database.
Argumentum e contrario, this means that C# intellisense is easy to do, because either
* it has to do a complete compile ...
* or it has to do no compile in order to generate its symbol db
. Neither is correct, hence
Quote:phresnel
Burnhard was wrong, as every language must be [partially] compiled to reap information from it.
Yet you reply:
Quote:Burnhard
I'm not wrong.
and pretend that one
Quote:[...] just need to read the blogs of the actual people who develop these things and then you will know why intellisense and C++ don't work too well together.
but then I've
Quote:phresnel
[...] read them.
And now
Quote:I know that you haven't read && understood them yourself, because it also explains some of the reasons why parsing C++ is slow, yet you start guessing that it is because of conditional compilation, but which is only a subset of the mix.
Quote:Burnhard
If I'm contradicting you, I'm not contradicting them, and they're the experts
You obviously don't know the meaning of compiling, otherwise you could read from the articles you linked to that they "parse" code to create something else, meta information in this case -> a.k.a. compiling.
Quote:Quote:Original post by phresnel
Tbh, I am unsure why you constantly change your intentions and consensus from post to post, and counter derive untrue things afterhand about non existent posts, like me implying things about what you've said but which you did not say in reality. Get some sleep and stop becoming personal.
I didn't. I'm not being personal.
Implicitly you are (maybe not directly to me, but at least to a handful of ppl in this thread):
Quote:read the blogs of the actual people
Quote:If I'm contradicting you, I'm not contradicting them, and they're the experts.
Quote:If you did, you wouldn't be busy contradicting them. [hint: I didn't]
You know, there also exist experts outside of Microsoft. Of the kind who understand what the Microsoft experts write in their blog entries. And up until now, you haven't shown any evidence that you understood it.
Quote:Well, it's not really a mystery, as the guys who write the feature have explained why they had problems with it.
Exactly.
Quote:you seem to be implying that it's no more difficult to parse C++ over C# and therefore the reason intellisense is inferior for that language over C# is a mystery.
I dunno, do you even try to understand what I am saying, have you given only a flying fuck to what people are trying to explain to you?
I did not say that C++ is as easy to compile as C#, because I absolutely know better, e.g. because metatrace is one of my humble creations:
Quote:metatrace
Metatrace is a C++ compile time ray tracer
and if you follow the links
Quote:I think the render time was 14 hours
for a scene as simple as
yet the #include hierarchy is flat and no macro was harmed.
What I actually said is that conditional compilation is not the number one reason for C++ being hard to compile:
Quote:phresnel
Anyways, for the curious, the reason why C# is faster to parse than C++ is that C++ contains many highly ambiguous parts, that is, pieces of source code can be arithmetics, declarations or something else, depending on sometimes large context.
Which most importantly includes templates and metaprogramming, and C++'s subtle lookup, and the combination of both, and the fact that C++ compilers must conserve a large amount of context during compilation, because of templates, subtle lookup, and ambiguous highly context-sensitive grammar. All was implied in that quote.
Now, go back, find a single facking quotation where I claim, implicity or explicitly, that C++ is easy to parse, as easy as C#. Then find out that it's better for you to stop pretending untrue things and that you prolly should no longer participate in this thread. Don't try again to defame anyone by quoting articles that you have not even read yourself, claiming things about it that or not true, and then re-emphasize your own fragile claims by stating that they and only they are the experts, in contrast to other C++ programmer participating in this thread of whom obviously no one is an expert, denying the article's true content.
[Edited by - phresnel on July 8, 2010 8:18:12 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
