>In today's W95 environment how does Visual Basic compare to C++.

>I have been offered my choice of the 2 after participating in a MS
>Beta
>test.

>I have not programmed in 15 years since I used basic with Apple 2 &
>studied
>Cobol in college, but would like to get back to it now for the PC.  

>After taking a look at an example of C, I am almost certain I want
>Visual
>Basic but everything looks so complex today with the windows
>environment.

>Any advice would be welcomed.
>--

>Thanks...................Bik

>Please remove the # when replying by email.
>Stop the Spammers!

> >In today's W95 environment how does Visual Basic compare to
C++.

> >I have been offered my choice of the 2 after participating
in a MS
> >Beta
> >test.

> >I have not programmed in 15 years since I used basic with
Apple 2 &
> >studied
> >Cobol in college, but would like to get back to it now for
the PC.  

> >After taking a look at an example of C, I am almost certain
I want
> >Visual
> >Basic but everything looks so complex today with the windows
> >environment.

> >Any advice would be welcomed.
> >--

> MS VB 5.0 Prof. is your choice for OOP.  I do recomend that
you
> learn C so you can review functional programming.

> > >In today's W95 environment how does Visual Basic compare to
> C++.

> > >I have been offered my choice of the 2 after participating
> in a MS
> > >Beta
> > >test.

> > >I have not programmed in 15 years since I used basic with
> Apple 2 &
> > >studied
> > >Cobol in college, but would like to get back to it now for
> the PC.

> > >After taking a look at an example of C, I am almost certain
> I want
> > >Visual
> > >Basic but everything looks so complex today with the windows
> > >environment.

> > >Any advice would be welcomed.
> > >--

> > MS VB 5.0 Prof. is your choice for OOP.  I do recomend that
> you
> > learn C so you can review functional programming.

> Of course, C++ lets you do OOP.  Actually, many would consider
> VB5 not to fully support OOP, since it only lets you do
> "interface inheritance".  What this actually is is a sort of
> support for polymorphism, without real functional inheritance.
> A lot of folks say you can accomplish this via containment in
> VB.  About the only thing I could say that no one would dispute
> is that C++ and VB have taken divergent paths here.  Of course,
> you could also accomplish interface inheritance in C++ too,
> with a little work.

> C++ is more flexible, has full OOP support, and your programs
> should run faster.  Any Windows program you want to write, you
> can write it in C++.

> VB lets you develop more quickly and is doubtless easier to
> learn (though less so with every release, I'd say).  Still
> cannot create standalone programs (you have to distribute a
> large runtime library, at the very least).

> Hope that helps.

> > VB lets you develop more quickly and is doubtless easier to
> > learn (though less so with every release, I'd say).  Still
> > cannot create standalone programs (you have to distribute a
> > large runtime library, at the very least).

> > Hope that helps.
> VB5 does not make you distribute a huge run time file
anymore. You can
> make a native code program with either VB5 Pro or VB5
Enterprise. If you
> want, run time file (dll) use is allowed. However, the
program will
> probably ballon in size with the now unneeded DLL code
included.

> > > VB lets you develop more quickly and is doubtless easier to
> > > learn (though less so with every release, I'd say).  Still
> > > cannot create standalone programs (you have to distribute a
> > > large runtime library, at the very least).

> > > Hope that helps.
> > VB5 does not make you distribute a huge run time file
> anymore. You can
> > make a native code program with either VB5 Pro or VB5
> Enterprise. If you
> > want, run time file (dll) use is allowed. However, the
> program will
> > probably ballon in size with the now unneeded DLL code
> included.

> According to everything I have heard, you are mistaken.  Yes,
> you can make a native code program, but you still have to
> distribute at least one LARGE (1.3M?) run-time library.

> > > > VB lets you develop more quickly and is doubtless
easier to
> > > > learn (though less so with every release, I'd say).
Still
> > > > cannot create standalone programs (you have to
distribute a
> > > > large runtime library, at the very least).

> > > > Hope that helps.
> > > VB5 does not make you distribute a huge run time file
> > anymore. You can
> > > make a native code program with either VB5 Pro or VB5
> > Enterprise. If you
> > > want, run time file (dll) use is allowed. However, the
> > program will
> > > probably ballon in size with the now unneeded DLL code
> > included.

> > According to everything I have heard, you are mistaken.
Yes,
> > you can make a native code program, but you still have to
> > distribute at least one LARGE (1.3M?) run-time library.

> Not sure how that applies to my posting.  The previous poster
> had claimed VB5 programs don't necessarily need a run-time
> file.  I just said they did.

> Actually, you can statically link the MFC into a C++ program,
> and it will only bring in the stuff it needs.

> > Not sure how that applies to my posting.  The previous poster
> > had claimed VB5 programs don't necessarily need a run-time
> > file.  I just said they did.

> > Actually, you can statically link the MFC into a C++ program,
> > and it will only bring in the stuff it needs.

> This is exacly the case.  With C++ you can statically link MFC allowing
> for the EXE to contain only what it needs.  With VB5's "TRUE"
> compilation support you still -- NO MATTER WHAT YOU DO -- have to
> distribute the MSVBVM50.DLL (1.3 meg) file.  This is garbage.  For those
> of us who want to distribute applications over the internet, this fact
> is simply unacceptable -- most people still have 28.8 modems -- not T1
> lines!

> Frank,
>   Forgive me if this sounds like a dumb question, ,, but,,, I was under the
> impression
> that VC++  REQUIRED the entire MFC dll to be included with distributed
> progams
> even if you only used some portions of the dll?  I don't completely
> understand the
> concept of Staticlly linking to MFC but, doesn't the entire dll still have
> to be present ?
> Or can you pull out portions of it ? My only other thought on the matter is
> that because
> Win95 is written in C (or is it C++ ?) that the OS included the MFC dll
> when the OS was
> installed on the users machine. And there for a C or C++ programmer is
> assured that the
> dll is present and does not have to worry about including MFC.dll with
> his/her program.
> james

> Frank,
>   Forgive me if this sounds like a dumb question, ,, but,,, I was under the
> impression
> that VC++  REQUIRED the entire MFC dll to be included with distributed
> progams
> even if you only used some portions of the dll?  I don't completely
> understand the
> concept of Staticlly linking to MFC but, doesn't the entire dll still have
> to be present ?

> > Frank,
> >   Forgive me if this sounds like a dumb question, ,, but,,, I was under
the
> > impression
> > that VC++  REQUIRED the entire MFC dll to be included with distributed
> > progams
> > even if you only used some portions of the dll?  I don't completely
> > understand the
> > concept of Staticlly linking to MFC but, doesn't the entire dll still
have
> > to be present ?

> Win 95 was NOT written in MFC, for one. Static linking likes the
> COMPILED MFC libraries to your executable, therefore eliminating the
> need for the Dynamic Link Library.