What is 'visual' about visual c++

[Aaron Bourgoin]

Can anyone tell me where the visual comes into play in Microsft's visual c++. I've been working through tutorials form MS and others and have yet to see anything that I would consider visual except for flowcharts in the books and these appear to have been prepared to explain things like loops, not actually code them.

Was I really wrong to think that this was the way one was able to "code", even part of the application using iconic objects?.

signed, the real newbie! (hey, I got my developer id!)

using microsoft visual c++ .net (standard edition)

[Anonymous]

In the beggining we have ANSI C (++)
Just for console applications.
There was a need for writing applicatio for windows with VISUAL feedback.
So we had the C SDK tooklit and few year later we had Visual C++.
Just a collection of an objects hierachy to provide the tools to make VISUAL objects on the screen. Nothing visual in programming terms.

[TomWaltz]

Next to nothing.

Microsoft just likes to make things sound better than they really are. They also like to bundle things together. Anything that comes with Visual Basic is now part of the "visual" series.

Visual C++, Visual J#, and other b@st@rdizations of real languages abound.

Just the same, there is little object-oriented code in the Archicad API. As Karl pointed out to me long ago, it may look like C++, but it's a not true object-oriented system.

[Karl Ottenstein]

In spite of marketing hype, there is some 'visual' aspect at least with respect to resouces, such as dialogs. The dialog editor lets you drag and drop controls and modify their position and properties visually and via the property inspector, for example. But, this is of no use to an AC API programmer since these dialogs are Windows-specific and we have to use the very non-visual GS DG format to produce cross-platform dialogs.

I would argue that 'IntelliSense' is a highly useful and visual (even if not graphic) feature ... providing available class members, syntax, etc at just the right place as you enter code.

And, for old timers, many other things about the interface and assemblage of files into a project seems visual compared to the old days of having to manage configuration and make files manually.

But, yeah, it's hardly visual/graphic programming!

Karl

[Aaron Bourgoin]

Karl,

I think the visual bit in the old days was the visual inspection of chads on the punch cards.

Come Novemebr, everything old is new again!

[Karl Ottenstein]

Aaron wrote:
I think the visual bit in the old days was the visual inspection of chads on the punch cards.

Come November, everything old is new again!

Except of course where the new electronic machines have no paper receipts or paper trail to allow for auditing.

[Aaron Bourgoin]

We voted in civic elections this week. The ballot was an 8.5x1111 sheet of paper and was fed into a voting machine that looked an awful lot like a paper shredder and I couldn't help but wonder.

Amazingly, the two frontrunners lost to the candidate who had been expected to place 3rd. None of the candidates were named Chad.

[stefan]

I think Karl is right: it's more the IDE, the classwizards, the resource editor (dialogs, icons, menu's) that are visual: you see the resource-code inside an interface, instead of directly as a *.rc-file with plain text.

Intellisense, code completion, syntax coloring, project/solution trees, classview, ...
that all helps and is more or less visual, when compared to just a text-editor approach of makefiles.

[Aaron Bourgoin]

#include <iostream>

int main ()
{
std::cout << "Thank you all for your replies! \n";
return 0;
}

[TomWaltz]

Code completion and syntax coloring are present on most modern IDE's, like XCode, CodeWarrior, and (I think) Borland.