Let's talk IDEs

[Falcon]

Isn't IntelliJ for Java only? Or is it extendable like Eclipse? As far as C/C++ IDEs I find that Visual Studio and Qt Creator are the best. Eclipse with C++ plugin on the other hand blows.

[Sidoh]

Isn't IntelliJ for Java only? Or is it extendable like Eclipse? As far as C/C++ IDEs I find that Visual Studio and Qt Creator are the best. Eclipse with C++ plugin on the other hand blows.

The company that makes IntelliJ (JetBrains) makes quite a few language-specific IDEs. I've used RubyMine as well, and it's also pretty awesome. IDEs are always more useful for strongly-typed languages, though...

I know there are plugins that enable their IDEs to be a reasonable C/C++ editor, but I'm sure it's not quite Visual Studio.

The professional version of IntelliJ also manages to be a pretty great IDE for jetty stuff (meaning it's a good HTML, CSS, JavasScript, and JSP editor).

edit: Looks like they're working on a C/C++ IDE.

[Sidoh]

We have a convention for how sources are organized in the tree. I normally know exactly where to look just from the functionality I need.

I normally need to find some text or function definition in one of those files rather than a file itself ...

Right. I'm sure you know where stuff is. I think what I'm meaning to ask is when you know exactly what file you want to open or definition you want to go to, how do you do it? Do you use visual studio?

I'm not trying to convince you to use a non-IDE environment. I was only arguing that a Unix shell environment is more efficient for development than an IDE. We've established that Visual Studio is the culprit of my findings (which I thought was the gold standard for IDEs).

Well, if a unix shell is actually more efficient for development than an IDE, I'd like to be convinced. So far, I'm not even close.

I don't normally have to write hash functions. If I didn't care about performance, I'd just use std::map and write a less than operator. If I cared about performance, I would try to derive a hash function myself that wouldn't likely collide and plug it into std::unordered_map.

Although, some code templates could be useful. Nifty.

I don't think caring about performance is binary. I usually care enough about performance to use HashMap over TreeMap, but I rarely see much worth in optimizing the hash function.

Anyway, the equals it generates is generally about as performant as you can hope for, and it'd still be a little annoying to write:

Code: [Select]

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }

    TimeSegment that = (TimeSegment)o;

    if (count != that.count) {
      return false;
    }
    if (unit != that.unit) {
      return false;
    }

    return true;
  }

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

I'd really love to see a development environment that implemented half of the features I listed in any significant capacity. This isn't something you can accomplish by shelling out to the compiler. I'll try to demonstrate.

Let's say I have a Map with String keys and Integer values. If it's the only iterable in scope, this is what I see when I type "iter<tab>":



If I update it to map.entrySet(), this is what I see:



notice that the type is updated automatically. This is really the beauty of these live templates. You see what the code the IDE is generating for you as you update the input. When I press "enter", I'm prompted to enter a name for the iteration variable. The generated name is usually acceptable (although not in this case).


Let's say I have a final member variable that isn't initialized. I can press <Alt>-<Enter> over it and I get this menu:



In this case, the first option is what I want. If I press <Enter>, I get this:



Now let's say I want to delegate the methods that Map declares to the member variable. I can do that by pressing <Alt>-N, typing "del" and pressing <Enter>:



I get this menu, which is a little more useful when there's more than one option:



Then it shows me a list of methods that I could delegate. Let's say I want to delegate everything except for get(Object). There's probably some fancy way to do this with the keyboard, but I'd probably just do <Ctrl>-A to select them all and then delete get, or just Ctrl-Click get:



This is what I get:



Notice this feature is only possible if the editor is aware of what methods Map implements. It'll be able to do this even if the delegate isn't typed as a Map. It just has to be anything that implements Map. The editor is able to infer all of that. It took less than 10 seconds to generate all of that code. You can imagine it'd take a long time to type it manually in the general case, especially if the interface you're writing a delegate for has lots of methods.

[nslay]

We have a convention for how sources are organized in the tree. I normally know exactly where to look just from the functionality I need.

I normally need to find some text or function definition in one of those files rather than a file itself ...

Right. I'm sure you know where stuff is. I think what I'm meaning to ask is when you know exactly what file you want to open or definition you want to go to, how do you do it? Do you use visual studio?

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

I'm not trying to convince you to use a non-IDE environment. I was only arguing that a Unix shell environment is more efficient for development than an IDE. We've established that Visual Studio is the culprit of my findings (which I thought was the gold standard for IDEs).

Well, if a unix shell is actually more efficient for development than an IDE, I'd like to be convinced. So far, I'm not even close.

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

I don't normally have to write hash functions. If I didn't care about performance, I'd just use std::map and write a less than operator. If I cared about performance, I would try to derive a hash function myself that wouldn't likely collide and plug it into std::unordered_map.

Although, some code templates could be useful. Nifty.

I don't think caring about performance is binary. I usually care enough about performance to use HashMap over TreeMap, but I rarely see much worth in optimizing the hash function.

Then it seems you don't use a hash map for anything performant in the first place.

Anyway, the equals it generates is generally about as performant as you can hope for, and it'd still be a little annoying to write:

Code: [Select]

  @Override
  public boolean equals(Object o) {
    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }

    TimeSegment that = (TimeSegment)o;

    if (count != that.count) {
      return false;
    }
    if (unit != that.unit) {
      return false;
    }

    return true;
  }

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

I'd really love to see a development environment that implemented half of the features I listed in any significant capacity. This isn't something you can accomplish by shelling out to the compiler. I'll try to demonstrate.

Let's say I have a Map with String keys and Integer values. If it's the only iterable in scope, this is what I see when I type "iter<tab>":



If I update it to map.entrySet(), this is what I see:



notice that the type is updated automatically. This is really the beauty of these live templates. You see what the code the IDE is generating for you as you update the input. When I press "enter", I'm prompted to enter a name for the iteration variable. The generated name is usually acceptable (although not in this case).


Let's say I have a final member variable that isn't initialized. I can press <Alt>-<Enter> over it and I get this menu:



In this case, the first option is what I want. If I press <Enter>, I get this:



Now let's say I want to delegate the methods that Map declares to the member variable. I can do that by pressing <Alt>-N, typing "del" and pressing <Enter>:



I get this menu, which is a little more useful when there's more than one option:



Then it shows me a list of methods that I could delegate. Let's say I want to delegate everything except for get(Object). There's probably some fancy way to do this with the keyboard, but I'd probably just do <Ctrl>-A to select them all and then delete get, or just Ctrl-Click get:



This is what I get:



Notice this feature is only possible if the editor is aware of what methods Map implements. It'll be able to do this even if the delegate isn't typed as a Map. It just has to be anything that implements Map. The editor is able to infer all of that. It took less than 10 seconds to generate all of that code. You can imagine it'd take a long time to type it manually in the general case, especially if the interface you're writing a delegate for has lots of methods.

That's very handy. I could definitely benefit from something like that.

[Sidoh]

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

That's completely ridiculous! I'd never navigate that way. I press Ctrl+Shift+N and type the name of the class/file I want and press Enter. There's no delay... the index makes it functionally instantaneous. Much, much faster than clicking through the source tree... does visual studio really not do that?

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

These aren't problems in a Java development environment. This is all the more reason for me to steer clear of C++. I'll actually actively avoid companies that use C++ after hearing about all this nonsense. It sounds absolutely infuriating. I've worked with and been frustrated by small C++ projects; I guess I should've figured those issues would only compound as the codebase gets more complex.

Then it seems you don't use a hash map for anything performant in the first place.

Uh... what? The generated hash function is good enough that it's still O(1) average time (instead of O(log n)). It's still much faster than a TreeMap, especially when the overhead is compounded by many terabytes of data (in groups of up to a few 1000).

Using HashMap along with the auto-generated hashCode provides enough speed improvement to justify using it over TreeMap and implementing compareTo.

As an aside: since every type in the java libraries that you could reasonably expect to implement a reliable hash function does, it's actually a lot easier to design a performant hash funciton in the majority of cases than you'd think.

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

You're only accepting Thing. In Java, equals must accept an arbitrary Object, so to have a completely general equals, it has to consider the type. If you only expect to receive instances of the same object, there's an option for that in the generation window.

In addition, there's no dereferencing in Java. If you want to verify that member variables are equal, you have to do it in the verbose way that the IDE used.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

Right, but that's annoying and inefficient. That's exactly my point. I'm happy to agree that if you don't have reliable red squigglies, you should be manually checking if things compile. However, it's far less annoying to have that information as you type. I almost never have false positives for reasons that wouldn't be present using the build file anyway (need to resolve dependencies, pull changes, etc.)

That's very handy. I could definitely benefit from something like that.

All of the features I listed are, I think. They save a lot of time.

It's not like the IDE does much thinking for you. It just saves you the trouble typing when you know exactly what you want. That's what an IDE should do, I think.

Another handy one: if you want to pull the return value of some method call out into a variable because you've discovered you want to use it in another place, you just put the cursor over it, press Ctrl+Alt+V and type a name for the variable. It also detects places that you've made exactly the same method call and replaces it with the variable.

[nslay]

In Visual Studio, you spend time looking at a long list of files in the Solution Explorer. This is made less worse by grouping the long list of sources into subgroups. Although, seeing that we have so many constituent projects, it's already time consuming to scroll through the list of projects, expand the tree and then further find the source you want! Shell is more efficient here, especially when you know the source tree by heart. Of course, if you had a text filter like you claim IntelliJ has, that would help (although file finding in VS or Windows is slower than Unix find!).

That's completely ridiculous! I'd never navigate that way. I press Ctrl+Shift+N and type the name of the class/file I want and press Enter. There's no delay... the index makes it functionally instantaneous. Much, much faster than clicking through the source tree... does visual studio really not do that?

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

And the Unix shell is definitely more efficient than Visual Studio ... by an enormous margin. There's no random freeze-ups, there's no reloading hundreds of projects when you regenerate a solution with CMake, there's no inability to find template definitions, there's no long monolithic list of sources to painstakingly scroll through, there's no 15 minute link time, there's no /MP glitches, there's no false positive red squiggly lines, there's no 10GB metadata files (which matters when you have terabytes of medical images on your drive) ...

But the biggest time wasters in Visual Studio are random freeze-ups and reloading project files. And it performs this way even on a modern OS like Windows Server 2008 on modern hardware (24 cores, 72GB of RAM).

These aren't problems in a Java development environment. This is all the more reason for me to steer clear of C++. I'll actually actively avoid companies that use C++ after hearing about all this nonsense. It sounds absolutely infuriating. I've worked with and been frustrated by small C++ projects; I guess I should've figured those issues would only compound as the codebase gets more complex.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Then it seems you don't use a hash map for anything performant in the first place.

Uh... what? The generated hash function is good enough that it's still O(1) average time (instead of O(log n)). It's still much faster than a TreeMap, especially when the overhead is compounded by many terabytes of data (in groups of up to a few 1000).

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Using HashMap along with the auto-generated hashCode provides enough speed improvement to justify using it over TreeMap and implementing compareTo.

As an aside: since every type in the java libraries that you could reasonably expect to implement a reliable hash function does, it's actually a lot easier to design a performant hash funciton in the majority of cases than you'd think.

That's completely overkill. Nice as it may be that your IDE can fill in some code for you, I'd have do the reverse of implementing operator==: Erase most of that. This is all I'd want:

Code: [Select]

bool operator==(const Thing &clOther) const {
  if (this == &clOther)
    return true;
  // TODO: Fill this in.
  return false;
}
That's not nearly as annoying or time consuming to write as you claim it to be, albeit less convenient than having it already. No living templates needed here.

You're only accepting Thing. In Java, equals must accept an arbitrary Object, so to have a completely general equals, it has to consider the type. If you only expect to receive instances of the same object, there's an option for that in the generation window.

operators and inheritance are ugly issues in C++.

In addition, there's no dereferencing in Java. If you want to verify that member variables are equal, you have to do it in the verbose way that the IDE used.

I'm sure you'll think of a convincing example. Just remember I'm not trying to convince you to use a non-IDE environment.

But I'm still convinced that a lot of the text-related functionality you listed can already be done with vim or emacs. And kind of cheating, plug clang into vim (since clang is modular and exposes its parser API), and you could pretty much do anything text-related you listed in vim with C or C++ ... actually on that thought, I just found this:
http://www.vim.org/scripts/script.php?script_id=3302

That apparently even does red squiggly lines ...

I still think it's cheating in the sense that vim is given more context than a normal text editor.

Will I use it in vim? Probably not ...

Squiggly red lines to me are more of a necessity and less of a fluffy feature. I'd much rather respond to errors as they crop up. Sometimes developing under the assumption that there are no errors leads to big problems and lots of wasted time.

Or just check to see if it compiles every so often ... you should do that any way, red lines or not. Of course, if you're stupid enough to write 1000 lines without checking if it compiles (even with red lines), you deserve what you get.

Right, but that's annoying and inefficient. That's exactly my point. I'm happy to agree that if you don't have reliable red squigglies, you should be manually checking if things compile. However, it's far less annoying to have that information as you type. I almost never have false positives for reasons that wouldn't be present using the build file anyway (need to resolve dependencies, pull changes, etc.)

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

That's very handy. I could definitely benefit from something like that.

All of the features I listed are, I think. They save a lot of time.

It's not like the IDE does much thinking for you. It just saves you the trouble typing when you know exactly what you want. That's what an IDE should do, I think.

Another handy one: if you want to pull the return value of some method call out into a variable because you've discovered you want to use it in another place, you just put the cursor over it, press Ctrl+Alt+V and type a name for the variable. It also detects places that you've made exactly the same method call and replaces it with the variable.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

[Sidoh]

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

Right, but I need to find files that aren't open dozens of times a day. I assume this is the case with you too? Do you really have to poke through the entire source tree any time you want to open a new file?

This isn't really a problem in IntelliJ either. I just leave everything open and press Alt+E, which lists recently opened files. You can then type to filter the list and press enter to open it. I hate using the mouse for this kind of stuff, and I'm really happy that I'm provided with efficient ways to circumvent moving my hand those six inches.

There's no way VisualStudio doesn't have something similar to this. It's too obvious a feature.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Sounds really awful. 

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Right, but in practice -- even with these generated hash functions -- a HashMap is much more performant than a TreeMap. It's performance-sensitive in that it's nice if it finishes a little faster. The distribution of group sizes is very widely spread for most data sets. Most reducers will have groups with millions of entries in a group, for example.

Most types used as keys are simple compositions of primitives, so it's quite easy to generate a good hash function algorithmically. It follows widely accepted best practices laid out in Effective Java. If you have a field that isn't a primitive, you can just incorporate the value of that object's hashCode into the return value.

These aren't crappy hash functions that are going to result in the O(n) worst case. In fact, I suspect that they're often better than hand-written hash functions because it's so easy to introduce error with this kind of fiddly nonsense.

operators and inheritance are ugly issues in C++.

Another win for Java (kind of)?

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

I'm sure I'd learn how to function quite well without red squigglies, but I'm quite confident that it saves me many minutes a day by informing me of an error or oversight as soon as it becomes an issue rather than further down the line. You just can't get the same level of granularity if you have to manually kick off the compiler any time you want to check for errors.

This isn't the only advantage to red squigglies, though. Since the java compiler gives more information than just the line number, the IDE can highlight just the problem area, which often helps make the underlying problem a little more obvious.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

Yuck. That seems like it'd throw many advantages that strong types provide out of the window. I'd much rather rely on my IDE to auto-infer the return type.

Code: [Select]

Thing thing1 = new Thing(new Stuff(1));
Thing thing2 = new Thing(new Stuff(1));

Would yield:

Code: [Select]

Stuff stuff = new Stuff(1);
Thing thing1 = new Thing(stuff);
Thing thing2 = new Thing(stuff);

I don't see much advantage in this "feature", do you? It seems something one would use purely out of laziness, but that's a problem the IDE should be able to take care of without throwing away all of the nice advantages type safety brings.

If the type of a variable is wrong, the IDE should be able to correct it for you. This comes up a lot, now that I think about it. I just cursor over the line with the error, press Alt-Enter, and there's an option to change the type of the variable. Same goes for return types of methods, parameters, etc.

[nslay]

Once you have a file open, it's given a tab like a browser tab. The problem is, once you have too many of those tabs open ... it's equally burdensome to find. I generally try to remember to close tabs when I'm finished when having to use Visual Studio, otherwise it's really annoying.

Right, but I need to find files that aren't open dozens of times a day. I assume this is the case with you too? Do you really have to poke through the entire source tree any time you want to open a new file?

This isn't really a problem in IntelliJ either. I just leave everything open and press Alt+E, which lists recently opened files. You can then type to filter the list and press enter to open it. I hate using the mouse for this kind of stuff, and I'm really happy that I'm provided with efficient ways to circumvent moving my hand those six inches.

There's no way VisualStudio doesn't have something similar to this. It's too obvious a feature.

I think with C++11, the future is very bright. All of <algorithm>, for example, becomes practicably useful with lambda expressions. Although, I have mixed feelings about the new template features (because people use templates to do unusual things that are hard to understand ... so-called template meta-programming).

Templates are always troublesome for Visual Studio to deal with (it almost never finds template definitions). It probably gets worse in C++11.

Sounds really awful. 

It's really not.

And the worst case complexity of hash map is O(n). For a balanced tree, the worst case complexity if O(log n). So if you pick a bad hash function, then a tree theoretically beats your hash map. If your application is performance-sensitive, you really should write your hash function by hand. A default hash function won't generally exploit the structure of your keys.

My impression is that you'd probably not notice a big difference using a TreeMap for casual use ... or if it's only a thousand elements, probably searching an array is substantially faster than either a hash map or a tree map despite having a theoretical complexity of O(n).

Not that any of this matters for casual use of containers ...

Right, but in practice -- even with these generated hash functions -- a HashMap is much more performant than a TreeMap. It's performance-sensitive in that it's nice if it finishes a little faster. The distribution of group sizes is very widely spread for most data sets. Most reducers will have groups with millions of entries in a group, for example.

Most types used as keys are simple compositions of primitives, so it's quite easy to generate a good hash function algorithmically. It follows widely accepted best practices laid out in Effective Java. If you have a field that isn't a primitive, you can just incorporate the value of that object's hashCode into the return value.

These aren't crappy hash functions that are going to result in the O(n) worst case. In fact, I suspect that they're often better than hand-written hash functions because it's so easy to introduce error with this kind of fiddly nonsense.

Fiddly non-sense? You know something about the key space: the distribution and the structure. You're throwing that information away. If you use it, it will almost certainly out-perform a one-size-fits-all solution. The fiddly non-sense is using a generic hash function for everything.

Of course, for casual use, none of this matters ...

operators and inheritance are ugly issues in C++.

Another win for Java (kind of)?

It's not that bad, Ctrl+F7 just compiles that one source file (rather than the whole project). You can't get away with this when writing templated classes and methods though ... and Visual Studio has a lot of trouble with templates so it always gives false alarms (or nothing). You usually have to wait until you can instantiate the class or method to see if it compiles.

I'm sure I'd learn how to function quite well without red squigglies, but I'm quite confident that it saves me many minutes a day by informing me of an error or oversight as soon as it becomes an issue rather than further down the line. You just can't get the same level of granularity if you have to manually kick off the compiler any time you want to check for errors.

This isn't the only advantage to red squigglies, though. Since the java compiler gives more information than just the line number, the IDE can highlight just the problem area, which often helps make the underlying problem a little more obvious.

I'm sure Visual Studio can do some of what you described. I just don't know how to use it well enough to do those tricks.

Regarding return types, in C++11, now you can do something like this (which I have mixed feelings about):

Code: [Select]

auto clThing = clOtherThing.DoSomething(); // Return type inferred automatically

clThing.DoSomething();

EDIT: Small English corrections.

Yuck. That seems like it'd throw many advantages that strong types provide out of the window. I'd much rather rely on my IDE to auto-infer the return type.

Code: [Select]

Thing thing1 = new Thing(new Stuff(1));
Thing thing2 = new Thing(new Stuff(1));

Would yield:

Code: [Select]

Stuff stuff = new Stuff(1);
Thing thing1 = new Thing(stuff);
Thing thing2 = new Thing(stuff);

I don't see much advantage in this "feature", do you? It seems something one would use purely out of laziness, but that's a problem the IDE should be able to take care of without throwing away all of the nice advantages type safety brings.

If the type of a variable is wrong, the IDE should be able to correct it for you. This comes up a lot, now that I think about it. I just cursor over the line with the error, press Alt-Enter, and there's an option to change the type of the variable. Same goes for return types of methods, parameters, etc.

The type is not lost at all. The compiler can infer the type from the return type of DoSomething(). C++11 is still a strongly typed language, it just makes more effective use of the compile-time type information.

[Sidoh]

It's really not.

It sounds really terrible, though. I'm not saying you can't work around it, but it just seems asinine that a developer would have to deal with any of that garbage. Seriously, I'd probably spend 10 extra minutes a day if I had to click through the source tree any time I wanted to open a new file. I generally have around 15k source files loaded. Sure, they're structured in a pretty sane hierarchy, but still: yuck.

The kinds of problems with C++ that you're listing are exactly what I hate about programming. I'd be so frustrated if I had to deal with that kind of crap on a daily basis. I suppose I'd get used to it pretty quickly, but I'd probably always be missing Java...

Fiddly non-sense? You know something about the key space: the distribution and the structure. You're throwing that information away. If you use it, it will almost certainly out-perform a one-size-fits-all solution. The fiddly non-sense is using a generic hash function for everything.

Of course, for casual use, none of this matters ...

It's not casual use, I assure you. There are certainly cases where it matters more to think about the hash function. I've been in that situation and dealt with it appropriately, I think. That being said, this doesn't come up often in contexts I'm very familiar with. Performance matters more than most things at my workplace, but tweaking a hash function is a lot less important than a dozen other optimization efforts. This is often the case with big data problems in general. Improving performance very rarely comes down to these kinds of small optimizations. It's almost always far more valuable to do things like: structure data to exploit sort order, avoid redundant reads over the data, and use approximation techniques like bloom filters and hyperloglog. These are all fairly obvious, of course, but it's pretty easy to introduce problems when working with high-level tools like Cascading.

A HashMap with an auto-generated hashCode is, in my experience, almost always more performant than a TreeMap with a manually constructed compareTo, so there's not really much to discuss on that front.

The type is not lost at all. The compiler can infer the type from the return type of DoSomething(). C++11 is still a strongly typed language, it just makes more effective use of the compile-time type information.

Right, I think that's why I said many of the advantages, and not all of the advantages. Maybe it's not much extra work for an IDE to find/refactor usages of a type under these circumstances, which is part of what I was worried about. It'd also be annoying if you were looking at some code that had one of these auto-inferred type variables where you cared to know what the type of said variable is. You just add an extra level of indirection... I guess the IDE could reveal that for you in place, but at that rate, you might as well just use the IDE to generate the actual type in the first place.

I guess I see some situations in which this might save a little bit of work, but not worth the nonsense, I think.

[Newby]

Not to interrupt you guys or anything, but I found that tmux literally transformed my life with shell productivity. I can argue that I am more productive with this than I am with an IDE, but I won't. I can't remember the last time I used an IDE.

[Falcon]

Not to interrupt you guys or anything, but I found that tmux literally transformed my life with shell productivity. I can argue that I am more productive with this than I am with an IDE, but I won't. I can't remember the last time I used an IDE.

Sounds a lot like screen.

[Newby]

Not to interrupt you guys or anything, but I found that tmux literally transformed my life with shell productivity. I can argue that I am more productive with this than I am with an IDE, but I won't. I can't remember the last time I used an IDE.

Sounds a lot like screen.

That's what I said. Then I discovered the pane feature. Juggling multiple shell sessions has never been the same. IT'S SO FUCKING SIMPLE AND EASY that it sometimes scares me.

[Sidoh]

I've been meaning to give tmux a try, Newby. I'm quite sure it would never replace an IDE, but it sounds like it'll enrich my terminal experience

[Sidoh]

tmux is pretty cool. definitely awesome to have a way to persist terminal layouts.

Newby, do you have any experience with setting up SSH sessions in tmux? I generally have four servers I want open connections with. Unfortunately, I have to use sudo to switch users, so I need to enter my password. I'm not super pleased with my solution, but it works. Any ideas?

[Newby]

Newby, do you have any experience with setting up SSH sessions in tmux? I generally have four servers I want open connections with. Unfortunately, I have to use sudo to switch users, so I need to enter my password. I'm not super pleased with my solution, but it works. Any ideas?

I work with a couple dozen or so servers on the daily. A properly configured config file (in ~/.ssh) is necessary. Not sure what you're getting at with sudo-to-switch-users, you can NOPASSWD sudo for your account or you can put the key in the ~/.ssh/authorized_keys account of the account you want to log in as.

Code: [Select]

$ grep -A 4 whatever.you.want.to.ssh.to ~/.ssh/psuedoconfig
Host whatever.you.want.to.ssh.to
    HostName full.hostname.here
    Port xx
    IdentityFile /path/to/private/key
    User blah
$ ssh whatever.you.want.to.ssh.to

Bam, you're logged in as blah on full.hostname.here with no password intervention. You can even have entries that are the same but with a different identity/username, if you want. I haven't tried it, but I log in as me and don't mind sudo'ing around as I type 140+ wpm... I generally re-type commands/words if I make a typo, it's just faster. So typing "sudo su username -l" and my password? Not a biggie.

I also took it one step further and aliased these.

Code: [Select]

$ alias fullshell='ssh full.hostname.here '
So I can do things like

Code: [Select]

$ fullshell (instantly logged in)
$ fullshell uname -a (runs uname -a on full.hostname.here, returns it)
And other shorthand conventions which are super useful in mass:

Code: [Select]

for host in hostone hosttwo hostthree hostfour; do ssh $host -- <some remote command i want to run on everything>; done