Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you the library source files on how to analyze the Go language. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

What is go suitable for?

Go is the abbreviation of golang, while golang can do server-side development, and golang is very suitable for log processing, data packaging, virtual machine processing, database agent and so on. In the aspect of network programming, it is also widely used in web applications, API applications and other fields.

Have you ever written small commands (or microprograms) in Go? When you are writing "Hello, world", a source file is enough, but this kind of gadget is useless and can give you a little sense of achievement at most.

As I mentioned before, in addition to command source files, you can also write library source files in Go. The library source file cannot be run directly, it is only used to store program entities. As long as they follow the Go language specification, these program entities can be used by other code. These "other codes" can be in the same source file as the program entity being used, in other source files, or even in other code packages.

What is the program entity? In Go, it is a general term for variables, constants, functions, structures, and interfaces. We always declare (or define) program entities before using them.

To say a little more, the names of program entities are collectively referred to as identifiers. Identifiers can be alphabetic characters, numbers, and underscores "_" that can be represented by any Unicode code, but the first character cannot be a number. As a rule, we can use Chinese as the name of the variable. However, I think this kind of naming is very bad, and I will explicitly prohibit it in the development team. As a qualified programmer, we should be infinitely close to writing programs of international standard.

Let's get back to business.

Question: how to split the code in the command source file into other source files?

To be more specific, if there is a command source file demo4.go in a directory, it is as follows:

Package mainimport ("flag") var name stringfunc init () {flag.StringVar (& name, "name", "everyone", "The greeting object.")} func main () {flag.Parse () hello (name)}

The code should look familiar to you. I posted a very similar code when I was talking about the command source file, which is called demo2.go. The difference between the two files is that demo2.go prints the greeting directly by calling the fmt.Printf function, while the current demo4.go calls a function called hello in the same place.

The function hello is declared in another source file, which I named demo4_lib.go and placed in the same directory as demo4.go. As follows:

/ / you need to add code here. [1] import "fmt" func hello (name string) {fmt.Printf ("Hello,% s!\ n", name)}

So the question is: what code should be filled in note 1?

Typical answer

The answer is simple: fill in the package declaration statement package main. Why? As I said before, source files in the same directory need to be declared to belong to the same code package. If there is a command source file in this directory, other source files should also be declared to belong to the main package in order for all files in the same directory to be compiled.

That way, we can run them. For example, we can run the following command in the same directory as these files and get the corresponding results.

$go run demo4.go demo4_lib.go Hello, everyone!

Or, build the current code package before running it, as shown below.

$go build puzzlers/article3/q1 $. / Q1 Hello, everyone!

Here, I put both demo4.go and demo4_lib.go in a directory with a relative path of puzzlers/article3/q1. By default, the import path of the corresponding code package is the same. We can refer to the program entity declared in it through the import path of the code package. However, the situation here is different.

Note that both demo4.go and demo4_lib.go declare that they belong to the main package. I mentioned this usage earlier when I talked about the organization of the Go language source code, that is, the package names declared by the source files can be different from the names of the directories in which they are located, as long as the package names declared by these files are the same.

By the way, I created a project called "Golang_Puzzlers" for this column. All the code and related files we covered will be stored in the src subdirectory of the project. In other words, the correct use is that you need to download the package file of the project to any local directory, then unzip it and add the "Golang_Puzzlers" directory to the environment variable GOPATH. Do you remember? This makes the "Golang_Puzzlers" directory one of the workspaces.

Problem analysis

This question examines the basic rules of code package declaration. Let's sum it up again.

The first rule should be consistent with the code package declaration statement of the source file in the directory. That is, they belong to the same code package. This applies to all source files. If there are command source files in the directory, other kinds of source files should also be declared to belong to the main package. This is also a prerequisite for us to build and run them successfully.

The second rule is that the name of the code package declared by the source file can be different from the name of the directory in which it is located. When building against a code package, the main name of the resulting file matches the name of its parent directory. For command source files, the main name of the executable generated by the build will be the same as the name of its parent directory, as I verified in my previous answer.

Well, after I have repeatedly stressed, I believe you have memorized these rules. The following will also be relevant to them.

When writing a real program, it is not enough to split the code into a few source files. We tend to use modular programming to put the code into different code packages according to its function and purpose. However, this involves some of the code organization rules of the Go language. Let's look at it together.

How does knowledge extension 1 split the code in the command source file into other code packages?

Let's not focus on the technique of splitting the code for a while. I still follow the previous split method here. I saved demo4.go as demo5.go and put it in a directory with a relative path of puzzlers/article3/q2.

Then I create a directory with a relative path of puzzlers/article3/q2/lib, and then make a copy of demo4_lib.go and rename it demo5_lib.go into that directory.

Now, how should we modify the code in order for them to be compiled? You can think about it first. I'll give you some of the answers here. Let's take a look at the modified demo5_lib.go file.

Package lib5import "fmt" func Hello (name string) {fmt.Printf ("Hello,% s!\ n", name)}

As you can see, I have changed two places here. The first change is that I changed the package declaration statement from package main to package lib5. Note that I deliberately made the declared package name different from the name of the directory in which it is located. The second change is that I changed the all-lowercase function name hello to uppercase Hello.

Based on the above changes, let's look at the following questions.

2, is the import path of the code package always the same as the relative path of the directory where it is located?

The relative path to the directory where the library source file demo5_lib.go is located is puzzlers/article3/q2/lib, but it claims to belong to the lib5 package. In this case, is the import path of the package puzzlers/article3/q2/lib or puzzlers/article3/q2/lib5?

This question often puzzles beginners of the Go language, even those who have developed programs in Go. Let's take a look.

First, when we build or install this code package, the path provided to the go command should be the relative path to the directory, like this:

Go install puzzlers/article3/q2/lib

The command completes successfully. After that, the corresponding archive file is generated under the pkg subdirectory of the current workspace, and the specific relative path is pkg/darwin_amd64/puzzlers/article3/q2/lib.a. Darwin_amd64 is the platform-related directory I mentioned when I talked about the workspace. As you can see, here corresponds to the relative path of the directory where the source file is located.

To further illustrate, I need to make two changes to demo5.go first. The first change is to add puzzlers/article3/q2/lib to the code package import statement preceded by import, that is, an attempt to import the code package. The second change is to change the call to the hello function to the call to the lib.Hello function. Among them, lib. It is called a qualifier and is designed to indicate the code package in which the program entity on the right is located. However, this is different from the complete writing of the package import path, which only contains the last level of lib in the path, which is consistent with the rules in the code package declaration statement.

Now, we can try it by running the go run demo5.go command. The error message will be similar to the following.

. / demo5.go:5:2: imported and not used: "puzzlers/article3/q2/lib" as lib5./demo5.go:16:2: undefined: lib

The first error message means that we imported the puzzlers/article3/q2/lib package but didn't actually use any of the program entities. This is not allowed in the Go language and will result in failure at compile time.

Note that there is another clue here, and that is "as lib5". This shows that although the code package puzzlers/article3/q2/lib is imported, the program entities in it should be used with lib5. Is a qualifier. This is the reason for the second error prompt. The Go command could not find lib. The code package corresponding to this qualifier.

Why is that? The root cause is that we declare in the source file that the code package we belong to is different from the name of the directory in which it belongs. Keep in mind that the relative path of the directory where the source file resides relative to the src directory is its package import path, and the qualifier given when actually using its program entity corresponds to the name of the package to which it claims to belong.

There are two ways to make the above build complete successfully. Here I choose to change the package declaration statement in the demo5_lib.go file to package lib. The reason is that in order not to confuse the users of the package, we should always make the declared package name the same as the name of its parent directory.

3, what kind of program entity can be referenced by code outside the current package?

You may wonder why I capitalized the first letter of the function name hello in the demo5_lib.go file. In fact, this involves the Go language rules for access to program entities.

Super simple, only a program entity with an uppercase name can be referenced by code outside the current package, otherwise it can only be referenced by other code in the current package. By name, the Go language naturally divides the access rights of program entities into package-level private and public. For a package-level private program entity, it cannot be referenced even if you import the code package in which it is located.

4. Are there any other access rules for program entities?

The answer is yes. In Go 1.5 and later, we can create internal code packages so that some program entities can only be referenced by other code in the current module. This is called the third type of access for Go program entities: module-level private.

The specific rule is that the public program entity declared in the internal code package can only be referenced by the code in the immediate parent package and its child package of the code package. Of course, you need to import the internal package before referencing it. For other code packages, importing the internal package is illegal and cannot be compiled.

There is a simple example in the puzzlers/article3/q4 package of the "Golang_Puzzlers" project for you to view. You can change the code and understand the role of the internal package.

The above is the editor for you to share how to analyze the Go language library source files, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.