The reaseon i'm not sure if i should study c++ is the possibility that i may not end up in a game industry at all (small european country, not US unfortunately)

There are many games companies within Europe, and assuming you live in an EU country, then you are free to move to a country that does have games studios. Games companies tend to be quite multicultural, and they're quite used to hiring from across Europe.

I just had to make a go of the counting to 10,000 thing because I've done similar things many times at work.

using System;
using System.Text;

namespace ConsoleApplication1
{
  class Program
  {
    static void Main()
    {
      StringBuilder output = new StringBuilder();
      
      for (int i = 1; i <= 10000; i++)
      {
        if (output.Length > 0)
        {
          output.Append(',');
        }

        output.Append(i);
      }

      Console.WriteLine(output);
      Console.ReadKey();
    }
  }
}

Anyway, I don't know if it's the most optimal way to do it, but it's definitely worked well for me over the years.

Edit:

Actually, initializing the string builder with a capacity is more optimal than what I have here.

I find it interesting that in these situations programmers almost always make the special case last rather than making the special case first. That is here they think "output a comma behind every element but the last" rather than "output a comma before every element but the first".

This surprised me as well. Is it a thing of imperative vs functional background?

(in a functional program, you almost always want the special case first, since the N-1th case is hard to detect)

I'm not sure it's functional vs imperative, per se. I think it's just not an idea that occurs to people naturally and generally has to be introduced. It's just that your chances of being introduced to the idea of special case first is much higher with a functional background.

That works, but it is extremely inefficient(slow), Strings in Java are immutable so each time you try to modify the string (using += for example) it creates a new string object containing the concatenated string and replaces the old reference leaving the old string as garbage for the GC to clean up (not good).

It's even worse than that. The java compiler tries to be smart and uses StringBuilder for all concatenations, but it's a peephole optimization; it doesn't consider it in the context of the surrounding code. What you'll really end with will be more like this:

public class Main {
	public static void main(String[] args){
	String xx = "";
	for (int x = 0; x < 10001;x++){
		xx = (new StringBuilder(String.valueOf(xx))).append(x).append(", ").toString();
	}
	System.out.println(xx);
}}

So not only are you creating a new string each iteration, a new instance of StringBuilder is created, too.

I feel like this would be jitted down so it only did that the first couple of times.

More seriously when you're usually trying to do something like that speed is fairly irrelevant (unless you're routinely concating 10 000 strings with a separator in your games?).

My favorite version is in LINQ, simple readable, no 0 or 1 offset bugs, no need for special case (removing the first or last character) and the shortest version. And even without using a stringbuilder and going for simplest path it's at 200ms which means if you're annoying yourself with a stringbuilder here when performance constraint aren't noted you're doing it wrong in my book.

string s = Enumerable.Range(1,10000)
.Select(item=>item.ToString())
.Aggregate((a,b)=>a+";"+b);

C# BITCHES *drop microphone*.

edit: how does that actually translate to machine code? I imagine it's about the same as the for loop when done properly (I feel like that's what a lot of Linq boils down to in most cases it just protects the user from doing it improperly).

My favorite version is in LINQ, simple readable, no 0 or 1 offset bugs, no need for special case (removing the first or last character) and the shortest version. And even without using a stringbuilder and going for simplest path it's at 200ms which means if you're annoying yourself with a stringbuilder here when performance constraint aren't noted you're doing it wrong in my book.

string s = Enumerable.Range(1,10000)
.Select(item=>item.ToString())
.Aggregate((a,b)=>a+";"+b);

I see your LINQ, and I raise you Python...

[source]', '.join(str(i) for i in range(1,10001))[/source]

My favorite version is in LINQ, simple readable, no 0 or 1 offset bugs, no need for special case (removing the first or last character) and the shortest version. And even without using a stringbuilder and going for simplest path it's at 200ms which means if you're annoying yourself with a stringbuilder here when performance constraint aren't noted you're doing it wrong in my book.

string s = Enumerable.Range(1,10000)
.Select(item=>item.ToString())
.Aggregate((a,b)=>a+";"+b);

I see your LINQ, and I raise you Python...

[source]', '.join(str(i) for i in range(1,10001))[/source]

I like this C# version much more than the Linq above.

String.Join(",", Enumerable.Range(1, 10000));

My favorite version is in LINQ, simple readable, no 0 or 1 offset bugs, no need for special case (removing the first or last character) and the shortest version. And even without using a stringbuilder and going for simplest path it's at 200ms which means if you're annoying yourself with a stringbuilder here when performance constraint aren't noted you're doing it wrong in my book.

string s = Enumerable.Range(1,10000)
.Select(item=>item.ToString())
.Aggregate((a,b)=>a+";"+b);

I see your LINQ, and I raise you Python...

[source]', '.join(str(i) for i in range(1,10001))[/source]

I like this C# version much more than the Linq above.

String.Join(",", Enumerable.Range(1, 10000));

Sure fits the specific scenario better, but wanted to display the linq power, this is specific so something like string.join can be done in C++ too, my take on this is linq is generic enought that you can consider it as a result of "implement an algorithm to do x" instea of "call method that does x" in the language comparison in this thread. There's not a function for everything, but most of the time there's a way to do anything in 20% the amount of lines of procedural code in linq whenever it's about "generate, do operations or transform the shape of data".

Sure fits the specific scenario better, but wanted to display the linq power, this is specific so something like string.join can be done in C++ too, my take on this is linq is generic enought that you can consider it as a result of "implement an algorithm to do x" instea of "call method that does x" in the language comparison in this thread. There's not a function for everything, but most of the time there's a way to do anything in 20% the amount of lines of procedural code in linq whenever it's about "generate, do operations or transform the shape of data".

There is nothing unique to LINQ there - it's just basic functional programming techniques.

Enumerable.Aggregate() is the reduce() function, hiding behind a confusing new name, and Enumerable.Select() is just a map/filter:
[source]reduce(lambda x,y: x+', '+y, map(str, xrange(1,1001)))[/source]

Sure fits the specific scenario better, but wanted to display the linq power, this is specific so something like string.join can be done in C++ too, my take on this is linq is generic enought that you can consider it as a result of "implement an algorithm to do x" instea of "call method that does x" in the language comparison in this thread. There's not a function for everything, but most of the time there's a way to do anything in 20% the amount of lines of procedural code in linq whenever it's about "generate, do operations or transform the shape of data".

There is nothing unique to LINQ there - it's just basic functional programming techniques.

Enumerable.Aggregate() is the reduce() function, hiding behind a confusing new name, and Enumerable.Select() is just a map/filter:
[source]reduce(lambda x,y: x+', '+y, map(str, xrange(1,1001)))[/source]

I know that too, but in C# it's just LINQ, i was speaking for C# in this "is C++ a must" thread, so i'm not going to use non C# terms. Overall the goal was mostly to showcase that those kind of sample tests were pretty useless anyway as API can turn those into a 1 liner regardless of languages.

Also i don't think any classical functional languages are making a dent in game programming atm so this doesn't sound too relevant to the discussion as those wouldn't be the alternative one'd be likely to pick from C++ would it?