Thread: IDE liking

Take it easy. I forgive you, and I am sure the others do, as well.

i forgive you too.

For those that exist on only one platform it can be an easy thing to become enamored with an IDE for that platform. When you job depends on your being fluent on multiple platforms (Mac, Linux, Windows) an IDE that only exists on one and a flavor of language that exists only on one become roadblocks to productivity and you learn to get good with tools and language elements that exist on all platforms, discarding language extensions and tools that are platform-specific as superfluous. I started as an IDE fan (well when they came along; my first "IDE" was a machine language monitor) but as I have grown in this business I find that I need tools that travel well and frankly VS doesn't. I understand MK's comments about being capable at the command line; it has been an essential part of every job I have had for the past ten years. For me, knowing Emacs/XEmacs which serves as a debugger, builder and editor, works the same on Windows, Mac and Linux is the answer that serves every language I need to code for (C/C++/Java/Python). Note that I said: "For me".

At the end of the day it is whatever makes you the most productive; if something with intellisense helps you remember your API calls for example, so be it. If on the other hand something like that feels like it is getting in the way, then it is an impediment to productivity and should either be fixed or not used.

my first "IDE" was a machine language monitor)

There are 3 applications I could count as my first IDE.

I will go with LogoWriter 2.0, since that's the first language I learned. That may or may not be considered an IDE.

Another possible qualifier is QBasic (I don't think I ned to post a picture for that one). Once again, that may or may not be considered an IDE.

Finally, there is Borland C++ 5.02. My first C++ IDE. Even to this day there's a lot of things about it that I prefer over some other IDEs. It was a nice IDE in its day.

I find that I need tools that travel well and frankly VS doesn't

This depends what you use VS for. Frankly, I agree with you to some extent...I rarely use Visual Studio for any application that I plan on building on Linux or Mac, but that doesn't meant you can't. As many people have stated already in this thread, you most certainly can write standard C++ (or even C# for that matter) in Visual Studio, and it will compile just fine on Linux or Mac. It's simply a matter of adhering to standards.

Of course, that doesn't change the fact that if you did use VS for such a purpose, you'd be forced to relocate to a different IDE and/or make a makefile when compiling for another platform, thus reducing some of its usefulness.


Slightly off topic but related:

I am hoping that C# gains a larger foothold in the Linux and Mac environments (with respect to Java, not necessarily with respect to C++). I don't say this in a pro-Microsoft sense, but just simply because I believe C# as a language is much more elegant, expressive, and easy to use than Java.

Originally Posted by DavidP

This depends what you use VS for. Frankly, I agree with you to some extent...I rarely use Visual Studio for any application that I plan on building on Linux or Mac, but that doesn't meant you can't. As many people have stated already in this thread, you most certainly can write standard C++ (or even C# for that matter) in Visual Studio, and it will compile just fine on Linux or Mac. It's simply a matter of adhering to standards.

Sure, but if you are using platform specific libraries, which is pretty normal, then you are out of luck.

Sorry, but it sounds like you do not know why max and min pose the problem that they do. The problem is that <windows.h> defines macros named max and min that can conflict with std::max and std::min from <algorithm>. Now, a particular library implementation bundled with a compiler might provide a version of <windows.h> with a workaround for this problem, but this has little to do with the compiler per se, and even less to do with the IDE.

The problem extends far beyond min and max. SendMessage() is defined as SendMessageA() in the global namespace in windows.h so any code you write that has a function called SendMessage() regardless of namespace 'scope' (namespace or class) will conflict with SendMessageA().

There are actually a whole host of defines in windows.h that essentially pollute the global namespace and cause these types of conflicts far more often than one might think. Seriously, though, who at Microsoft felt SendMessage() was specific enough to cram into the global namespace and cause all kinds of problems?

I forgive your statements Sipher but you have not taken responsiblity for your false information. It is your job to take false information and disseminate it for what it is. Just saying that you are repeating this or that website or forum and using that as an excuse for your ignorant statements is just passing the buck if you ask me.

No one who has ever used Visual Studio would believe your statements. The primary IDE and compiler used to compile DirectX and Direct3D applications is Visual Studio. Direct3D and DirectX are APIs that have export libs to link with and headers to include. They have very little to do with the compiler or the IDE. The shader debugging option in 2003 has been removed in 2005 and 2008 and replaced with PIX which is far superior anyways. Your statements about DirectX also don't make any sense from a pure C++ linking standpoint so I'm not sure how you even believed any of what you 'read' or how any one in their right mind on a forum would even make such a statement. Pure ignorance. Open mouth, insert foot.

Seriously, though, who at Microsoft felt SendMessage() was specific enough to cram into the global namespace and cause all kinds of problems?

It was probably back in the day when hardly anyone knew what a namespace was. Seriously...they've only been around since the latter mid to late 90s as far as I know. And they really only gained popular use in the last decade.

Obviously MS couldn't use namespaces in their headers because it's a C++ and C API.

Originally Posted by maxorator

Obviously MS couldn't use namespaces in their headers because it's a C++ and C API.

Think about what you are saying; a namespace is simply a scope of visibility of names of things; the "global" namespace has been around forever, regardless of language; these were just known as the much-hated global variables and functions....

Originally Posted by jeffcobb

Think about what you are saying; a namespace is simply a scope of visibility of names of things; the "global" namespace has been around forever, regardless of language; these were just known as the much-hated global variables and functions....

I was talking about the C++ namespace, not the general concept. But yes, they could've used some prefix like in DDK.

If min and max were functions, they could be put into namespaces to avoid collision.
But otherwise namespaces wouldn't help very much, would they? There is no safe way to "rename" a function in C++, which is mostly what they've used their macros for. Was there a specific way namespaces could help in which you were referring to?

Originally Posted by maxorator

Obviously MS couldn't use namespaces in their headers because it's a C++ and C API.

Couldn't they have done something like:

Code:

#ifdef __cplusplus
namespace whatever {
#endif
// put header here.
#ifdef __cplusplus
}
#endif

But why they created macros named min & max, I have no idea. Shouldn't macros be in all upper-case? That confused the hell out of me the first time I ran into that problem and had to do #undef min before I could use the std::min() function.

Originally Posted by Bubba

In MSVS you can just put NO_MIN_MAX in the the preprocessor section of your project settings rather than use #undef.

Then you'd be relying on that always being in the preprocessor section of the project settings. If you lose the project settings or switch to a different compiler, you'll get the error again. If you put the #undef in the source file you won't have to worry about it happening again (and newbies reading your code long after you're gone can learn about that problem with the windows header file -- and hopefully you commented why the #undef is there).