首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    类型声明与空安全(Void Safety)

    在 Kotlin 中,不可能为空的变量和可能为空的变量被强行分开了(Java 有 @Nullable 和 @NonNull 注释,但只会提供警告)。那 Kotlin 为什么要这样设计呢?...Kotlin 非空类型/可空类型(NonNull/Nullable)声明 最开始时我们提到:在 Kotlin 中,不可能为空的变量和可能为空的变量被强行分开了。具体是怎么分开的呢?...很简单,默认的类型声明不能为空,类型后面跟问号”?”则可以为空。...Kotlin 可空(Nullable)类型的调用 声明一个非空变量,意味着你可以随意的调用他的方法而不用担心空指针错误,相对应的,可空变量则无法保证了。...Kotlin 通过不允许可空变量直接调用方法来保证不会出现空指针错误。那么可空变量应该怎么调用呢? Kotlin 可空变量的调用方法是:调用的”.”号前加”?”或”!!”。

    1K50

    【Kotlin】空安全 ① ( Kotlin 的空安全机制 | 变量可空性 | 默认变量不可赋空值 | 声明可空类型变量 )

    文章目录 一、Kotlin 的空安全机制 二、变量可空性 1、默认变量不可赋空值 2、声明可空类型变量 一、Kotlin 的空安全机制 ---- Java 中的空指针问题 : 在 Java 语言...: Null can not be a value of a non-null type String 这是因为 var name 变量 默认为非空的 , 在 Kotlin 中 不允许将 默认变量...赋值一个空值 , 除非 将该变量声明为 可空类型 ; 2、声明可空类型变量 声明可空类型变量 : 如果要声明一个 可空类型的变量 , 必须 声明该变量的具体的类型 , 并在该类型后添加 ?...代码示例 : 在下面的代码张红 , 将 var name 变量声明为了 String?...可空类型声明后 , 在 IntelliJ IDEA 中 , 就不再进行报错了 ;

    1.9K20

    不能定义声明dllimport_不允许 dllimport 静态数据成员

    “CTest::~CTest” : 不允许 dllimport 函数 的定义 “CTest::CTest” : 不允许 dllimport 函数 的定义 //代码如下 template class __...在.cpp中变态地调用自己声明的模板。 明白这个道理之后也就不难理解为什么有的时候可以编译通过链接的时候却报错了,链接器找不到另一个.obj的相应地址当然报错。...现在来分析一下上面的模板代码为什么会出错,很简单: 既然使用了__declspec(dllimport)声明,却又对CTest()及~CTest()进行定义,违反VC规则“数据、静态数据成员和函数可以声明...为什么不能将这2个函数的定义放在.cpp文件中上面已经有解释了。 上面说的不太完美:添加以下说明: __declspec(dllexport) 声明一个导出函数,是说这个函数要从本DLL导出。...明明已经定义了,为什么又没有了?? 肯定是因为我把m_nValue定义为static的原因。

    2K20

    空芯光纤,为什么这么火?

    传统纤芯 空芯光纤,顾名思义,就是光纤里面不再有实体纤芯,而是“空”的——只有空气、惰性气体或真空。 那么,空芯光纤,相比于传统玻芯光纤,到底有什么优势呢?...为什么现在光通信行业,都非常关注和重视空芯光纤呢? 研究空芯光纤,并不是因为减少了里面的纤芯能够降低成本,而是因为光信号在空气中传播,比在玻璃纤维中传播更有优势。...空芯光纤还有很多的优点,小枣君待会再做介绍。 █ 空芯光纤的发展演进 接下来,我们还是先看看空芯光纤的技术实现。 光纤的原理,说白了,就是把光“困”在有线线缆里。...于是,科学家们继续探索,想要找到新的空芯光纤结构。 研究人员提出了Kagome型空芯光纤。后来,基于对Kagome型空芯光纤的研究,又提出了反谐振空芯光纤,成为业界主流研究方向。...三大运营商更不用说了,死死盯着空芯光纤技术的相关进展。 相信接下来的这几年,空芯光纤的研究和落地将会进一步提速。 █ 空芯光纤的优点 我们再来说说空芯光纤的优点。

    69810

    为什么ConcurrentHashMap不允许插入null值?

    插入 null 值,这到底是为什么呢?...实现代码如下: 编译阶段没有报错,执行以上程序,得到的结果如下: 从上述报错信息可以看出,使用 ConcurrentHashMap 是不能插入 null 值的,否者程序在运行期间就会报空指针异常...实现源码如下: 从上述源码可以看出,在添加方法的第一句就加了判断:如果 key 值为 null 或者是 value 值为 null,就直接抛出异常 NullPointerException 空指针异常...然而,这个原因是不能说服面试官的,虽然源码是这样设计的,但我们要思考的是,这样设计背后更深层次的原因,为什么 ConcurrentHashMap 不允许插入 null?...可以看出这就是 ConcurrentHashMap 的二义性问题,那为什么 HashMap 就不怕二义性问题呢? 可证伪的 HashMap 上面说到 HashMap 是不怕二义性问题的,为什么呢?

    1.9K30

    为什么空状态设计理应花费更多时间

    toc 旧事重提,之前就译过一篇,空状态的设计,一年半之后发现对这方面还是欠缺,故有此篇^_^ 原文:WHY EMPTY STATES DESERVE MORE DESIGN TIME 在很多设计中,空状态...不要被空状态这个名字愚弄。空状态有着驱动用户参与,取悦用户,并且在一些危险情况譬如用户下载App清空了内容,或者运行到错误状况时挽救用户的极大潜能。 这些空状态一般被称为,初次使用,用户清除和错误。...因此问题就在这里: 如果你知道你的用户会在第一周找个理由离开,你还会任由空状态影响留存率吗? 这边文章专注在怎样才能利用最关键的空屏幕,也就是初次使用时的空状态。...如何填充空状态 将“初次使用”的空状态单独考虑,或者最好将它当作整体体验的一部分。一个成功的界面可以达到下面的目的。...似乎看起来不多,但是如果你产品的首个空状态有别于其他类似产品,那么你也就告诉用户你的产品的整个体验都是和其他产品不同的。 仔细的体验每个类似产品的landing页以及空状态的体验。

    48410

    为什么不建议你用去 “! = null” 做判空?

    最终,项目中会存在大量判空代码,多么丑陋繁冗!如何避免这种情况?我们是否滥用了判空呢? 「精华回答:」 这是初、中级程序猿经常会遇到的问题。...他们总喜欢在方法中返回null,因此,在调用这些方法时,也不得不去判空。另外,也许受此习惯影响,他们总潜意识地认为,所有的返回都是不可信任的,为了保护自己程序,就加了大量的判空。...这里给一些实践建议: 「1、假如方法的返回类型是 collections,当返回结果是空时,你可以返回一个空的 collections」 (empty list),而不要返回 null,这样调用侧就能大胆地处理这个返回...,例如调用侧拿到返回后,可以直接 print list.size(),又无需担心空指针问题。...「其他回答精选:」 1、如果要用 equal 方法,请用 object空>.equal(object空>)) 例如: 使用 "bar".equals(foo)  而不是。

    57820

    为什么不建议你用去 “! = null” 做判空?

    最终,项目中会存在大量判空代码,丑陋繁杂。。。如何避免这种情况?是否滥用了判空? 精华回答 这是初、中级程序猿经常会遇到的问题。他们总喜欢在方法中返回null,因此,在调用这些方法时,也不得不去判空。...另外,也许受此习惯影响,他们总潜意识地认为,所有的返回都是不可信任的,为了保护自己程序,就加了大量的判空。...这里给一些实践建议: 1、假如方法的返回类型是collections,当返回结果是空时,你可以返回一个空的collections(empty list),而不要返回null,这样调用侧就能大胆地处理这个返回...,例如调用侧拿到返回后,可以直接print list.size(),又无需担心空指针问题。...其他回答精选: 1、如果要用equal方法,请用object空>.equal(object空>)) 例如使用: "bar".equals(foo) 而不是 foo.equals(

    72610

    为什么foreach中不允许对元素进行add和remove

    阿粉的读者遇到了一个比较经典的面试题,也就是标题上说的,为什么 foreach 中不允许对元素进行 add 和 remove。...阿粉就这个问题深入分析一下为什么不让使用 add 和 remove,并且实际运行一下,我们来看一下。...其实说这话的,一般都是没去看过源码的,为什么这么说,如果你要是反编译出来 foreach 这一段代码,那么你肯定发现内部是使用迭代器实现的,既然这样,那好,我们再用迭代器遍历一下试试。...为什么不相等的时候,就会出现异常呢?...1, 2, 3, 4, 6, 7, 8, 9] 他实现了对这个元素中间进行移除的操作,那么他的内部源码是怎么实现的,实际上很简单,复制 也就是他创建一个新的数组,再将旧的数组复制到新的数组上,但是为什么很少有人推荐这种做法

    46810

    为什么我不建议你用去 “ ! = null 做判空?

    最终,项目中会存在大量判空代码,多么丑陋繁冗!如何避免这种情况?我们是否滥用了判空呢? ---- 精华回答: 这是初、中级程序猿经常会遇到的问题。...他们总喜欢在方法中返回null,因此,在调用这些方法时,也不得不去判空。另外,也许受此习惯影响,他们总潜意识地认为,所有的返回都是不可信任的,为了保护自己程序,就加了大量的判空。...这里给一些实践建议: 1、假如方法的返回类型是collections,当返回结果是空时,你可以返回一个空的collections(empty list),而不要返回null,这样调用侧就能大胆地处理这个返回...,例如调用侧拿到返回后,可以直接print list.size(),又无需担心空指针问题。...其他回答精选: 1、如果要用equal方法,请用object空>.equal(object空>)) 例如: 使用 "bar".equals(foo) 而不是 foo.equals("

    1K10
    领券