In C there are precompiled headers which avoid the recompilation. > On Nov 13, 2020, at 7:18 PM, kev kev <kevthemusic...@gmail.com> wrote: > > > Thanks for the answer. If C/C++ has object files, is it not possible to see > “something.h” and then fetch the corresponding object file? > > With go, if I import “package something” and that package imports another > package called “package bar” then at some point I will need to compile “bar” > and “something”. This to me is like your header example. > > I think you are maybe saying that this traversal is only done once for > golang and the information is stored in an object file? While in C, the > header traversal is done each time I see include? >> On Saturday, 14 November 2020 at 00:14:41 UTC Kevin Chowski wrote: >> C/C++ also has object file caching (depending on how your build is set up, I >> guess). In C/C++ the issue is that you need to possibly open a large number >> of header files when you import any header file. >> >> For example, if I write a file "main.c" which imports "something.h", which >> in turn imports "another.h" and "big.h", and compile just main.c, the >> compiler has to open all three header files and include them in the parsing >> of main.c in order for the compilation to correctly move forward. In Go, the >> compiler arranges things such that it only has to open one file per package >> that is imported. The post you linked goes into greater detail, so I will >> avoid duplicating the details for now, but feel free to ask a more specific >> question and I can try to answer. >> >> There's a bit of nuance there, which the post also goes into: Go's strategy >> ends up requiring that some package much be compiled before any package >> which imports it is compiled. In C/C++ the ordering is a little more >> flexible due to the more decoupled nature of header files, meaning that >> theoretically more builds could occur in parallel. But I suspect that in >> your average Go program the dependency tree would still allow you to execute >> a large number of builds in parallel. >> >> Also note that the article claims this is "the single biggest reason" Go >> compilation is fast, not the only one. There are lots of smaller, yet >> important, reasons as well. For example, parsing the language is pretty >> straightforward because it is not very complex, and linking the final binary >> together is continually being optimized. Plus there are no turing-complete >> meta-language features like the templates C++ compilers have to deal with ;) >> >> As for your following, the whole set of files in some package are the >> compilation unit, at least as far as I understand the terms. This is because >> if a.go and b.go are both in the same package (e.g. in the same directory), >> code in a.go can call code in b.go without explicitly declaring anything. So >> before the code in a.go can be fully compiled into an object file, b.go must >> be considered as well. >>> On Friday, November 13, 2020 at 3:54:34 PM UTC-7 kev kev wrote: >>> I recently read the post by Rob Pike about language choices for Golang: >>> https://talks.golang.org/2012/splash.article#TOC_5. >>> >>> The seventh point refers to how Golang handles dependencies. It mentions an >>> "object file" for packages that a _dependent_ reads. >>> >>> Below I go through my interpretation of this section: >>> >>> Example: >>> >>> package A imports package B. >>> >>> When I compile package A, package B would have already been compiled. What >>> package A receives is not the AST of package B, but an "Object file". This >>> object file only reveals data about the publicly accessible symbols in that >>> package. From the example, if B had a private struct defined inside of it, >>> this private struct would not be in the object file. >>> >>> This part seems to make sense for me, hopefully I did not make any mistakes. >>> >>> It seems that the speedup compared to C/C++ is because the object file is >>> created once per package, while in C/C++ you need to re-compile the thing >>> you are including each time? >>> >>> Followup question: >>> >>> Is a single file a compilation unit or is it a package? >>> >>> Thanks >>> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/2e237e13-37c9-4741-8ea1-67f813923fafn%40googlegroups.com.
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/856ABBAB-9990-4127-97F8-3318801F2A64%40ix.netcom.com.
