十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
GOPATH是你的工作目录,对于项目文件而言,项目的结构和你的工作目录的结构有很大关系。
让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名注册、虚拟主机、营销软件、网站建设、鼓楼网站维护、网站推广。
GOPATH路径下默认是有以下三个目录的,
1.src 存放源代码(比如:.go .c .h .s等)
2.pkg 编译后生成的文件(比如:.a)
3.bin 编译后生成的可执行文件(为了方便,可以把此目录加入到 $PATH 变量中,如果有多个gopath,那么使用${GOPATH//://bin:}/bin添加所有的bin目录)
作为C语言家族的一员,go和c一样也支持结构体。可以类比于java的一个POJO。
在学习定义结构体之前,先学习下定义一个新类型。
新类型 T1 是基于 Go 原生类型 int 定义的新自定义类型,而新类型 T2 则是 基于刚刚定义的类型 T1,定义的新类型。
这里要引入一个底层类型的概念。
如果一个新类型是基于某个 Go 原生类型定义的, 那么我们就叫 Go 原生类型为新类型的底层类型
在上面的例子中,int就是T1的底层类型。
但是T1不是T2的底层类型,只有原生类型才可以作为底层类型,所以T2的底层类型还是int
底层类型是很重要的,因为对两个变量进行显式的类型转换,只有底层类型相同的变量间才能相互转换。底层类型是判断两个类型本质上是否相同的根本。
这种类型定义方式通常用在 项目的渐进式重构,还有对已有包的二次封装方面
类型别名表示新类型和原类型完全等价,实际上就是同一种类型。只不过名字不同而已。
一般我们都是定义一个有名的结构体。
字段名的大小写决定了字段是否包外可用。只有大写的字段可以被包外引用。
还有一个点提一下
如果换行来写
Age: 66,后面这个都好不能省略
还有一个点,观察e3的赋值
new返回的是一个指针。然后指针可以直接点号赋值。这说明go默认进行了取值操作
e3.Age 等价于 (*e3).Age
如上定义了一个空的结构体Empty。打印了元素e的内存大小是0。
有什么用呢?
基于空结构体类型内存零开销这样的特性,我们在日常 Go 开发中会经常使用空 结构体类型元素,作为一种“事件”信息进行 Goroutine 之间的通信
这种以空结构体为元素类建立的 channel,是目前能实现的、内存占用最小的 Goroutine 间通信方式。
这种形式需要说的是几个语法糖。
语法糖1:
对于结构体字段,可以省略字段名,只写结构体名。默认字段名就是结构体名
这种方式称为 嵌入字段
语法糖2:
如果是以嵌入字段形式写的结构体
可以省略嵌入的Reader字段,而直接访问ReaderName
此时book是一个各个属性全是对应类型零值的一个实例。不是nil。这种情况在Go中称为零值可用。不像java会导致npe
结构体定义时可以在字段后面追加标签说明。
tag的格式为反单引号
tag的作用是可以使用[反射]来检视字段的标签信息。
具体的作用还要看使用的场景。
比如这里的tag是为了帮助 encoding/json 标准包在解析对象时可以利用的规则。比如omitempty表示该字段没有值就不打印出来。
1、解压压缩包到go工作目录,如解压到E:\opensource\go\go,解压后的目录结构如下:
E:\opensource\go\go
├─api
├─bin
│ ├─go.exe
│ ├─godoc.exe
│ └─gofmt.exe
├─doc
├─include
├─lib
├─misc
├─pkg
├─src
└─test
2、增加环境变量GOROOT,取值为上面的go工作目录
3、Path环境变量中添加";%GOROOT%\bin",以便能够直接调用go命令来编译go代码,至此go编译环境就配置好了
注:如果不想手动设置系统环境变量,也可下载go启动环境批处理附件,
修改goenv.bat文件中的GOROOT值为上面的go工作目录后直接双击该bat文件,go编译环境变量即设置完成。
4、测试go编译环境,启动一个cmd窗口,直接输入go,看到下面的提示就是搭建成功了
E:\opensource\go\gogo
Go is a tool for managing Go source code.
Usage:
go command [arguments]
The commands are:
build compile packages and dependencies
clean remove object files
doc run godoc on package sources
env print Go environment information
fix run go tool fix on packages
fmt run gofmt on package sources
get download and install packages and dependencies
install compile and install packages and dependencies
list list packages
run compile and run Go program
test test packages
tool run specified go tool
version print Go version
vet run go tool vet on packages
Use "go help [command]" for more information about a command.
Additional help topics:
gopath GOPATH environment variable
packages description of package lists
remote remote import path syntax
testflag description of testing flags
testfunc description of testing functions
Use "go help [topic]" for more information about that topic.
5、编译helloworld测试程序,go语言包中test目录带有helloworld.go测试程序,源码见"附一 helloworld.go",
直接调用"go build helloworld.go"就生成了"helloworld.exe"可执行程序,运行一下这个程序看到了我们期望的hello,wolrd。
E:\opensource\go\go\testgo build helloworld.go
E:\opensource\go\go\testhelloworld.exe
hello, world
E:\opensource\go\go\test
附一 helloworld.go
// cmpout
// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Test that we can do page 1 of the C book.
package main
func main() {
print("hello, world\n")
}
我喜欢jetbrains系列的IDE+go插件。不过我要说的是这个问题主要看你的观点如何。
说eclipse:
构建方式是使用go
install
命令,每一次编译运行都是go
install。这样的好处就是如果你有很多的包,下载下来并没有编译,这样每次编译速度是很快的。而且(!)go
install
符合go官方的项目结构,官方说过了,一个go的项目应该是以个gopath,包含src,pkg,bin三个主要目录。所以说go
install个人认为才是主要的go编译方式。
说eclipse的缺点:
其实eclipse插件的go编译方式,还有目录结构,项目结构,都是非常完美的!!!!真的很完美!可是,他的代码提示,太差件!大括号都不能自动补全,gdb
32bit
64bit兼容问题,eclipseC++
没有html
js插件,需要手动安装,几乎不能开箱即用。不过如果你是开发算法,数据处理,还是推荐eclipse的,毕竟其他都无关紧要。
说jetbrains:
说先说clione肯定不适合,新建项目没有向导,导致改成go项目各种不开心,比如图标对于我来说就无法接受go
lib
不是小耗子~这是次要的,重要的是各个文件都是灰色的(没有在cmake中包含的结果),然后说剩下的,phpstorm这个不说了,估计很少有人插件按在这里,webstorm,体验也不是很好,idea?体验很好,可是毕竟比较重,尤其是现在加入了自家的K啥玩意(无意冒犯,没记住单词)~可是话说回来,go跟C系列IDE配合才是最佳,跟java系列一点不搭关系,用idea似乎有点格格不入,但是!idea支持新建项目向导,lib的图标也很清晰,最后还是选择idea吧,期待clion的强大起来!
再说jetbrains系列缺点:
插件的构建方式是go
buiild
这个让人很不爽,我们几乎不确定会构建到什么地方去,还要每次设置一下run配置。这个可能无关紧要,毕竟不是什么大的毛病,可是go
build不能缓存.a文件,直接构建的结果就是很多第三方包的情况下很慢!所以建议安装包的时候手动install
一下解决这个问题。自带代码格式化,这个格式化跟go
格格不入,总的来说就是蛋疼,心碎,菊花痒。
最后说liteIDE:
轻量级IDE,我可以说是国人GO伟大作品典范,然而默认构建也是go
build,项目管理方式不符合go官方标准。代码提示不能自动导入(eclipse也不能),不过如果你的项目是以包为单位的,那么另当别论。一定很不错,毕竟是轻量级专门针对GO的IDE!
说这些,其实还有很大一部分取决于你的项目是用vendor机制管理,还是godeps机制管理依赖关系。go不像java拥有强大的几乎天下一统的maven(无意冒犯,暂不评价其他构建套件)。
go没有官方包仓库。
go没有官方包管理工具。
go没有官方自动化构建套件。
上面三个没有是致命要害。导致民间各种百花齐放。
说说我的项目怎么管理
gpm
一个shell工具(windows下你可以用git的bash,或者cygwin~)
我是严格艳照官方推荐方式管理go项目,一个go项目一个gopath。系统的gopath只是为了安装go命令,我没有配置gobin,意义不大。
项目的依赖跟我的代码包都在src下(非vendor)
vendor用来存放包的特殊依赖,发布项目直接把依赖包发布上去(公网管理则只上传依赖关系文件
godeps文件)
资源文件等都放在src目录同级,编译文件放在bin,引用直接../引用。