
Visual Basic vs. Visual C++
Quote:
(YComputing) writes:
>>>We are undertaking a new project with a relatively agressive time
>>>frame and we're trying to decide whether to program in Visual Basic or
>>>Visual C++.
>>Why decide? I use a mix of both in most all projects, even throw in
>>Access for some devlopmen time tools.
>>I do not see them as mutually exclusive.
>Ahhhh! Please do your eventual replacement a favor and don't do this!
>How many people out there are really good at Visual C++, Visual Basic AND
>Access?
If they are trying to DECIDE between VB and VC there MUST be a (percieved
anyway) expertise availabloe in both. As for Access, Jeez, it is built
for Dilbert's boss to run - surely a development team can handle using it
for what it is good for,
Quote:
>Visual C++ is fine for writing DLL's for VB where speed is critical, but
>make sure that the C++ code will never need to be maintained if you go
>this route.
Infinitely doable. There is another advantage though: Common code procs
across a development team - wrap 'em up in a DLL to minimize changes,
duplicated code and application size.
Quote:
>If you start mixing and matching, you sacrifice the #1 need in business
>software -- maintainability.
I agree with the later clause, but not the first. The *act* of adding
some C procs to a support DLL, or hiding essentials like a security kernel
or trade secret algorithms in a DLL does not negatively impact
maintainability. It *CAN* but, again, since they are deciding betwixt VB
and VC, I am assuming some C expertise.
I would *not* council that they LEARN VC just to do mixed language
development, but MS has made it so easy to leverage the best of C, the
best of VB, the best of Office, it is kinda there to take advantage of,
provided the expertise is there.
Quote:
>Especially if you have an aggressive time-frame, stick exclusively with
>VB. Yes, you can go faster with VC++ (I've written code in both to
>demonstrate this), but VB isn't slow enough to warrant the maintenance
>hassle of dragging in C++.
By that reasoning we should rule out OLE servers, API calls and third
party tools.
Quote:
>Steve Young
>Young Computing
Sorry, No $ale
M Yaklin
ProTools Development Systems