--
Ma...@mWilden.com
John Parchem <jpar...@mcs.com> wrote in article
<01bc1704$da2b2560$d2bf03c7@oasis2>...
- Pancrace
--
O Shema Yishrael, Adonoi Elohenu, Adonoi Echad
Qodoish, Qodoish, Qodoish, Adonoi Tsabayoth
M'lo Kol Ha'Aritz K'vodu
:
:
:
I wonder if my news reader is out of order cause the message title was:
"Will VB5 start killing off Visual C++ ?" (sic)
Well, after Mark@mWilden and Bendik Engebretsen messages I think the
question is already answered but I'd like to ask something:
If they killed Visual C++, how would they build new releases of Visual
Basic? Let me redo the question in another way: do they build VB using VB ?
Well, I guess not.
--
Regards,
// Per Ghosh
// hul...@algonet.se
Max Ruao <max...@nutecnet.com.br> wrote in article
<01bc17df$a06ee7e0$LocalHost@max>...
Justin Holmes
Max Ruao <max...@nutecnet.com.br> wrote in article
<01bc17df$a06ee7e0$LocalHost@max>...
> If they killed Visual C++, how would they build new releases of Visual
> Basic? Let me redo the question in another way: do they build VB using VB
?
>
> Well, I guess not.
My question for you:
Do they write Visual C++ using Visual C++??
>My question for you:
> Do they write Visual C++ using Visual C++??
Actually yes they did.
Justin
Remove .---- from address to mail...
Spam has just gotten too bad.
As a matter of fact they do. Each successor is written using the
previous version.
C was originally intended as an operating system programming language
and has often been called a super-assembler ( super in this case not
meaning greater or more wonderful, but higher level ). Obviously the
first C compiler was written in assembler, but after that, because of
the affinity between C and machine code you could write the next one in
C. Early on they may still have used assembly language but eventually
most of the compilers were written using a preexisting C compiler with
some assembly required <groan> for optimization.
Now C++ is C on steroids ( yes I know it has distinct features, but for
the sake of this discussion just let it stand ). Even so, you can write
a C++ compiler in C++ because you can always resort to the lower level C
functionality when you need to.
BASIC and specifically VB can not do this nearly as well, though it is
theoretically possible to write a text parser, syntax checker, etc. The
real question is "Why would you ever want to do that in BASIC???????"! (
shudder )
--
<****************************************************>
< >
< matthew...@xcellenet.com >
< >
< It goes without saying, so, I ain't agonna say it! >
< >
<****************************************************>
> Max Ruao wrote in article
> > If they killed Visual C++, how would they build new releases of Visual
> > Basic?
>> Let me redo the question in another way: do they build VB using VB ?
> >
> > Well, I guess not.
>
> My question for you:
> Do they write Visual C++ using Visual C++??
>
S*U*R*E
I simply can't imagine one building up all that stuff using Assembly from
the scratch.
By the way, they do not just use Visual C++, they use MFC.
But, to not stand on just my opnion, let me quote Dean McCrory from the
MSMFC team on the Scot Wingo's MFC FAQ:
"11.7. Does Microsoft use MFC in their products? Which ones?
There are many Microsoft apps written in MFC. Sometimes its just not
obvious... (to
name a few: Bookshelf, Bob!, WordArt OLE server, Visual C++ (of course),
Win95
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
paint, Win95 WordPad, some portions of Win95 FAX software, some Win95 games
I know of...).
...
Dean McCrory, MSMFC, 6/8/95"
But I was not fair when I asked if they build VB using VB, there's a part
of the VB package all built in VB:
the samples.
Ah, go ahead and offend them. They're just BASIC programmers after all!
I think it's a question of the right tool for the job. In corporate
environments
especially, the main concerns are ease of use, maintainability, and
productivity.
Although C++ is a more robust environment in mission critical apps, it
simply
cannot compete with VB in terms of productivity when it comes to cranking
out
UI-heavy apps. What many people do, me included, is use VB for the
front-end
and VC++ for the back-end processing -- this works quite well as each tool
is being used for what it was really intended for. If I were designing a
mass-
market horizontal app like Word, I'd probably use C++ for the increased
performance
and robustness. I don't subscribe to the blanket statement "VC++ is the
answer
to everything." Sure, you can hammer in a nail with a sledgehammer, but
I'd
rather use a nailgun if its available.
Although we'll see performance improvements in VB5 compiled code, I don't
think
it's going to unseat VC++ anytime soon. You may see VB used in more
instances where in the past VC++ was used for performance reasons, however.
This "one language for everything" argument has been going around since the
days of PL/1 and C++, although powerful, isn't the _best_ solution for
every
problem. Maybe Java will be the answer -- we'll see. In the meantime, use
the best tool for the job....
Mike Bouck
mich...@interdyn.com
John Parchem <jpar...@mcs.com> wrote in article
<01bc1704$da2b2560$d2bf03c7@oasis2>...
Mike Bouck <mich...@interdyn.com> wrote in article
<01bc1947$44a333d0$6f24a8c0@ceratops>...
Kevin Meek
k...@odyssee.net
See what ya get for being a advocate for Lucifer? ;-)
Mike Bouck <mich...@interdyn.com> wrote in article
<01bc19e5$0ee3b320$6f24a8c0@ceratops>...
> I never said VB was _better_ than VC++ -- I only suggested that it is
> arguably _faster_ (i.e. more productive per unit time) than VC++ for UI
> heavy apps.
OK, but I'm most interested in "better," not just "faster." Obviously,
increased productivity is a component in what makes one method better than
another for a given task.
> For example, if I want to make an app that stuffs the contents of an edit
> control
> into a static label when a button is pressed, in VB I just create a new
> form,
> drop a label, edit, and button control onto the form, and write one line
of
> code
> in the button's OnClick event handler to do the operation. done. In
VC++,
> by
> contrast, I have to creat a project workspace, create a skeleton SDI app
> using
> AppWizard, use the resource editor to create my controls, assign
> data/control
> variables to the controls, and finally do the operation in the button's
> OnClick
> event handler. The point is, even in this simple example, there are more
> steps
> involved to acheive the same thing in VC++ vs. VB. If this was a lager,
> more complex UI application, the contrast would be even greater between
the
> two.
I'd prefer to hear about more real-world examples, in which, for example,
you'd already have created the app. I agree that creating an app is faster
in VB, but once that's done, I don't see how performing the task you
mention is noticeably different. In both cases, you drop a control down
and write a line of code in OnClick.
I'd argue that a true OOP language lets you get the job done faster in a
UI-heavy application. Instead of copying and pasting, you can just
instantiate from a class.
Supposedly Microsoft practices something called "dogfooding" wherein
portions of a still-in-development release of VC++ that are up and working
are used to complete the rest of the release. The idea being that late
stage development tasks can't proceed if the early stage tasks were not
done correctly.
The term "dogfooding" comes from the idea that a dog food manufacturer
ought to be willing to eat the food he produces -- a kind of hard-core
quality assurance method.
For example, if I want to make an app that stuffs the contents of an edit
control
into a static label when a button is pressed, in VB I just create a new
form,
drop a label, edit, and button control onto the form, and write one line of
code
in the button's OnClick event handler to do the operation. done. In VC++,
by
contrast, I have to creat a project workspace, create a skeleton SDI app
using
AppWizard, use the resource editor to create my controls, assign
data/control
variables to the controls, and finally do the operation in the button's
OnClick
event handler. The point is, even in this simple example, there are more
steps
involved to acheive the same thing in VC++ vs. VB. If this was a lager,
more complex UI application, the contrast would be even greater between the
two.
Now obviously there are tradeoffs. My VB app will probably be larger and
slower
than the equivilent VC app, but that's when you need to ask "is it fast
enough for
this application?" If your primary concern for a given project is speed
and
efficiency -- use VC++, no question. But if speed and efficiency is not
the primary
concern, than you might opt for a faster, more productive route.
Mike Bouck
mich...@interdyn.com
Mark Wilden <Ma...@mWilden.com> wrote in article
<01bc1971$cd4548c0$4e0228ce@default>...
> Could you elaborate on how VB is better than VC++ for UI?
>
> Mike Bouck <mich...@interdyn.com> wrote in article
> <01bc1947$44a333d0$6f24a8c0@ceratops>...
Also, you can get the UI 90% and then you're stuck because everything is
off the shelf. Try adding a property to an OCX or changing the way it
behaves.
VC is the other way, I tend to work on the underlying logic (so where am
I going to store my data? Hmm, how about CDocument instead of behind
8,000 VB forms) and then the GUI grows around it which is just plain
better design.
With VC++ you get total access to everything (which can be scary
sometimes - until you need it) - if a CButton doesn't support a GIF - by
golly you can just add it!
It all depends on what you're trying to accomplish I guess...
But for me..
M A K E M I N E V C + + ! !
Scot
Stingray
http://www.stingsoft.com
MFC LIVES!
On the half full side of things, the success of Java shows two big things:
1.) that it and C++ make a better top/bottom, front/back than Mickey's got
and 2.) that the form revolution is over. A language with the ability to
make forms is the only way to keep from letting the tail wag the dog,
unless of course your done once that line of text goes from the edit box
into the static control.
I hope mickey gets with the picture and starts looking around at what all
the other vendors are now doing w/C++. Optima++, Visual SQL, and Borland
are starting to make VC++ look antiquated. Version 5 looks like a real
yawner; the press release makes it sound like it should have been 4.21.
Rob Williams
RobCo Incorporated
mail: r...@robco.xo.com
>As a matter of fact they do. Each successor is written using the
>previous version.
Does that mean that every 'new' compiler in fact makes use of code
compiled in a previous version, which, in turn, uses yet again older
code... right back into the assembler era? If so, an average program
should contain a lot of old 'compiler overhead' code. Of am I taking a
wrong turn here somewhere?
Joost van Schaik
Amersfoort, The Netherlands
-------------------------------------
Joost.va...@solair1.inter.nl.net
-------------------------------------
"The difference between men and boys
is the price of their toys."
Joost,
Usually, this "compiler overhead" code is no older than the compiler
which produced the compiler in question. This can be one generation
older that the compiler you are using, but by using bootstrapping
techniques, it can be completely up to date. The newest compiler,
compiled by the previous compiler, can be used to compile its own source
code. Done properly, all traces of previous compiler code can be
eliminated by such techniques.
Ron Martin
Ann Arbor, MI