Microsoft visual c runtime library 7.1 code#

> is turing complete in itself you get genric type > that given a better type system (the haskell type system I said ‘generics solve problems introduced You need to do lots of boxing/unboxing, when downcasting, in languages like c++, or always, in dynamically typed languages (leaving optimizations aside). What part of “be it implicit or explicit” don’t you understand? Casts are ALWAYS there, even if in dynamically typed languages are implicit. > really? can you point me to casts in some > there, because they’re the only way to do transform one > casts, in dymically typed languageswill always be How so? You yourself mentioned Haskell: types are inferred, no “more code” to write.

No one said you will catch more errors, what’s been said is that you will catch more errors at compile time, rather than run time, which is an enormous benefit. Simply because you don’t need to do runtime checking on types. > Tell us which, I don’t see them, given that: And obviously once you have tests you don’t need to assert the correctness of the typing.ĪDA has the strongest compile time checks that I can think of, yet an Ariane went BOOM cause they did a floating point casting error. Cause if you have int fun(int,int) you still can’t assert the correctness of the functions without tests. And I showed you that given a better type system (the haskell type system is turing complete in itself you get genric type safety for free. I said ‘generics solve problems introduced from strong static manifest typing’. Really? can you point me to casts in some (python|lisp|ruby|smalltalk) code? Tell us which, I don’t see them, given that:Ĭasts, in dymically typed languageswill always be there, because they’re the only way to do transform one type into another, at runtime. You are contraddicting yourself now: first you said that generics are there just to avoid casting, a problem, you said, of languages with manifest typing, now you say that generics are also used in languages without manifest typing, basically disproving your point and proving my point that generics have more to do with the general advantage of static typing over dynamic typing than with casts. > functors for years, that are tightly integrated with the > people from OCaml, haskell and so on had generic > More, did you noticed I said: ‘strong static manifest’ ? > So generics in C# solve problems generated from C#’s In any case, be them explicit or implicit, casts, in dymically typed languages, or in the statically typed languages when there’s no way to apply static typing, will always be there, because they’re the only way to do transform one type into another, at runtime. But, in essence, nothing stops you from implemening implicit downcasting either. In fact, c++ doesn’t require explicit casts when upcasting, however it needs them when downcasting, for an obvious reason: downcasting is dangerous, and thus the compiler wants you to be sure of what you’re doing. Why so, nothing forbids you to design a language which manifest typing that doesn’t need explicit casts.

> Casts are a problem implicit with strong static manifest > typing. Static typing has many advantages over dynamic typing, some of which are illustrated in the article we’re talking about. Bugs that a static type checker would have found, have to be found through testing instead. This way it gains in convenience and turn-around times, but loses in performance and robustness. Python has typechecking too, only it does it at run-time rather than compile-time.

> In general, all those type-checking gimmicks are evil. Generic classes, on the other hand, are fully type-checked as soon as the compiler encounters them, and the so-called “derivation constraints” allow generic class writers to express constraints on generic parameters.Īs a consequence, users of generic classes don’t need to worry about type errors within the generic class, and if the generic arguments they provide don’t fit the constraints, they get a clear error message. Someone instantiating the template with the wrong arguments will get rather unhelpful type error messages possibly deep inside the template code. Only then will any errors in the template show up.Īlso, the template writer might expect certain operations to be defined on the template arguments, but there’s no way for him to express that explicitly. It can’t typecheck it, it can’t produce any code, it can’t even check that the functions you use do actually exist.Īll that has to be done (over and over again) when What does that mean? When a C++ compiler encounters a template all it can do is check its syntax. There’s a much more important difference between them: templates are glorified macros, whereas generic classes are in fact just classes with parameters.

Microsoft visual c runtime library 7.1 code#

> fact that C# generics are instantiated runtime, reducing > code bloat, doesn’t comfort me at all.