Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[psyn]

GDB can do it too, but the kicker is, I don't have to run my applications under the VS debugger all the time to take advantage of crash investigation. I would need to do so with GDB under Windows, as it lacks this ability (Windows doesn't do core dumps, at least not in a way GDB can understand).

GDB could just as easily set this up at runtime.

Could, but doesn't, and doesn't have the ability to do so wrt MDMPs either as far as I know.

Ah, okay. I didn't know that. Believe it or not, I have never tried to run GDB inside Windows. Seems... backwards.

[Blacken]

I can believe it. Because using GCC on Windows is backwards. It's unsuitable to the task. (Trying to integrate GCC-compiled code with VS-compiled code is...Fun.)

[qwertyuiopas]

How is it unsuitable?

Because MSVC can't compile

Code: [Select]

int main()
{
    int a(){return 3;}
    return a();
}?

Or maybe because you can invoke GCC with

Code: [Select]

gcc *.cand furthermore put it in a batch file, for double-click compiling?

Because you don't have to navigate a sub-menu of an options window of a properties page to add a new library file?

Because you must register with microsoft for prolonged use of the free version?

Because all examples for it will work unaltered or with freely available libraries, while MSVC examples routinely use mfc and atl, both unavailable in the express editions since 2005 or so(Didn't check the MSV* varsion, but they dropped support before visual studio 2008)?

Yes, I can see how you can have problems merging compiled code between compilers when they use C++, since few implementations are compatible, so you would have similar problems when working with C++ code across ANY different compiler implementations.
(reference, though far from the whole problem)
The fact that you conveniently focused the problem as "GCC is inferior to MSVC", win in reality it is "MSVC, GCC, and practically any other compiler produce incompatible compiled C++" *really* shows how mature and knowledgable you are, since you don't have to resort to only telling half-truths by conveniently only mentioning one small facet of an issue that is somewhat less than well known, in hopes that others don't understand...

Warning: Continued use of MSVC relies on microsoft not to cancel or further limit the express editions, or requires you to pay them despite the face that they may release the full tool for free at any time.
Warning: Continued use of GCC relies on a microsoft monopoly to never take full effect, followed by a microsoft initiative to ensure that no other compilers are available.

Oh, and surely you might have had problems getting MSVC to compile some of the many GCC C extensions or GCC C++ extensions

Especially since MSVC doesn't seem to have an easily googled list, so it can be assumed that it doesn't have anything optional or extra. (-pedantic can be used to warn you if GCC finds any of these non-standard extensions...)

[Blacken]

Because MSVC can't compile

Irrelevant, because that isn't legal Standard C or C++. It is an illegal lexical pattern that a conformant compiler will disallow. If you want to define a function within another function you can use the Functor design pattern, but it's bad practice anyway to do so inside a function; if you did it in a professional environment with capable developers you would be asked what the hell you were thinking.

You are, once again, wrong.

Or maybe because you can invoke GCC with
gcc *.c
and furthermore put it in a batch file, for double-click compiling?

Hot damn, it's like I don't have nmake or cl or link sitting in %PROGRAM_FILES%\%VS9%\VC\bin!

For the denser sort, here's a translation: you can do exactly that with MSVC, too.

You are, once again, wrong. But you're doubly so, because not only can you do it, it's idiotic to trumpet that as being a net benefit on the Windows platform.

Because you don't have to navigate a sub-menu of an options window of a properties page to add a new library file?

No, I don't. That you don't know how to effectively use a set of tools is not my problem.

Because you must register with microsoft for prolonged use of the free version?

Yeah, free registrations are so onerous and terrible and oh wait it takes quite literally 30 seconds.

Because all examples for it will work unaltered or with freely available libraries, while MSVC examples routinely use mfc and atl, both unavailable in the express editions since 2005 or so(Didn't check the MSV* varsion, but they dropped support before visual studio 2008)?

Nonsense. Examples related to MFC or ATL use MFC or ATL. Others do not.

You are, once again, wrong.

The fact that you conveniently focused the problem as "GCC is inferior to MSVC", win in reality it is "MSVC, GCC, and practically any other compiler produce incompatible compiled C++" *really* shows how mature and knowledgable you are, since you don't have to resort to only telling half-truths by conveniently only mentioning one small facet of an issue that is somewhat less than well known, in hopes that others don't understand...

This is top-to-bottom, manifestly wrong. Can you read? No, seriously. Can you read? Are you capable of actually understanding what is written?

GCC is inferior on Windows. It is a platform designed for using MSVC. Other systems are going to be inferior to the integrated solution. You, my intellectually dishonest and deficient punching bag, are mischaracterizing what I say either because you cannot process it, or because you are unwilling to admit that you might actually be--and I know this is a shocker--arguing an untenable position.

"Oh hurr my minor and entirely irrelevant points show how knowledgable [sic] you really are!" Please. If you can't present a coherent case, don't try to respond at all.

You are...once again...wrong.

Warning: Continued use of MSVC relies on microsoft not to cancel or further limit the express editions,

Fearmongering. Stupid fearmongering, too; it's far more likely that DevDiv's full development suite (which only makes about a billion dollars in revenue per year) will be turned into freely available software.

or requires you to pay them despite the face that they may release the full tool for free at any time.

And you benefitted in the meantime. Not relevant. (That, and VS2008 is already free for damned near any individuals who'd want it. If you can't find a free, legal version of VS2008 Professional you aren't looking very hard.)

Oh, and surely you might have had problems getting MSVC to compile some of the many GCC C extensions or GCC C++ extensions

...Yes. Because they are nonstandard extensions. Irrelevant.

Especially since MSVC doesn't seem to have an easily googled list, so it can be assumed that it doesn't have anything optional or extra. (-pedantic can be used to warn you if GCC finds any of these non-standard extensions...)

This just in: a standard compiler doesn't add things that aren't part of the standard. Irrelevant.

Shocker.




Look. Your high school classes have clearly not prepared you for sane, cogent discussion about technical topics, and you aren't exactly doing a good job of showing any meaningful domain-specific knowledge of your own; what you keep bringing up is freshly Googled fearmongering garbage that you aren't capable of interpreting. You don't know enough to know that it has no reasonable bearing on the point you want to drive. Why don't you just admit that you don't have a case and sit down, shut up, and learn from people who do know what they're talking about?

I mean, for the love of God. You're a high-schooler who's still in the "OH GOD FREE SOFTWARE IS BETTER THAN SEX" phase. There's a possibility that, someday, you might have the experience and knowledge to be able to analyze a situation without the hysteria and foolish partisanship you insist on employing now. You can't now. Stop.

[qwertyuiopas]

What, compilers must adhere to a standard and *never* contain optional enhancements that improve ease of use, simply because they aren't standard? Wow, it's like you never considered that if all OSes were made to a standard, then no OS would be any better than any other!

Simple, realy. The compiler must adhere to the standards, however there is nothing that explicitly denies a compiler from adding optional functionality.

// style comments in pure C code? How dare they! And in this case, they includes nearly every compiler, since no sane compiler would stubbornly deny a feature that is so often used elsewhere, simply because they must comply with an older standard and deny all intellegent features.

So, with // comments being a nonstandard feature that exists everywhere, how can you argue that a compiler may not add other, code-related, optional improvements when it is of universal benefit to programmers using it, in an attempt to become clearly better than the alternatives? Surely you don't think that redesigning the core parser to produce faster code is denied because it no longer uses the standard method but it's output has the same results?

Now, GCC has an aadded advantage, as it can be used on most or all recent OSs, so if a feature is added to it, the code using that feature will compile on any OS with a recently updated copy of GCC.
Oh, and *gasp*

Code: [Select]

#pragma onceis non-standard.

In the C and C++ programming languages, #pragma once is a non-standard but widely supported preprocessor directive

Non-standard, and yet widely supported? If the first compiler to allow that #pragma listened to your advice, nobody would have ever been the irst, and it could have never reached that point of being widely supported where it doesn't matter if it is non-standard!

it is not necessary for the programmer to create new macro names such as GRANDFATHER_H in the Include guard article's example. This eliminates the risk of name clashes, meaning that no header file can fail to be included at least once. It also requires less typing than the include guard method.

Non-standard, saves typing, more accurate than the alternative, eliminates naming clashes?

And yet, non-standard?

How could you even think to allow it to even exist, if it isn't standard??

(Note: GCC will comply specificaly with the ISO C standard with -ansi, but that is *optional*, just like any non-standard functionality need not be used)

[Blacken]

Look closely, folks. See the dodge? See how, when he is line-by-line fisked and shown to be wrong in aggregate, he tries to shift to another tack? It's really quite good--well, "good" by his standards, not so much by those of basic honesty. Instead of saying "you know what? I was wrong," he instead attempts to attack something only peripherally related. And, in the process, does his damndest to rewrite what has gone before in an attempt to make himself look better. Not to, y'know, be intellectually honest and represent a coherent point--but because he's got to win. Being right has nothing to do with it--he's got to win.

psyn and I have been dumb enough to let him get away with shifting the topic so he is not forced to stick to his sinking ship. But see how now he's hyperfocusing on the most minute little point and expanding it (incorrectly) in an attempt to draw some kind of "haw haw, I win" out of this?

Marvelous. It doesn't work, and works even less when somebody calls him out, but it's vastly entertaining to watch.

What, compilers must adhere to a standard and *never* contain optional enhancements that improve ease of use, simply because they aren't standard? Wow, it's like you never considered that if all OSes were made to a standard, then no OS would be any better than any other!

They're perfectly welcome to add non-standard extensions (some of GCC's are dubiously termed "enhancements", but I digress). You cannot in any sort of intellectually honest way fault others for not including them. But you left intellectual honesty behind some time ago.

Simple, realy. The compiler must adhere to the standards, however there is nothing that explicitly denies a compiler from adding optional functionality.

Except good sense to not break compatibility. Extensions, whether they're GCC or otherwise, are relatively rarely used in production C/C++ environments, because they cannot be relied on to exist everywhere. You can use them in your little hobby projects to your heart's content, but you cannot in good faith complain that they do not exist elsewhere, because they are not binding to the standard.

// style comments in pure C code? How dare they! And in this case, they includes nearly every compiler, since no sane compiler would stubbornly deny a feature that is so often used elsewhere, simply because they must comply with an older standard and deny all intellegent features.

Psst. I know you think you're real hard and all, but one-line comments are legal Standard C.

So, with // comments being a nonstandard feature that exists everywhere,

They're not. Fail less.

how can you argue that a compiler may not add other, code-related, optional improvements when it is of universal benefit to programmers using it, in an attempt to become clearly better than the alternatives? Surely you don't think that redesigning the core parser to produce faster code is denied because it no longer uses the standard method but it's output has the same results?

Internal optimizations of the compiler itself? That has nothing to do with a code standard. Do you even know what a standard is? At this point I honestly have my doubts if you're capable of drawing the distinctions necessary to actually answer "yes" to that.

Now, GCC has an aadded advantage, as it can be used on most or all recent OSs, so if a feature is added to it, the code using that feature will compile on any OS with a recently updated copy of GCC.

Unless they're architecture-specific, as a number of them are (typeinfo in GCC 2 and, I think, GCC 3 provided different name resolutions on ARM than on x86), of course. But that doesn't mean all that much, now, does it, when the compiler does not play nicely with everything else on the platform? You know, like GCC on Windows?

Oh, and *gasp*

Code: [Select]

#pragma onceis non-standard.

In the C and C++ programming languages, #pragma once is a non-standard but widely supported preprocessor directive

Non-standard, and yet widely supported? If the first compiler to allow that #pragma listened to your advice, nobody would have ever been the irst, and it could have never reached that point of being widely supported where it doesn't matter if it is non-standard!

it is not necessary for the programmer to create new macro names such as GRANDFATHER_H in the Include guard article's example. This eliminates the risk of name clashes, meaning that no header file can fail to be included at least once. It also requires less typing than the include guard method.

Non-standard, saves typing, more accurate than the alternative, eliminates naming clashes?

And yet, non-standard?

How could you even think to allow it to even exist, if it isn't standard??

Is this supposed to be a compelling argument? You're intentionally mischaracterizing my position. Once more: you cannot fault a toolset for refraining from picking up arbitrary extensions not included inthe standard. Not that you cannot extend it. Argue honestly or shut up.

This is absolutely pathetic on your part. You aren't even capable of reading to actually respond to what I actually say. You instead invent things to argue against (I'll note that this is the third time you've changed the topic when either psyn or I made you look foolish--in this thread alone). Unless you can carry on a sane conversation without fleeing to rant about something else when you're proven wrong, I'm done with you.

[psyn]

This thread turned from face-palm embarrassment to classic hilarity in an instant.

BTW, excellent posts, Blacken. I don't have much to add, but maybe it will help a little.

Because MSVC can't compile

Irrelevant, because that isn't legal Standard C or C++. It is an illegal lexical pattern that a conformant compiler will disallow. If you want to define a function within another function you can use the Functor design pattern, but it's bad practice anyway to do so inside a function; if you did it in a professional environment with capable developers you would be asked what the hell you were thinking.

You are, once again, wrong.

Yep. Also, see anonymous namespace method, boost::lambda, and C++0x's lambda. Anyone checking in code using a local nested function would be grounds for immediate termination... or public seppuku.

Or maybe because you can invoke GCC with
gcc *.c
and furthermore put it in a batch file, for double-click compiling?

Hot damn, it's like I don't have nmake or cl or link sitting in %PROGRAM_FILES%\%VS9%\VC\bin!

For the denser sort, here's a translation: you can do exactly that with MSVC, too.

Again, truth. Listen to him. And you can change the compiler setting inside MSVC. We use the Intel compiler. GCC and Clang could also be used.

Because all examples for it will work unaltered or with freely available libraries, while MSVC examples routinely use mfc and atl, both unavailable in the express editions since 2005 or so(Didn't check the MSV* varsion, but they dropped support before visual studio 2008)?

1. MFC has been discouraged for over six years. It sucked for years before that. Buy VC Standard Edition if you need MFC -- only companies with legacy code need MFC support.

2. Do your old KDE3 examples work under KDE4? I didn't think so.

Yes, I can see how you can have problems merging compiled code between compilers when they use C++, since few implementations are compatible, so you would have similar problems when working with C++ code across ANY different compiler implementations.

Hey, you deserve praise. You made one accurate criticism in your entire post. Yes, ABI compatibility sucks. Yes, cross-compiler C++ runtime conflicts sucks. Welcome to plugin hell. It sucks.

Oh, and surely you might have had problems getting MSVC to compile some of the many GCC C extensions or GCC C++ extensions

What, compilers must adhere to a standard and *never* contain optional enhancements that improve ease of use, simply because they aren't standard? Wow, it's like you never considered that if all OSes were made to a standard, then no OS would be any better than any other!

Simple, realy. The compiler must adhere to the standards, however there is nothing that explicitly denies a compiler from adding optional functionality.

No person writing cross-platform C++ code uses these extensions. On rare occasion, when some missing functionality is required, like __attribute__, it is placed inside a platform #ifdef.

Especially since MSVC doesn't seem to have an easily googled list, so it can be assumed that it doesn't have anything optional or extra. (-pedantic can be used to warn you if GCC finds any of these non-standard extensions...)

Link. I will use Boost and C++0x, thanks.

Oh, and *gasp*

Code: [Select]

#pragma onceis non-standard.

#pragma once directive is not generally used in production code without accompanying include guards. It wasn't that long ago when it was unsupported. Modules were widely hoped to make it into the next C++ standard, anyway.

Non-standard, saves typing, more accurate than the alternative, eliminates naming clashes?

And yet, non-standard?

How could you even think to allow it to even exist, if it isn't standard??

If only you put this excitement of yours to more productive means. Few extensions are cross-compiler compatible. #pragma once is... and thus, it is sometimes used. C++'s compilation model is its worst feature, so its acceptance shouldn't be surprising.

So, with // comments being a nonstandard feature that exists everywhere,

They're not. Fail less.

I don't even program in C, and I knew of C99's comment addition. Jeez.

[Blacken]

Hey, you deserve praise. You made one accurate criticism in your entire post. Yes, ABI compatibility sucks. Yes, cross-compiler C++ runtime conflicts sucks. Welcome to plugin hell. It sucks.

The funny part is that he's asserting that it's a flaw across "all" compilers...when he's trumpeting the glories of the one that isn't compatible with pretty much everything on the platform. It certainly does suck...but his advocacy is for something that increases, rather than decreases, the suck.

[qwertyuiopas]

What, are psyb and Blacken two accounts from the same person?

Let me tell you something:
When you argue, you both seem to quote an entire post, and feed it line by line into a program that finds subtlly flawed arguments against each one.

When I argue, I just pick out a few arguments, because anything more would result in exponential growth until the post length limit is reached.

So, no, when I don't respond to all of your arrogant babble, it isn't because I can't, but because I respect the others reading this.


Also, if you ever had to program for a non-windows platform, you would probably prefer MSVC even if it were somewhat worse that GCC on that platform. MinGW, however is GCC designed for windows, so I am highly sceptical of any argument claiming that it is far worse than MSVC.

[Helmaroc]

[Renault]

If such a thing existed, I would hail its inventor as the savior of the internet, even as I panned her as a killjoy.

[Maldevious]

I can take solace in the fact that I have absolutely no idea what the argument in this thread is all about. Thanks for all the suggestions, very helpful to me when setting up my fresh install due to new hard drive.

[DrPizza]

Once again, you blindly misinterpret my arguments to make yours seem plausible. I was arguing about programs that alter the OS for advanced features. Example, that exact debugger you were claiming was so great.

First, it either must already be running, or it must be started when any program crashes, consuming RAM. Considering current trends care more for startup time, advanced features, and disregard excessive RAM usage, it likely starts when windows does.

Educate yourself. Windows has a built-in facility to fire up a debugger on JIT basis when a program crashes (configured through the AeDebug registry key).

Additionally, the extra code to allow it to integrate with the OS does *not*, under *any* circumstance, make the program *smaller*.

You know what the "extra code" is? It's the ability to fire up and attach to a process identified by the PID passed on the command-line. That's it. And you know what? Any decent debugger will already have that capability. That's how much "extra code" we're talking here. NONE.