<p>I have a mapping application that needs to draw a path, and then display icons on top of the path. I can't find a way to control the order of virtual earth layers, other than the order in which they are added. </p>

<p>Does anyone know how to change the z index of Virtual Earth shape layers, or force a layer to the front?</p>

[{'answer_id': 31696, 'author': 'travis', 'author_id': 1414, 'author_profile': 'https://Stackoverflow.com/users/1414', 'pm_score': 2, 'selected': False, 'text': '<p>Wikipedia has great write-ups comparing both <a href="http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java#Generics" rel="nofollow noreferrer">Java/C# generics</a> and <a href="http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Templates_vs._Generics" rel="nofollow noreferrer">Java generics/C++</a> templates. The <a href="http://en.wikipedia.org/wiki/Generic_programming" rel="nofollow noreferrer">main article on Generics</a> seems a bit cluttered but it does have some good info in it.</p>\n'}, {'answer_id': 31697, 'author': 'jfs', 'author_id': 718, 'author_profile': 'https://Stackoverflow.com/users/718', 'pm_score': 5, 'selected': False, 'text': '<p>Anders Hejlsberg himself described the differences here "<a href="http://www.artima.com/intv/generics2.html" rel="noreferrer">Generics in C#, Java, and C++</a>".</p>\n'}, {'answer_id': 31698, 'author': 'Matt Cummings', 'author_id': 828, 'author_profile': 'https://Stackoverflow.com/users/828', 'pm_score': 1, 'selected': False, 'text': '<p>The biggest complaint is type erasure.  In that, generics are not enforced at runtime.  <a href="http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html" rel="nofollow noreferrer">Here\'s a link to some Sun docs on the subject</a>.</p>\n\n<blockquote>\n  <p>Generics are implemented by type\n  erasure: generic type information is\n  present only at compile time, after\n  which it is erased by the compiler.</p>\n</blockquote>\n'}, {'answer_id': 31721, 'author': 'On Freund', 'author_id': 2150, 'author_profile': 'https://Stackoverflow.com/users/2150', 'pm_score': 1, 'selected': False, 'text': '<p>C++ templates are actually much more powerful than their C# and Java counterparts as they are evaluated at compile time and support specialization. This allows for Template Meta-Programming and makes the C++ compiler equivalent to a Turing machine (i.e. during the compilation process you can compute anything that is computable with a Turing machine).</p>\n'}, {'answer_id': 31758, 'author': 'Konrad Rudolph', 'author_id': 1968, 'author_profile': 'https://Stackoverflow.com/users/1968', 'pm_score': 6, 'selected': False, 'text': '<p>C++ rarely uses the “generics” terminology. Instead, the word “templates” is used and is more accurate. Templates describes one <em>technique</em> to achieve a generic design.</p>\n\n<p>C++ templates is very different from what both C# and Java implement for two main reasons. The first reason is that C++ templates don\'t only allow compile-time type arguments but also compile-time const-value arguments: templates can be given as integers or even function signatures. This means that you can do some quite funky stuff at compile time, e.g. calculations:</p>\n\n<pre><code>template &lt;unsigned int N&gt;\nstruct product {\n    static unsigned int const VALUE = N * product&lt;N - 1&gt;::VALUE;\n};\n\ntemplate &lt;&gt;\nstruct product&lt;1&gt; {\n    static unsigned int const VALUE = 1;\n};\n\n// Usage:\nunsigned int const p5 = product&lt;5&gt;::VALUE;\n</code></pre>\n\n<p>This code also uses the other distinguished feature of C++ templates, namely template specialization. The code defines one class template, <code>product</code> that has one value argument. It also defines a specialization for that template that is used whenever the argument evaluates to 1. This allows me to define a recursion over template definitions. I believe that this was first discovered by <a href="http://erdani.org/" rel="noreferrer">Andrei Alexandrescu</a>.</p>\n\n<p>Template specialization is important for C++ because it allows for structural differences in data structures. Templates as a whole is a means of unifying an interface across types. However, although this is desirable, all types cannot be treated equally inside the implementation. C++ templates takes this into account. This is very much the same difference that OOP makes between interface and implementation with the overriding of virtual methods.</p>\n\n<p>C++ templates are essential for its algorithmic programming paradigm. For example, almost all algorithms for containers are defined as functions that accept the container type as a template type and treat them uniformly. Actually, that\'s not quite right: C++ doesn\'t work on containers but rather on <em>ranges</em> that are defined by two iterators, pointing to the beginning and behind the end of the container. Thus, the whole content is circumscribed by the iterators: begin &lt;= elements &lt; end.</p>\n\n<p>Using iterators instead of containers is useful because it allows to operate on parts of a container instead of on the whole.</p>\n\n<p>Another distinguishing feature of C++ is the possibility of <em>partial specialization</em> for class templates. This is somewhat related to pattern matching on arguments in Haskell and other functional languages. For example, let\'s consider a class that stores elements:</p>\n\n<pre><code>template &lt;typename T&gt;\nclass Store { … }; // (1)\n</code></pre>\n\n<p>This works for any element type. But let\'s say that we can store pointers more effciently than other types by applying some special trick. We can do this by <em>partially</em> specializing for all pointer types:</p>\n\n<pre><code>template &lt;typename T&gt;\nclass Store&lt;T*&gt; { … }; // (2)\n</code></pre>\n\n<p>Now, whenever we instance a container template for one type, the appropriate definition is used:</p>\n\n<pre><code>Store&lt;int&gt; x; // Uses (1)\nStore&lt;int*&gt; y; // Uses (2)\nStore&lt;string**&gt; z; // Uses (2), with T = string*.\n</code></pre>\n'}, {'answer_id': 31778, 'author': 'izb', 'author_id': 974, 'author_profile': 'https://Stackoverflow.com/users/974', 'pm_score': 1, 'selected': False, 'text': "<p>In Java, generics are compiler level only, so you get:</p>\n\n<pre><code>a = new ArrayList&lt;String&gt;()\na.getClass() =&gt; ArrayList\n</code></pre>\n\n<p>Note that the type of 'a' is an array list, not a list of strings. So the type of a list of bananas would equal() a list of monkeys.</p>\n\n<p>So to speak.</p>\n"}, {'answer_id': 31821, 'author': 'Konrad Rudolph', 'author_id': 1968, 'author_profile': 'https://Stackoverflow.com/users/1968', 'pm_score': 4, 'selected': False, 'text': "<p>Follow-up to my previous posting.</p>\n\n<p>Templates are one of the main reasons why C++ fails so abysmally at intellisense, regardless of the IDE used. Because of template specialization, the IDE can never be really sure if a given member exists or not. Consider:</p>\n\n<pre><code>template &lt;typename T&gt;\nstruct X {\n    void foo() { }\n};\n\ntemplate &lt;&gt;\nstruct X&lt;int&gt; { };\n\ntypedef int my_int_type;\n\nX&lt;my_int_type&gt; a;\na.|\n</code></pre>\n\n<p>Now, the cursor is at the indicated position and it's damn hard for the IDE to say at that point if, and what, members <code>a</code> has. For other languages the parsing would be straightforward but for C++, quite a bit of evaluation is needed beforehand.</p>\n\n<p>It gets worse. What if <code>my_int_type</code> were defined inside a class template as well? Now its type would depend on another type argument. And here, even compilers fail.</p>\n\n<pre><code>template &lt;typename T&gt;\nstruct Y {\n    typedef T my_type;\n};\n\nX&lt;Y&lt;int&gt;::my_type&gt; b;\n</code></pre>\n\n<p>After a bit of thinking, a programmer would conclude that this code is the same as the above: <code>Y&lt;int&gt;::my_type</code> resolves to <code>int</code>, therefore <code>b</code> should be the same type as <code>a</code>, right?</p>\n\n<p>Wrong. At the point where the compiler tries to resolve this statement, it doesn't actually know <code>Y&lt;int&gt;::my_type</code> yet! Therefore, it doesn't know that this is a type. It could be something else, e.g. a member function or a field. This might give rise to ambiguities (though not in the present case), therefore the compiler fails. We have to tell it explicitly that we refer to a type name:</p>\n\n<pre><code>X&lt;typename Y&lt;int&gt;::my_type&gt; b;\n</code></pre>\n\n<p>Now, the code compiles. To see how ambiguities arise from this situation, consider the following code:</p>\n\n<pre><code>Y&lt;int&gt;::my_type(123);\n</code></pre>\n\n<p>This code statement is perfectly valid and tells C++ to execute the function call to <code>Y&lt;int&gt;::my_type</code>. However, if <code>my_type</code> is not a function but rather a type, this statement would still be valid and perform a special cast (the function-style cast) which is often a constructor invocation. The compiler can't tell which we mean so we have to disambiguate here.</p>\n"}, {'answer_id': 31866, 'author': 'serg10', 'author_id': 1853, 'author_profile': 'https://Stackoverflow.com/users/1853', 'pm_score': 3, 'selected': False, 'text': '<p>Both Java and C# introduced generics after their first language release.  However, there are differences in how the core libraries changed when generics was introduced.  <strong>C#\'s generics are not just compiler magic</strong> and so it was not possible to <em>generify</em> existing library classes without breaking backwards compatibility.</p>\n\n<p>For example, in Java the existing <a href="http://java.sun.com/javase/6/docs/technotes/guides/collections/index.html" rel="noreferrer">Collections Framework</a> was <em>completely genericised</em>.  <strong>Java does not have both a generic and legacy non-generic version of the collections classes.</strong>  In some ways this is much cleaner - if you need to use a collection in C# there is really very little reason to go with the non-generic version, but those legacy classes remain in place, cluttering up the landscape. </p>\n\n<p><strong>Another notable difference is the Enum classes in Java and C#.</strong>  Java\'s Enum has this somewhat tortuous looking definition:</p>\n\n<pre><code>//  java.lang.Enum Definition in Java\npublic abstract class Enum&lt;E extends Enum&lt;E&gt;&gt; implements Comparable&lt;E&gt;, Serializable {\n</code></pre>\n\n<p>(see Angelika Langer\'s very clear <a href="http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#How%20do%20I%20decrypt%20Enum?" rel="noreferrer">explanation of exactly why</a> this is so.  Essentially, this means Java can give type safe access from a string to its Enum value:</p>\n\n<pre><code>//  Parsing String to Enum in Java\nColour colour = Colour.valueOf("RED");\n</code></pre>\n\n<p>Compare this to C#\'s version:</p>\n\n<pre><code>//  Parsing String to Enum in C#\nColour colour = (Colour)Enum.Parse(typeof(Colour), "RED");\n</code></pre>\n\n<p>As Enum already existed in C# before generics was introduced to the language, the definition could not change without breaking existing code.  So, like collections, it remains in the core libraries in this legacy state.</p>\n'}, {'answer_id': 31929, 'author': 'Orion Edwards', 'author_id': 234, 'author_profile': 'https://Stackoverflow.com/users/234', 'pm_score': 10, 'selected': True, 'text': "<p>I'll add my voice to the noise and take a stab at making things clear:</p>\n<h2>C# Generics allow you to declare something like this.</h2>\n<pre><code>List&lt;Person&gt; foo = new List&lt;Person&gt;();\n</code></pre>\n<p>and then the compiler will prevent you from putting things that aren't <code>Person</code> into the list.<br />\nBehind the scenes the C# compiler is just putting <code>List&lt;Person&gt;</code> into the .NET dll file, but at runtime the JIT compiler  goes and builds a new set of code, as if you had written a special list class just for containing people - something like <code>ListOfPerson</code>.</p>\n<p>The benefit of this is that it makes it really fast. There's no casting or any other stuff, and because the dll contains the information that this is a List of <code>Person</code>, other code that looks at it later on using reflection can tell that it contains <code>Person</code> objects (so you get intellisense and so on).</p>\n<p>The downside of this is that old C# 1.0 and 1.1 code (before they added generics) doesn't understand these new <code>List&lt;something&gt;</code>, so you have to manually convert things back to plain old <code>List</code> to interoperate with them. This is not that big of a problem, because C# 2.0 binary code is not backwards compatible. The only time this will ever happen is if you're upgrading some old C# 1.0/1.1 code to C# 2.0</p>\n<h2>Java Generics allow you to declare something like this.</h2>\n<pre><code>ArrayList&lt;Person&gt; foo = new ArrayList&lt;Person&gt;();\n</code></pre>\n<p>On the surface it looks the same, and it sort-of is. The compiler will also prevent you from putting things that aren't <code>Person</code> into the list.</p>\n<p>The difference is what happens behind the scenes. Unlike C#, Java does not go and build a special <code>ListOfPerson</code> - it just uses the plain old <code>ArrayList</code> which has always been in Java. When you get things out of the array, the usual <code>Person p = (Person)foo.get(1);</code> casting-dance still has to be done. The compiler is saving you the key-presses, but the speed hit/casting is still incurred just like it always was.<br />\nWhen people mention &quot;Type Erasure&quot; this is what they're talking about. The compiler inserts the casts for you, and then 'erases' the fact that it's meant to be a list of <code>Person</code> not just <code>Object</code></p>\n<p>The benefit of this approach is that old code which doesn't understand generics doesn't have to care. It's still dealing with the same old <code>ArrayList</code> as it always has. This is more important in the java world because they wanted to support compiling code using Java 5 with generics, and having it run on old 1.4 or previous JVM's, which microsoft deliberately decided not to bother with.</p>\n<p>The downside is the speed hit I mentioned previously, and also because there is no <code>ListOfPerson</code> pseudo-class or anything like that going into the .class files, code that looks at it later on (with reflection, or if you pull it out of another collection where it's been converted into <code>Object</code> or so on) can't tell in any way that it's meant to be a list containing only <code>Person</code> and not just any other array list.</p>\n<h2>C++ Templates allow you to declare something like this</h2>\n<pre><code>std::list&lt;Person&gt;* foo = new std::list&lt;Person&gt;();\n</code></pre>\n<p>It looks like C# and Java generics, and it will do what you think it should do, but behind the scenes different things are happening.</p>\n<p>It has the most in common with C# generics in that it builds special <code>pseudo-classes</code> rather than just throwing the type information away like java does, but it's a whole different kettle of fish.</p>\n<p>Both C# and Java produce output which is designed for virtual machines. If you write some code which has a <code>Person</code> class in it, in both cases some information about a <code>Person</code> class will go into the .dll or .class file, and the JVM/CLR will do stuff with this.</p>\n<p>C++ produces raw x86 binary code. Everything is <em>not</em> an object, and there's no underlying virtual machine which needs to know about a <code>Person</code> class. There's no boxing or unboxing, and functions don't have to belong to classes, or indeed anything.</p>\n<p>Because of this, the C++ compiler places no restrictions on what you can do with templates - basically any code you could write manually, you can get templates to write for you.<br />\nThe most obvious example is adding things:</p>\n<p>In C# and Java, the generics system needs to know what methods are available for a class, and it needs to pass this down to the virtual machine. The only way to tell it this is by either hard-coding the actual class in, or using interfaces. For example:</p>\n<pre><code>string addNames&lt;T&gt;( T first, T second ) { return first.Name() + second.Name(); }\n</code></pre>\n<p>That code won't compile in C# or Java, because it doesn't know that the type <code>T</code> actually provides a method called Name(). You have to tell it - in C# like this:</p>\n<pre><code>interface IHasName{ string Name(); };\nstring addNames&lt;T&gt;( T first, T second ) where T : IHasName { .... }\n</code></pre>\n<p>And then you have to make sure the things you pass to addNames implement the IHasName interface and so on. The java syntax is different (<code>&lt;T extends IHasName&gt;</code>), but it suffers from the same problems.</p>\n<p>The 'classic' case for this problem is trying to write a function which does this</p>\n<pre><code>string addNames&lt;T&gt;( T first, T second ) { return first + second; }\n</code></pre>\n<p>You can't actually write this code because there are no ways to declare an interface with the <code>+</code> method in it. You fail.</p>\n<p>C++ suffers from none of these problems. The compiler doesn't care about passing types down to any VM's - if both your objects have a .Name() function, it will compile. If they don't, it won't. Simple.</p>\n<p>So, there you have it :-)</p>\n"}, {'answer_id': 33729, 'author': 'Jörg W Mittag', 'author_id': 2988, 'author_profile': 'https://Stackoverflow.com/users/2988', 'pm_score': 4, 'selected': False, 'text': '<p>There are already a lot of good answers on <em>what</em> the differences are, so let me give a slightly different perspective and add the <em>why</em>.</p>\n\n<p>As was already explained, the main difference is <em>type erasure</em>, i.e. the fact that the Java compiler erases the generic types and they don\'t end up in the generated bytecode. However, the question is: why would anyone do that? It doesn\'t make sense! Or does it?</p>\n\n<p>Well, what\'s the alternative? If you don\'t implement generics in the language, where <em>do</em> you implement them? And the answer is: in the Virtual Machine. Which breaks backwards compatibility.</p>\n\n<p>Type erasure, on the other hand, allows you to mix generic clients with non-generic libraries. In other words: code that was compiled on Java 5 can still be deployed to Java 1.4.</p>\n\n<p>Microsoft, however, decided to break backwards compatibility for generics. <em>That\'s</em> why .NET Generics are "better" than Java Generics.</p>\n\n<p>Of course, Sun aren\'t idiots or cowards. The reason why they "chickened out", was that Java was significantly older and more widespread than .NET when they introduced generics. (They were introduced roughly at the same time in both worlds.) Breaking backwards compatibility would have been a huge pain.</p>\n\n<p>Put yet another way: in Java, Generics are a part of the <em>Language</em> (which means they apply <em>only</em> to Java, not to other languages), in .NET they are part of the <em>Virtual Machine</em> (which means they apply to <em>all</em> languages, not just C# and Visual Basic.NET).</p>\n\n<p>Compare this with .NET features like LINQ, lambda expressions, local variable type inference, anonymous types and expression trees: these are all <em>language</em> features. That\'s why there are subtle differences between VB.NET and C#: if those features were part of the VM, they would be the same in <em>all</em> languages. But the CLR hasn\'t changed: it\'s still the same in .NET 3.5 SP1 as it was in .NET 2.0. You can compile a C# program that uses LINQ with the .NET 3.5 compiler and still run it on .NET 2.0, provided that you don\'t use any .NET 3.5 libraries. That would <em>not</em> work with generics and .NET 1.1, but it <em>would</em> work with Java and Java 1.4.</p>\n'}, {'answer_id': 38286, 'author': 'pek', 'author_id': 2644, 'author_profile': 'https://Stackoverflow.com/users/2644', 'pm_score': 1, 'selected': False, 'text': '<p>Looks like, among other very interesting proposals, there is one about refining generics and breaking backwards compatibility:</p>\n\n<blockquote>\n  <p>Currently, generics are implemented\n  using erasure, which means that the\n  generic type information is not\n  available at runtime, which makes some\n  kind of code hard to write. Generics\n  were implemented this way to support\n  backwards compatibility with older\n  non-generic code. Reified generics\n  would make the generic type\n  information available at runtime,\n  which would break legacy non-generic\n  code. However, Neal Gafter has\n  proposed making types reifiable only\n  if specified, so as to not break\n  backward compatibility.</p>\n</blockquote>\n\n<p>at <a href="http://tech.puredanger.com/java7#reified" rel="nofollow noreferrer">Alex Miller\'s article about Java 7 Proposals</a></p>\n'}, {'answer_id': 1109644, 'author': 'Daniel Earwicker', 'author_id': 27423, 'author_profile': 'https://Stackoverflow.com/users/27423', 'pm_score': 2, 'selected': False, 'text': "<p>11 months late, but I think this question is ready for some Java Wildcard stuff.</p>\n\n<p>This is a syntactical feature of Java. Suppose you have a method:</p>\n\n<pre><code>public &lt;T&gt; void Foo(Collection&lt;T&gt; thing)\n</code></pre>\n\n<p>And suppose you don't need to refer to the type T in the method body. You're declaring a name T and then only using it once, so why should you have to think of a name for it? Instead, you can write:</p>\n\n<pre><code>public void Foo(Collection&lt;?&gt; thing)\n</code></pre>\n\n<p>The question-mark asks the the compiler to pretend that you declared a normal named type parameter that only needs to appear once in that spot.</p>\n\n<p>There's nothing you can do with wildcards that you can't also do with a named type parameter (which is how these things are always done in C++ and C#).</p>\n"}, {'answer_id': 3398108, 'author': 'Sheepy', 'author_id': 409817, 'author_profile': 'https://Stackoverflow.com/users/409817', 'pm_score': 0, 'selected': False, 'text': "<p>NB: I don't have enough point to comment, so feel free to move this as a comment to appropriate answer.</p>\n\n<p>Contrary to popular believe, which I never understand where it came from, .net implemented true generics without breaking backward compatibility, and they spent explicit effort for that.\nYou don't have to change your non-generic .net 1.0 code into generics just to be used in .net 2.0. Both the generic and non-generic lists are still available in .Net framework 2.0 even until 4.0, exactly for nothing else but backward compatibility reason. Therefore old codes that still used non-generic ArrayList will still work, and use the same ArrayList class as before.\nBackward code compatibility is always maintained since 1.0 till now... So even in .net 4.0, you still have to option to use any non-generics class from 1.0 BCL if you choose to do so.</p>\n\n<p>So I don't think java has to break backward compatibility to support true generics.</p>\n"}]
['https://Stackoverflow.com/questions/31701', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/2785/']