问题标签 [type-safety]

假设我们有以下类型：

现在，您如何构造一个集合，T使每个子至少有一个T出现在集合中，这个约束在编译时强制执行？与此相反的集合：

编译，这个：

才不是。我在上面使用过 Scala，但我也很乐意看到其他语言的解决方案。

（如果我的话有点不对劲，请原谅我；我感冒了，今天用谜题自娱自乐。）

我正在积极开发桌面应用程序、本地和网络服务、一些经典的ASP.NET等，所以我习惯于静态编译和静态代码分析。现在我（终于）学习了ASP.NET MVC 3.0，我看到许多 ASP.NET MVC 专家和经验丰富的开发人员都建议在 ASP.NET MVC 3.0（如果适用）中使用强类型视图。

我猜“强类型”意味着@model=...在视图代码的顶部编写。但在这样做时，我只让IntelliSense工作，没有进行静态代码检查。我可以在cshtml@model的语句中写任何我想要的东西，它会编译和运行。因此，也可以编译。事实上，如果我不输入@model，我可以动态地使用任何我想要的具有“兼容”属性和方法的模型。Model.Anything

我习惯于“强类型”，意思是“不会编译”，就像 LINQ 一样，如果你没有得到正确的属性，任何东西都不会编译。@model除了 IntelliSense 和运行时错误之外，还有其他用途吗？如果实际上不是，为什么将其称为强类型？

强类型化，计算机文学中的意义

我想问一下 Clojure 上有哪些类型的安全语言结构？

我已经多次阅读 Luke VanderHart 和 Stuart Sierra 的“实用 Clojure”，但我仍然有明显的印象，即 Clojure（像其他 lisps 一样）并没有非常重视编译时验证检查。类型安全只是对正确语义进行编译时检查的一种（非常流行的）策略

我问这个问题是因为我渴望被证明是错误的；clojure 上有哪些设计模式可用于验证（在编译时，而不是在运行时）期望字符串的函数不会被调用，例如整数列表？

另外，我读过像 Paul Graham 这样非常聪明的人公开提倡 lisp 允许在其之上实现来自低级语言的所有内容（大多数人会说该语言本身正在其之上重新实现），所以如果那个断言会是真的，那么像类型检查这样的琐碎事情应该是小菜一碟。那么你是否觉得在 clojure 或其他 lisps 中存在类型系统（或实现此类类型系统的能力），这使程序员能够将验证检查从运行时偏移到编译时，甚至更好的设计-时间？

假设，我向一个actor发送一个请求并同步接收它的响应：

现在我必须沮丧resp才能MyResponse访问data

如何摆脱强制转换并以类型安全的方式编写代码？（我想我可以改用模式匹配，但我更喜欢另一种解决方案）。

假设我有两个元素容器：

foo我在这两个容器上运行的许多类bar之间传递了不合理的信息。但是，我发现我必须非常小心，不要混淆哪些缺陷与哪个容器相关联，有时会在此失败，然后很难找到导致的逻辑错误。

所以，假设我有两个不雅点：

是否有一种简单的设计模式可以帮助防止我尝试bar[id_foo]通过“绑定”id_foo到foo.

基本上，我试图找出消除foo和之间歧义的最简单方法bar。我可以为每个类创建单独的类，然后将迭代器定义到这些类中。但是我想避免为每个我想要这种“安全性”foo的容器创建一个单独的类。bar

问题是要求诸如“索引安全”之类的东西（类似于类型安全）。我目前实现这一点的方式是通过命名我的不雅点来指示它们与哪个容器相关联。

I am trying to determine whether an object pointed by a T* pointer is truly a T object, or some other, unrelated type. I tried dynamic_cast, however it is less than useless, it returns the pointer itself instead of null even when it is obvious it does not point to a valid T object:

Is there any workaround for this, or some other solution? I've tried casting to void* and char* before the dynamic_cast to no avail, typeid is not enough either since I want to accept subclasses as well.

Some context: I'm writing a custom Array class implementing shallow conversion between different kinds of Arrays, like Array<Object*> and Array<String*>, and I would like to guarantee a minimal type safety by doing a dynamic type check at every element access, for example:

Casting to Object*, then doing the type check on the Object* works in a lot of cases, but it fails in the case of Array<Object*>, though I am not sure whether it is possible to insert something non-Object into an Array<Object*> without the use of reinterpret_cast.

使用以下 C++ 定义：

以下代码将无法编译，这才有意义：

但以下代码确实编译：

虽然它没有任何意义 - 比较不同的枚举并且这样的代码可能是错误的。

为什么这些看似相同的情况在 C++ 中的处理方式不同？

您可以使用例如 JUnit 来测试您的库的功能，但是您如何测试它在泛型和通配符方面的类型安全性呢？

只有针对可编译的代码进行测试才是“快乐路径”测试；您是否还应该针对非类型安全使用测试您的 API 并确认这些代码无法编译？

那么你如何验证你的泛化 API 在编译时引发了正确的错误呢？您是否只是构建一个非编译代码套​​件来测试您的库，并将编译错误视为测试成功，反之亦然？（当然，您必须确认错误与泛型有关）。

是否有促进此类测试的框架？

我有两个连接的简单查询：

此查询必须转换为类型安全查询，我尝试的是：

我的问题是，我想将 Uebersetzung_.textLang 字段作为选择。但是当我尝试向查询添加选择时，例如：

我收到一条错误消息：

我需要这个字段，因为我想从 jsp 页面访问它。有没有其他方法可以在选择中获取此字段？

我有以下查询：

但我在建立条件方面遇到了问题。这是我的代码：

这会产生以下内容：

并且 ufcorse 不起作用。我应该使用哪种方法进行日期比较（或如何删除'模式部分中的外部字符）？