• go | 切片的长度和容量


    其实这也不算什么重难点了,只是想想,也就记录下来吧。对了,有一段时间没在这上面更了然后那个排名就有点在掉,感觉这个机制不太好,更过于频繁很可能只是写流水账,内容质量会大打折扣

    好的,我们步入正题,
    go 的中切片的长度表示切片实际元素个数。容量表示该切片当前最大能装在元素个数。如果一次要append超过这个容量的数量会,go 的切片机制会在内存找一块连续内存,充当新的切片,其中新的切片容量是元素的两倍(大概,具体机制,还有细研究)
    然后会把之前的旧切片的数据copy到新的切片地址,然后把切片指向这个新的切片

    go 切片长度与容量

    package main
    
    import (
        "flag"
        "fmt"
    )
    
    
    func main(){
        var arr32 []int32
        var arr64 []int64
    
        var num = flag.Int("num", 0, "append element num")
    
        flag.Parse()
    
        for i := 0; i < *num; i++{
    
            arr32 = append(arr32, int32(i))
        }
    
        fmt.Println("the arr32 len is ", len(arr32), "the arr32 cap is ", cap(arr32))
    
        for i := 0; i < *num; i++{
            arr64 = append(arr64, int64(i))
    
        }
    
        fmt.Println("the arr64 len is ", len(arr64), "the arr64 cap is ", cap(arr64))
    
        fmt.Println("the main test end...")
    
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    # 运行结果
    go run  test_19_flagslice_capacity.go  --num=100
    the arr32 len is  100 the arr32 cap is  128
    the arr64 len is  100 the arr64 cap is  128
    
    • 1
    • 2
    • 3
    • 4

    经过实验测试,貌似容量与长度的关系并不是所谓的两倍关系。

    go 容量 && c++ 的容器

    • 共同点:都可以动态扩容。容量增长倍数通常是2倍。两者都会自动管理底层内存.
    • 不同点:Go 有垃圾回收功能,自动处理内存回收。而c++众所周知需要手动管理。在Go中切片属于基础数据结构,可疑直接通过make([]type, length, capacity)直接使用,而在c++中需要使用std::vector 通过类实例化。内存管理,由于Go 有垃圾管理机制所以会带来一定的性能开销。Go的切片机制本身不支持并发操作,而是需要同步机制来确保线程安全,而c++容器中有一些是支持并发操作的。

    参考

    参考01

  • 相关阅读:
    如何写好一篇学术论文
    C的魅力在于指针
    2024年java面试--mysql(3)
    msm8953 LCD移植详解
    【原创】xenomai UDD介绍与UDD用户态驱动示例
    分布式一致性算法:Raft
    Xcode隐私协议适配
    C /C++ 中的堆栈使用
    Docker远程API漏洞
    【Hadoop生态圈】10.使用Sqoop迁移MySQL数据到HDFS中
  • 原文地址:https://blog.csdn.net/ttxiaoxiaobai/article/details/138081465