0

I would like to speed up the compilation time of a legacy C++ project with millions of lines of code. I didn't find any compiler benchmarks focusing on refactoring the "most vexing parse" described by Scott Meyers https://en.wikipedia.org/wiki/Most_vexing_parse I have a theory: If I was able to check my code for these cases, I could speed up the compilation. The check for the most vexing parse would be nice in clang-tidy to achieve this target. By refactoring the findings I plan to speed up the compile times. Is it worth it? What do you think?

Robert
  • 53
  • 1
  • 6
  • why do you think this would speed up compilation? – 463035818_is_not_an_ai Jun 22 '22 at 09:55
  • I dont think it is possible to distinguish between a vexing most vexing parse and an intended one – 463035818_is_not_an_ai Jun 22 '22 at 09:57
  • @463035818_is_not_a_number I don't know if this speeds up the compilation, but Scott Meyers is suggesting it. – Robert Jun 22 '22 at 10:04
  • can provide a reference or quote? I'd be curious to learn from Scott – 463035818_is_not_an_ai Jun 22 '22 at 10:04
  • 2
    is it possible that you misunderstood? I only found this article https://www.fluentcpp.com/2018/01/30/most-vexing-parse/ which talks about time you need to spend fixing compiler errors due to the most vexing parse. However, that only applies when there is a compiler error in the first place, it does not refer to time taken for compilation, and applies even less when compiling legacy code (which should be safe to assume that its free of compiler errors) – 463035818_is_not_an_ai Jun 22 '22 at 10:09
  • It is possible that I misunderstood. "The most vexing parse is a counterintuitive form of syntactic ambiguity resolution in the C++ programming language. In certain situations, the C++ grammar cannot distinguish between the creation of an object parameter and specification of a function's type. In those situations, the compiler is required to interpret the line as a function type specification." [https://en.wikipedia.org/wiki/Most_vexing_parse]( wikipedia) In my interpretation this means, the compiler goes the extra mile to interpret the disambiguity and by fixing this, I can speed it up. – Robert Jun 22 '22 at 11:07
  • 1
    for the compiler there is no issue nor ambiguity. The rule says: If it can be a function declaration then it is one, and that what the compiler assumes. The ambiguity is for the human reader. Suppose you want to delcare a "a function time_keeper that returns an object of type TimeKeeper and has a single (unnamed) parameter, whose type is a (pointer to a) function taking no input and returning Timer objects." then that is `TimeKeeper time_keeper(Timer());`. The issue only arises when you write the same because you wanted to define a variable called `time_keeper` – 463035818_is_not_an_ai Jun 22 '22 at 11:12
  • The "extra mile" is `if (could_be_function(ast)) type = Type::function_declaration; else type = Type::local_variable;`, which does not noticeably adversely impact compilation time. – Eljay Jun 22 '22 at 11:25
  • 1
    No, on a practical level, this is probably doomed. The "most vexing parse" refers to things that an experienced programmer reading the code will misinterpret. There are benign applications of this rule, the most common being `int f();`. Yes, beginners sometimes write something like this to try to create an object named `f` of type `int`, but after a while we all know that this is a function declaration, and that's what the rule gives us. – Pete Becker Jun 22 '22 at 12:49

0 Answers0