Re: About C++ IDEs



Michael Viking <TheViking@xxxxxxxxx> wrote:
"Hendrik Schober" <SpamTrap@xxxxxx> wrote in message
news:uiYkX1ezHHA.4824@xxxxxxxxxxxxxxxxxxxxxxx
Michael Viking <TheViking@xxxxxxxxx> wrote:
<SNIP>
If I throw a ball away from me at 45 degrees it rises and then falls. It's
a parabola. Maybe I consider VC6 to be the peak of the IDE?


VC6 is more than an IDE and I didn't talk about the IDE.
You specifically said "C++ tools". I like the newer IDEs
better, but I agree that VS6 was very snappy. But its C++
compiler was a PITA and we were very happy when VC7.1
came along.

The compiler in VC6 is fine. It's not optimal, it's not best, but it's
fine.

That depends on what you do. It's almost ten years old
and disregards standard C++ in many critical areas. IME,
as soon as the keyword 'template' appeared somewhere,
VC6 caused trouble.

The proof is all the applications that were developed with it.

LOL! This is "proof" that (ancient) BASIC was a fine
language.

[...]
For one, in order to use techniques that make your
code safer, you will need a compiler that supports
those techniques. Try to use boost with VC6.
Also, VC6 was seriously lacking when it comes to
its std lib.
Finally, if your code needs to get compiled on
several compilers, VC6 is a major PITA. It chokes
on what every other compiler happily compiles and
eats lots of erronous code at the same time.
You keep being locked into that for 9 years now,
just putting off the work to migrate that to a
compliant compiler/std lib pair.

I agree that some people have this issue. We don't. We don't need to
compile code on several compilers, and I bet that few do.

(You avoided adressing the other two points.)

I'm not sure which points I missed, so I'll try to address each one. We
don't use Boost. Some do, but I'd guess that most don't?

I have no idea why one wouldn't want to use a box
full of tools as boost is. But even if -- it didn't
take boost to make VC6 choke. It couldn't even keep
up with /my/ template code (and that was long before
I got my nose into template meta stuff).
It prevented us from doing things in better, safer,
and more efficient ways.

We use very
little of the std lib, and it's not hard to repair the issues we come
across, since they're just header files. [...]


Oh boy.

Maybe we're
putting off work, but so far so good. We sure didn't get fooled like some
people doing the work to go to 2003, and then more work to 2005.

We neither, BTW. 2003 was a great improvement (due to
its fixed C++ compiler) and we happily switched. 2005
was a customer's requirement and it was an easy switch,
so nobody complained.

It's my understanding that quite a few people got burned here trying to use
C++/CLI or whatever it was.

<shrug>
I wouldn't know.
Still, this has nothing to do with any of my points.

[...]
We still use VC6 because the compiler works fine for us and the IDE rocks.

What's wrong with C or even assembler? Worked
fine, too, editors were snappy on a 286, and
people wrote operating systems, IDEs, office
applications and what not using these. SCNR

Again. I think of it as a parabola. Sure I could do those things, and
because I can it makes me better at what I do now. But those are "too close
to the metal" in most cases - but we do have assembly in our code. At some
point one is abstracted so far away from what's going on that it's too far.

Right. And where the point inbetween is, that is a
personal preference. So yours isn't better or worse
just because you feel it's right.
For me using libraries like boost and applying some
modern template techniques (that shift work to compile-
time, thus making the code faster at run-time and
making more fail at compile-time instead of run-time)
is a necessary abstraction, and dealing with raw
pointers etc. is too close to the metal and a last
century's way of doing things.

These are valid. For the size of our dev team and what we need to do, we
don't feel moving to the compiler, making these changes, etc. is a tradeoff
we want to make. If you have the time and resources, that's great.


There's about half a dozen developers working on
the projects I work on. Not all of them work on
Windows, though. As a small company that ships
software to some very big companies, we know how
brutal deadlines can be.
We see it the other way around: We can't afford
to not to use technologies that save time and
make our code more stable.

[...]
And from what I've seen of people we've
interviewed, the ones who could write in C and assembler and understand that
Win SDK and know what they're doing are a heck of a lot better than the
people who can put together some sort of UI with the latest .NET and that's
all they know. Reality is these people don't know much of anything, and if
they do have some kind of problem, it's abstracted away to where they can't
understand or debug it.

In my youth[TM] I heard the same about people not doing
assembler.

I honestly don't know what you're saying here. [...]

When I was young, I was told that those who only
write code in high-level languages and don't do
assembler don't know much of anything. Since most
applications today are not written in assembler,
but in some higher-level language, and since that
wouldn't be possible if the overwhelming majority
of those making them where morons, I have to
conclude that this statement was wrong.
Now you say those who only write .NET stuff and
don't know the much about the Win32 API don't know
much of anything. I compare that statement with my
experience with similar statements and don't see
much value in it.
(BTW, while I write most of my code on Windows, 95%
of the code I write nowadays runs on quite a few
platforms. Therefor I write plain and portable std
C++ and almost never use the Win32 API at all --
and thus know very little about it. Your above
statement paints me as not knowing much of anything.)

-Michael Viking

Schobi

--
SpamTrap@xxxxxx is never read
I'm HSchober at gmx dot de
"If there were some arcane way to remove the heads of every
newsgroup troll on the planet, I think it would elevate
humans to a whole new level of intelligence."
Rocky Frisco


.



Relevant Pages

  • Re: Problems with GetOpenFileName and GetSaveFileName
    ... > OK I've tested your program with VC6 SP6. ... what version of the Platform SDK are you using? ... even offered them free upgrades to 98SE but they didn't go for it). ... > SDK installed and available to the VC compiler.. ...
    (microsoft.public.win32.programmer.ui)
  • Re: fatal error LNK1103: Debug-Informationen beschaedigt
    ... Der Compiler ist so mies gegen alle seine Nachfolge, dass ich jedes Beharren darauf als nicht gerechtfertigt ansehe. ... Das ist meine ganz persönliche Meinung, die alle meine Entwicklerkolegen bei mir in der Firma jedoch alle teilen. ... Zudem sind die Flyouts noch platzsparender und erlauben noch mehr vom Code zu sehen! ... Ich arbeite zwar produktiv immer noch mit VS2003 aber jedesmal wenn ich mit VC6 noch irgendeinen Legacy Kram bei uns pflegen muss treibt mich der Compiler zu Wahnsinn... ...
    (microsoft.public.de.vc)
  • Re: About C++ IDEs
    ... Eberhard Schefold wrote: ... The compiler and library may be hopelessly outdated, but the VC6 ... IDE has one major thing going for it: it doesn't suck in quite the way ...
    (microsoft.public.dotnet.languages.vc)
  • Re: About C++ IDEs
    ... VC6 is more than an IDE and I didn't talk about the IDE. ... The compiler in VC6 is fine. ... What's wrong with C or even assembler? ...
    (microsoft.public.dotnet.languages.vc)
  • Re: performance , speed and portability of VC++.NET and VC++ 6.0
    ... VC6 is non-compliant in many many areas, ... Each compiler has generally seen optimizer improvements as well, ... In my experience, those are users that are heavily invested in MFC, ... which has much better IDE support in VC6 than in the later versions. ...
    (microsoft.public.dotnet.languages.vc)

Loading