-1

I have been lately looking into GoLang -- coming from C++ background-- I am reading a paper which allegedly explains the reasoning behind making Golang, here is its link: https://talks.golang.org/2012/splash.article

One of the claims being is, handling Dependencies (Package) in C and C++ is pain and takes on a #ifndef guard instance to state

The intent is that the C preprocessor reads in the file but disregards the contents on the second and subsequent readings of the file...

I referred a GCC page for the same, https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html.

so that if the header file appears in a subsequent #include directive and FOO is defined, then it is ignored and it doesn’t preprocess or even re-open the file a second time

Go: "Reads in and disregard" vs GCC: it doesn’t preprocess or even re-open the file a second time.

Doesn't contradict?

your thoughts are appreciated. Thanks for Reading my question.

RaGa__M
  • 2,550
  • 1
  • 23
  • 44
  • No. The one is a nonstandsrd extension to C which applied only in certsin circumstances. – Volker Mar 27 '21 at 15:54
  • @Volker, can you elaborate? – RaGa__M Mar 27 '21 at 16:01
  • @Volker: I wouldn't call this an "extension" because, unless I misunderstand, it doesn't change observable behavior in any way. I think it's an *optimization* that has no effect on standard conformance. – Nate Eldredge Mar 27 '21 at 16:40

1 Answers1

0

The first passage is talking about a generic compiler, which, conceptually speaking, should read the contents of the file and disregard the contents (because they are #ifdefd out). That is, roughly, what the C standard specifies a compiler should do.

But practically everything in the C standard is under the "as if" rule - a compiler does not actually have to be implemented in the way suggested in the standard, so long as the end result it produces is exactly the same in every case. As such, GCC's particular implementation adds an optimization where, in cases where it can tell with certainty that the contents of the file would be disregarded, it doesn't actually read it. This is perfectly fine because it still behaves as if it has read the file but disregarded it.

Note that other compilers do not necessarily do the same.

Nate Eldredge
  • 48,811
  • 6
  • 54
  • 82
  • can you quickly share the link to that C spec passage, meanwhile I am searching it too... – RaGa__M Mar 27 '21 at 16:07
  • @RaGa__M: The general as-if rule is 5.1.2.3 (6) point 2 (in C17). For the preprocessor in particular, 5.1.1.2 (1) note 6 emphasizes that the description of preprocessing is conceptual. – Nate Eldredge Mar 27 '21 at 16:12
  • Have you got the link to that Spec? – RaGa__M Mar 27 '21 at 16:18
  • @RaGa__M: See https://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents. I am looking at https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf – Nate Eldredge Mar 27 '21 at 16:22
  • "The general as-if rule is 5.1.2.3 (6) point 2 (in C17)" @Nate Eldredge, correct me if am wrong "5.1.2.3" talks about "Program execution" and "5.1.2.3 (6) point 2 (in C17)" seems irrelevant to the 'as-if' rule you are referring. – RaGa__M Mar 27 '21 at 18:15
  • @RaGa__M: Yes, that's about execution, but my point is that the program executes exactly the same whether this optimization is made or not. I agree that 5.1.1.2 is more directly relevant here. – Nate Eldredge Mar 27 '21 at 19:25
  • "program executes exactly the same whether this optimization is made or not"_____I think you are missing the point, Go claim is all about reducing the compilation time, saying Dependencies in C and C++ is pain although in practice one of the majorly used C compiler (GCC) does what exactly they have been looking for, so their claim contradicts the Reality, moreover, the optimization in question is really simple to achieve -- make a conditional readFile call. – RaGa__M Mar 27 '21 at 19:46
  • It's not clear whether the author of the Go article was aware of GCC's multiple-include optimization, or maybe it hadn't yet been introduced at that time (in 2012). The phrase "without great cleverness" suggests they had an idea that some optimizations might be possible. It's also true that the GCC optimization only applies under particular circumstances, which may not be met in the cases that the Go people are interested in. – Nate Eldredge Mar 27 '21 at 19:52
  • 1
    @RaGa__M: But it seems more likely that the Go people are more interested in talking about how their language avoids the issue *altogether*, rather than about how other designs might be able to mitigate it in some situations. // Anyway, I think that will be my last reply on this question - I'm afraid it's not really that interesting to me. – Nate Eldredge Mar 27 '21 at 19:54