Comment by chadzawistowski | Hacker News Reader

Comment by chadzawistowski | Hacker News Reader

Parent Full thread

chadzawistowski

One case where C# is far superior to Java is generics.

Generics were a cutting-edge feature in 2005. Microsoft took the opportunity to start from scratch, and released the .Net Framework 2.0 without backwards-compatibility, and with full support for generics. A List<String> is actually a List of String.

When Sun released Java 5, they didn't want to disrupt the established Java ecosystem. Their implementation is called "type erasure". As an example, List<String> is actually just List<Object>, with automatic runtime typecasting to String. https://docs.oracle.com/javase/tutorial/java/generics/erasur...

Java's solution works well enough, but it breaks down in certain scenarios, such as multiple levels of generics. For example, when getting an element from a List<List<String>>, Object is not cast to List<String> (which doesn't really exist), but merely List.

C#'s implementation of generics became even more sophisticated with C#4, which introduced covariance and contravariance. https://msdn.microsoft.com/en-us/library/ee207183.aspx

> Generics were a cutting-edge feature in 2005.

I was already using C++ templates in 1994 with Borland C++ for Windows 3.1!

Ada, CLU and ML go back to the late 70's / early 80's.

Yes, but I guess that code would break in a million ways today in a modern C++ compiler

It certainly worked at the time, for that specific compiler

It was still a language feature even if it wasn't available 100% bug free in all C++ compilers.

C code also used to break left and right long after C90 was approved.

I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.

> I had to use K&R C style code in 1999 because the HP-UX compiler at a customer location didn't knew any better, but that didn't mean other C features weren't available elsewhere.

Curious, what did you need to do specifically? Parameter declarations weren't inlined?

But anyway, C, being smaller, breaks in fewer ways

> Curious, what did you need to do specifically? Parameter declarations weren't inlined?

In those days HP-UX C compiler was still transitioning between K&R and ANSI standards.

We could only properly compile without strange errors while using K&R function declarations.

If memory serves me right, it was the first HP-UX release having support for 64bit file systems.

Templates are not proper generics. Templates can be used to emulate generics, but they are not the same thing at all. Templates are not first-class citizen of the type system (they don't survive to the typechecking phase), while generics are. You cannot write a generic list implementation in C++ and have it typechecked.

I'd like to hear more about that because I'm not sure I understand. Can you give an example for something you cannot do in C++ in a type safe way that you can do in C#, Java or Swift?

I already gave one. You can't write a generic list implementation and make the compiler prove your code is sound (according to the rules of the C++ type system) for any valid type argument value.

You obviously need to learn about template metaprogramming, enable_if, type traits and SFINAE.

C++ templates are Turing complete, you can validate whatever you feel like at compile time.

I'm absolutely aware of enable_if, type traits and SFINAE. But they do not address the concern I raised here. The things you mention come to play on template instantiation, after the concrete (non-generic) types are already known. The problem I mention is that with templates you cannot type check generic code. I can put whatever nonsense enable_ifs on my template declaration and the compiler does not check if they are satisfied by the implementation.

You can write the following C++ code and C++ allows it:

<template typename T> void foo(const T& arg) { arg.bar(); }

This is perfectly fine for a macro system. But this is not how truly generic type system would work. If templates were proper generics, the typechecker would immediately refuse this to compile saying something like: "Error: I can't prove T has the bar() member."

> C++ templates are Turing complete, you can validate whatever you feel like at compile time.

So please write a template metaprogram that validates if a given C++ class (input to the program, given as a template argument) matches a table schema in the database system (the table name and connection string are also given as template arguments). For fetching the schema, you have to connect to the DB, of course at compile time. If the schema does not match, the compilation should fail ;)

Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.

Do you want an example how to write it properly?

With or without the upcoming concepts TS already in GCC 6.0?

Also this example would require T to be an interface with a bar method in C#. Do you also want to the the variant with MI and pure abstract classes in C+?

> Because whoever wrote foo () was too lazy to make use of type traits and validate that T has a method called bar with zero arguments.

In a proper generic type system, the compiler validates it, not the programmer. Even if you constrain the type using type traits, the compiler would not check if the implementation satisfies the constraints. I can put a type trait for existence of bar() and then another programmer may rename bar() to baz() forgetting to update the constraint and the code will still compile fine.

Except that reasoning fails with concepts, already available in GCC 6.0 and as a TS.

So you're saying concepts will reject libraries that compile fine today?

They might, if used properly.

I do admit that I need to update myself with what GCC 6.0 allows vs the letter of the TS.

I don't think concepts are even necessary to do what pkolaczk wants to do, which is (I think) to constrain the argument to a particular interface, say Bar:

  template <typename T> 
  void foo(const T& arg) {
    const Bar* b = arg;
    b->bar();
  }

or

  template <typename T> 
  void foo(const T& arg) {
    static_assert(is_base_of<Bar, T>::value, "T must be a Bar");
    arg.bar();
  }

I can't say I'm a huge fan of either syntax, but the compiler will perform static type checking as if you had written where T : Bar in C#.

The body of the template won't be typechecked until the instantiation of the template. This is different than in C#. If I replaced arg.bar with arg.baz in C#, the generic type definition would not compile, even if I never use it. In C++ I can't write a template and have it typechecked for all possible input types satisfying the type constraints, in C# I can. So C++ type system is weaker than that of C#.

I see what you mean, but uninstantiated also means unused. So we're not talking about anything that could possibly lead to runtime errors. It's not an issue with type safety.

It definitely has a downside for the development process, especially when it comes to writing libraries. But it is also to some degree inevitable if you want structural typing. Maybe there is a better way to do it though.

Now I am curious about an example where generics are able to do what templates, which are Turing complete, aren't.

I think of templates as an automated copy+paste mechanism. C++ templates can bloat the compiled executable pretty significantly... If you define a generic Foo<String> and Foo<Widget>, C++ templates will generate two separate binary implementations. C# will use the same implementation, and perform type checks using reflection at runtime.

Further support for the idea that C++ templates are an automated copy+paste mechanism is that you're allowed to give templates arguments that are not types.

Further reading: https://msdn.microsoft.com/en-us/library/c6cyy67b.aspx

It is not how you think of them, rather what is possible to do with their expressiveness.

C# type checks imply a performance hit and are an implementation detail. Nothing prevents a C# compiler to choose another one. It has nothing to do with generics vs templates.

For example Modula-3 and Ada compilers use the same approach as C++ for code generation of their generics.

So where is that example of something that can only be written with C# generics, but not with C++ templates?

A github gist maybe?

It is not the case of what can only be written, but what can be written and typechecked. C# generics offer much stronger type safety for library writers than C++ templates. C++ templates are not type-checked. C# (and Java, and Scala and Haskell) generics are.

Yes they are type checked.

That is what enable_if, type traits, if constexpr and eventually concepts allow for.

No, they are not. This code compiles fine, despite an obvious non-generic type-error. You may add whatever number of type traits, constexprs, etc there, and it will still compile fine as long as syntax is ok.

  #include <string>

  template <typename T>
  void foo(const T& arg) {
    int x = std::string("int expected");
  }

  $ g++ -c template.cpp
  $ // see, no error

Templates are only syntax-checked. The type checker is not even executed on the non-generic code inside of templates. The type checker will be executed after the template is instantiated (expanded). At that point, generic types do not exist. There exist only concrete types.

They are still type checked when they are instantiated and the code is as generic as always.

Uninstantiated templates are dead code that will be stripped anyway.

Did I write anything different?

Sure, you can type-check them for particular type arguments. But you can't type-check them generally at the generic level and you have absolutely no guarantee that your library code is free of type errors. Not a problem if the goal is to produce the final executable, but a big problem for a library writer, who doesn't control the inputs (in this case: the types provided by the user of the library).

And AFAIK C++17 concepts do not address this problem, really. I can constrain my input types with them, and the calling code will be forced to conform to them (and the compiler will present a nice error message if it doesn't), but there is still no checking on the other side - that is if the template implementation is correct assuming these constraints. I can publicly declare my code requires T.bar(), then shamelessly call T.baz() in the template implementation and the compiler will not catch it.

This is like a Python program. You don't know if it type-checks before you run it, but even if you run it once or twice and it was fine, that doesn't guarantee there are no type errors.

Yes.

The code line int x = std::string("int expected"); has zero relation with any of the template arguments.

So a programmer error that doesn't have anything to do with the types provided for the template.

Sure it will be caught in C#, because its build model assumes the existence of modules and everything is compiled to binary.

In C++ a similar compilation error would occur when compiling the translation unit into a library where the template is instantiated.

Of course, most templates being header only the error will only occur when instating it, but it will still blow on compilation and prevent the final generation of the exe, dll being produced.

Also errors related to semantic type check, independent of template arguments is relatively easy to achieve with unit tests.

I still fail to see how a generic system that doesn't offer partial specialization or meta-programming as being more powerful than templates.

I never said more powerful. I said stronger. In C++ you need unit tests to check something I can have statically proven in C#. And obviously you can't instantiate your template for all possible valid input types, because this number can be infinite.

Monomorphisation is the name of the technique of producing a different version of the code for each set of type parameters that are used in the program. C++ and Rust use monomorphisation instead of doing runtime checks because they're trading off slightly bigger binaries for greater speed.

By not doing runtime checks you get to skip that work at runtime, obviously, but you also get to enable other optimizations like inlining the monomorphised version.

Templates are a macro system. Macro systems are often Turing-complete. But if being Turing-complete was the only important thing in programming, then we'd all code in assembly and never look forward. Most programming languages are Turing-complete, but this doesn't mean they are practically equivalent for every job. You know, Brainfuck is also Turing-complete, but you'd be probably pissed-off if I said heavy-templated C++ code readability is often close to that of Brainfuck.

Macro systems can be very powerful, but they are also quite hard to use. It is 2016 and error messages in C++ templates are still inferior to the messages you get in C#, Java or Scala generics, despite templates existing for much longer.

C++ templates are also not the very best at metaprogramming either. Take any macro system like the ones found in LISPs, Scala or Template Haskell - they are much more powerful and consistent with the rest of the language. I can code Scala metaprograms in Scala or LISP metaprograms in LISP. But I can't code C++ metaprograms in C++, I have to use this weird duck-typed functional template language which doesn't have even loops or conditionals.

That weird duck typed functional template language runs circles around C# and Java generics.

I have experience in compiler design and C#, Java and C++ are my tools of trade. So I know their generics systems pretty well.

Maybe if I get bored during Easter I can bother to provide your safe list.

> That weird duck typed functional template language runs circles around C# and Java generics

This sentence doesn't make much sense. Comparing oranges and apples. It is like saying Scala macros are better than Scala generics. C++ templates are neither great at metaprogramming (there are much better macro systems in other languages out there) nor great at generics (Java, C# or Swift generics are not state-of-the-art either, but in some cases I mentioned they are better).

One case where Java generics are far superior to C# (actually CLR) is implementing more advanced generics on top of JVM thanks to erasure. C# generics are too weak to express concepts found in Scala or Haskell type system directly, but at the same time too strong to serve as a base for a standalone implementation of such type systems.

When does it matter what an element from a List<List<String>> is cast to at runtime? In a properly-written statically-typed program, types are a compile-time construct (ignoring the machinery of dynamic linking and method call semantics in particular implementations, which don't matter to the programmer), and though you may use them at runtime via reflection, I would argue that 99% of the time that you do, you're writing bad code. http://stackoverflow.com/questions/20918650/what-are-the-ben...

Type erasure introduces limitations on what you can do at runtime that forces a developer to write code to workaround it. For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary. A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).

> A lot of JVM-based languages are required to introduce additional complexity in the language to simulate reified generics (e.g. Scala's Manifest/TypeTag classes).

I'm not sure how this makes sense. These tags are just standard context bounds, which are extremely useful and quite awesome.

You make it sound as if these tags were some kind of special feature added to the language, or context bounds were solely invented to support these tags.

> For example, in Java you can't write a generic method that instantiates an object based on the type of the generic. The workaround is typically to pass in the Class type as an additional parameter to the method, which in theory should not be necessary.

If a method needs to instantiate an object, the normal technique is to accept a factory function as a parameter. You can do the same thing with type-erased generics.

C# decided to create a shortcut for calling the constructor of a generic type parameter. But, for example, you can't call static methods of a generic type parameter (and a constructor is really just a slightly special static method).

Passing in the class type for instantiating a new instance is not what you should do in your applications. You don't know at compile time if the class you pass in has a default constructor, so your program can fail at runtime. As others have stated, the right thing to do is pass in a factory object. C# solves this by adding even more cruft to the language in the form of a "new constraint" that tells the compiler to ensure that the type has a default constructor. https://msdn.microsoft.com/en-us/library/sd2w2ew5.aspx

Don't Java Generics mess with method (argument type) Overloading?

> Generics were a cutting-edge feature in 2005.

Generics have been around since at least the early '80s.

Well, "cutting-edge" in enterprise technology.

Another interesting failed prototype on the JVM was the language "Pizza" https://en.wikipedia.org/wiki/Pizza_%28programming_language%...

Ada isn't enterprise technology?

https://en.wikibooks.org/wiki/Ada_Programming/Generics

http://www.cs.dartmouth.edu/reports/TR86-104.pdf

(From 1984.)

Reply on news.ycombinator.com