More on the VB vs. VC++ debate

I've posted this before and I'll post it again. What I would absolutely love to see is a version of Visual C++ that incorporates VB's event driven programming environment while keeping all of C++ syntax and language structures, including pointers and all of those other really nasty things you can do to generate BLUE SCREENS OF DEATH.

This to me would be an optimal programming environment; one which would allow you to get as close to the "bare metal" as you desired, without kludgy VB type language constructs getting in the way, while also letting you take advantage of the really fast prototyping that VB objects allow you to achieve with Windows interfaces.

I can see no technical reasons at all for not doing this. I'm quite sure the reasons for not doing it are purely financial. The two markets seem to be, "idiot proof" and "not idiot proof", which seem to translate into "make it as easy as possible", and "make it as hard as possible". Of course, I'm only familiar with Visual C++ 4.0, and I think VC++ is on about 7.0 now. Perhaps others can answer whether or not VC++ has moved more in the VB direction.

Tis a consummation devoutly to be wished.

Don't you get a bit tired of this debate?

The respective languages will both get better with time so just use which ever is more appropriate or that you're more comfortable with.

Why is there this insecrurity complex with VB programmers that they are not using a REAL language?

Get over it and write some code, You'd be surprised how little of this goes on in other language forums, they just don't care...

You could spend a life time trying to convice a hard core C programmer that you're for real, but they don't really care, they probably use VB occasionally anyway and leave the conversation thinking "What's with these guys anyway??"

End users are concerned with end results, not what compiler is used.

Time to leave this debate.

Quote:

---

Originally posted by Paul282
Don't you get a bit tired of this debate?

The respective languages will both get better with time so just use which ever is more appropriate or that you're more comfortable with.

Why is there this insecrurity complex with VB programmers that they are not using a REAL language?

Get over it and write some code, You'd be surprised how little of this goes on in other language forums, they just don't care...

...End users are concerned with end results, not what compiler is used.

Time to leave this debate.

---

Hmmm, you seem to have responded entirely to my subject line, and not at all to the substance of my post. I agree with all of your observations. However, the point of my post was that it should be possible to have the best of both worlds. I am neither predominantly a visual basic programmer or a visual C++ programmer. I'm about equally adept at both (somewhere above average but definitely not yet an expert in either).

And like it or not, the price you DO pay for ease of use with Visual Basic is LOSS of POWER, in the sense of being able to achieve maximally efficient programming solutions. This is not at all a debate about what the end user gets, but rather about how much crap the programmer has to go through to achieve results for the end user. My point was simply that by combining the C++ language (vastly superior to VB IMHO), with VB's event-driven programming model (vastly superior to C++'s from the ground up approach, IMHO), you would have an Integrated Development Environment that maximized both productivity and power.

Your thought is very good.

Why don't you mail it to MICROSOFT. If they like it, they could make VC++ like VB!

There is no value in posting this question here. All you get here is your post will become hotter and hotter day by day but what about your VC++ like VB?

If you want the ease of VB and the power of C++, why don't you switch to Bortland C++ Builder? That *is* best of both worlds. (creating an interface sucks not as hard as it does in VC++, and it is c++ code (and actually more ansi compliant then VC++ is...).

Quote:

---

Originally posted by Crazy D
If you want the ease of VB and the power of C++, why don't you switch to Bortland C++ Builder? That *is* best of both worlds. (creating an interface sucks not as hard as it does in VC++, and it is c++ code (and actually more ansi compliant then VC++ is...).

---

Damn, You dragged me back into the debate with that comment :D

Borland C++ Builder is not as wonderful as that. It's a RAD system identical to Delphi and not as good as VB. I use it from time to time because it has static linking so it's good for stand alone tools.

Problem is, is that it's a port from the Delphi IDE and the componant base (VCL rather than Active X) is pascal and so sometimes your code is riddled with pascal too. Performance is much like VB it has a few nice features like Form1->DoubleBuffered = true; which I like. It doesn't properly support multiple inheritance of it's componants (because delphi doesn't) and has SHOCKING DB support. you can get some third party stuff which is ok but you really gotta look. BCB 5 has ADO only in enterprise version which is why I didn't buy it Thousands of dollars. I use 4 from time to time. the interface is familiar if you come from VB but don't expect your software to gain in performance if the algorithms you're using are the same. (except maybe in graphics, but not maths)

Strings are done better. VB flitters around with unicode and ansi and often you need to check where the hell you are before you call the API, Where as the BCB AnsiString made more sense.

VC++... hmmmm, The dos compiler is faster and makes smaller exes that BCB BUT... I've read two books on VC++ and have still never managed to make anything worth while with it. Productivity droppped to ZERO! Admittedly my API skill weren't much then so MFC looked greek. Don't think I'll give it a second chance.

(Still rambling on)
The other down side of BCB was that their VCL componants are old. The VCL Richtext box was very slow compared to the activex version, especially opening 3mb rtf files and then resizing the window, you computer almost freezes! it calls an older version of the richtxt dll.

(they may have fixed that in BCB5, but what they really needed to do was rewrite the VCL in C++ for BCB rather than the bloody pascal version.)

haahhh, now I feel better after that big spiel... you all asleep yet?

[Edited by Paul282 on 05-01-2000 at 08:30 AM]

My thought is that VB is great for prototyping. If you want something done quickly, use VB.. if you want something that's efficient, then use VC. What would be great is if the VB compiler would create *.o files that you could link with C *.o files. I don't think I'd want VC to loose the functionality of manually creating windows but it would be nice if there was some type of builder that would take your drag-and-drop window design and turn it into code. Then you could modify the code to be optimized for what you want. There's also alot that I'd like to see added to VB, but then we're talking about pushing the language beyond what it was intended for. Things like _real_ pointer manipulation, the ever popular "continue" statement, and much better file access commands. The lack of these things make a lot of file and string manipulation feel pretty hackish to me. I guess my ideal invronment would be VC with the ability to add VB code, like like how you can include ASM calls in C.. and how you can have .cpp file and c files.. both handled differnetly. If you think about it, it should be possible. A .o file just contains the compiled code fof that file. You should be able to have a compiler that can take the refrence to that function and link it to that .o file. This isn't new technology...

I've never had real problems using Borland C++ Builder. Ok, I didn't do *that* much with it, but I loved it better then VC++. Me too bought a bunch of VC++ books, but still onluy managed to write one program, and that was a huge pain in the ass. It took my 2 days how to figure out how to save a file, after the mainframe had shown the savedialog (and actually created the file), and in my view save the file itself. Only that made me move back to VB. Programming should be a bout programming, not about learning the IDE first before you can do something. The IDE has neat stuff though, I love the macro's. But then, without a project, no need for macro's ;-)
And another huge negative thing of VC++ IMHO is that it's NOT C++, it's MFC programming, and by coincidence, the language looks like C++, but it definitely is not.
That's another reason why I like Borland better.
Now I don't know about database performance, neither richtext (I use wordpad if I handle richtext files :-), but at least it's syntax (the stuff you write, not the VCL, which is pretty powerful by the way) is just plain C++ (with better Ansi compliance then V-MFC-++).
But then, every job has it's tool, and I'm sure there are enough reasons to find why using VB, VC++, Delphi, Borland, and all other langauges. If you have the time, check them, compare them, then make your decision.
If you don't have the time, stuck with the tool you know best since that will be the fastest way for you to write a program.

And don't forget, most parts of Visual C++ is not ActiveX either, only they use MFC code for their objects where Borland (indeed) uses object pascal.

And besides, VC *is* event driven, only problem is that there are not much objects you can insert visually (why did they call it *Visual* C++ anyway, only true visible part is the sourcecode :-))

Hmm some how I have the feeling this thread should belong in another part of this board.... :-)

I'm getting very frustrated with VC++, I don't know if there's something wrong with my copy but it seems I can only put controls on a form while my program's running, is it only me that seems stupid too, I agree with what crazyD says about MFC programming, it should be called not perticularly Visual MFC, then we'd at least know what we're buying.

I think i've mentioned this before but I love the C++ language itself, I'm no expert but i know what I like.

I think I heard a rumour that version 7 is going to have the VB environment for all the languages, for some things I think that's going too far, a VB class module is a COM object, but a VB programmers we can't get at the COM part(good, I don't understand it) I don't want to write the COM part myself, but I'd like to be able to edit it if I want to, I hope in the new environment, we'll have the stuff we need as an inherited abstract class we can see and edit, but don't have to write, It depends what happens with this microsoft splitting thing, as it looks now all the undocumented API's are going to have to be documented (horay) but I hope someone persuades someone that MFC is somehow illegal, that'd be a happy day for us all.

True,VC++ is not "Visual"

I think it might be "Vicious C++" or "Variety on C++" I had more luck with C++ with linux where you just write you're C++ code and if you're not sure you can look in a book...

BCB... I admit, I like it, but if you want to get REALLY annoyed with something then try to write DB connected software with it... the Plus is that you can see the data fill tables in design time the minus is BDE 'Borland Database engine' Even hard core delphi programmers don't stand by it. Imagine any Db work you want to do (even access) requires that a 12 Mb file to accompany the project (can't static link it) That's bigger than Mdac! and it has to be installed with every package even if the person has it installed because it has to create alias's for ODBC. You can install a partial version of only 2-3 mb but if the person has other BDE software requiring the full install then that will no longer work.

A sub industry has started up for 3rd party odbc drivers, whiich is what I ended up doing.

Still the more I get into the API the less I need C++ (and yet learn more about it)

I don't understand what all the fuss over the MFC is. You don't have to use it.. all it is, is pre-established classes that you can use to make windows. Granted, you're not going to get very far very fast without using it to make windows, but if you're going to write a non GUI app, you can use all the standard ANSI C++ and C stuff. It's something that's there in addition to the compilers. I'm still pretty new to the MFC but the way I look at it, all it is, is classes that you didn't have to write yourself. As far as RTF, etc, I haven't had much expierence with controls in VC, but I'm the kind of person who wants' to be able to have total control over what happenes in the code anyway. Maybe I'm missing something here.. if so, let me know.

I always got the feeling in VC++ that you either:

a) Use MFC for Windows programming and make everything a bloody class whether you want to or not

or

b) F***ing right off.

Which is what I ended up doing.

The book I got had the back half as an MFC appendix, which would be good if you were sent to prison and had 20 years to memorise it all.

Ansi C programming with All API calls looked more interesting

[Edited by Paul282 on 05-01-2000 at 11:15 AM]

Quote:

---

Originally posted by Paul282
True,VC++ is not "Visual"

I think it might be "Vicious C++" or "Variety on C++" I had more luck with C++ with linux where you just write you're C++ code and if you're not sure you can look in a book...

...Still the more I get into the API the less I need C++ (and yet learn more about it)

---

I think you've hit the nail on the head, and isolated what my major complaint is with VC++. It is simply not really "VISUAL".

Don't agree with the comment above that somehow VC++ is simply MFC programming. That's a choice you make, and a wise one if you're really gonna write a lot of "Windows" programs in C++. However, you don't "have" to use MFC at all. But if you don't, windows stuff becomes really tedious.

A wiser choice, as most of us here have discovered, is to use VB for the user interface stuff and write C++ dlls to do the low-level grunt work that requires speed.

... well my MFC was never any good you see :D

I don't aggree about creating DLLs to do the grunt work though. The API has most of what I need and where it doesn't VB math is pretty quick if you know your data types well. I find that if you have a really CPU intesive task it's often several functions, and the constant DLL call overhead (while very small) is often as high as the difference in the speed of math.

9 times out of 10 (for me anyway) my program didn't run as well as the C++ equivelent because it wasn't as well written. A different approach or different algorithm (or API call) was all that was required to meet the speed

Admittedly I don't do much on-form 3d rendering so that might be different

ShepherdOfChaos, have you ever tried Borlad C++ Builder? It keeps a good development environment quite familiar to Visual Basic. I mean the form designing and event processing are quite the same.

It's also fast enough. You gotta try it out... ask me if you want more infos.

See you,

keetsh

I think they still have their 60 day enterprise edition for download.

try it before you buy it.

I definately agree with creating a dll to do the grunt work. VB definately has a lot of limitations that C doesn't have. Though I like the ease of development of the "visual" components, I get very frustrated with the lack of control. I can't manipulate memory the way I want to.. I can't access a file the way I want to.. I can't process data as fast as I want to. I'm not talking just about math here. I'm talking about allocating large amounts of memory to do thousands or tens of thousands of caluclations. It's just not going to happen in VB. If I want to work with a file, I pretty much have to read it into memory and manipulate it and then write it back out to disk. This isn't practicle with huge files.. hence making a DLL that will handle the in-file manipulation.

For applications that aren't time sensitive, VB will take care of the job.. but you don't see people trying to write time critical apps in it. I'm not saying it should be able to handle this.. that was never the intention of the language.

Really?

In the area of files I've never had any problems. I deal exlusively with byte arrays and deal with files of hundreds of MBs.

What can't you do with VB in file IO that you can do with C++? I'm genuinely interested because I may be missing out on something...

I feel that C++ is a better way to go for the following reasons:

1) its portable - I can take the same program and compile in winblows and in linux

2) c++ has waaaayyyyyyyy more power (for good and for evil)

3) c++ isn't necessarily microsoft dependent

as in... down with MicroSoft!

Thanx for letting me rant.

Hang on hang on

you can't port a C++ program writen for windows to linux !!! There's no way it would compile. The program is too dependant on the OS architecture, API etc

WAAAAAYYYYY more power ??? really? in what way?. What have you actually done in C++ that you have not been able to do in VB to date? (a dos app? wow, can use qbasic for that)

There's more quite a lot C++ can do, but under windows... what do YOU need it for?

Most VB programmers just think it's cool to talk about C++ like you know all about it, like name dropping.

If C++ is "a better way to go" in your opinion, then go that way.

I think that this is about all that you can do in C++ that you can't do in VB

Handle Messages from a different Program.

Run your own code in another Program.

Set a Global Hook.

I'm working on the first 2, and I think I'm getting somewhere, but writing a C++ dll is probably easier.

There's been talk of MFC which some people object to, in VB you are using MFC without even knowing it (some of you probably had an inkling) if you try to use GetBitmapDimesionEx on a stdPicture bitmap in VB, it won't work, it's a fake bitmap in there, I hate it I want a real Bitmap. But VB is so simple to use, Trying to do COM in C++ is a nightmare whereas in VB you can set up a COM object in seconds, again withouut even knowing you're doing it. Which would you prefer in a fight, a machine gun or a MIG Fighter Jet, I'd prefer the gun because I have no Idea how to work the MIG.

The API book I'm reading at the moment might interest you, it's got a section on global hooks. They've published a DLL with the book as a stepping stone to achieve it as obviously VB can't create a traditional DLL for the injection into memory. I haven't looked into it in detail but there is a sample project on the CD which works (I'm fairly sure of course that their DLL has to be on the system) but it's free to use in you're own projects so I can give you a copy if you're interested.

The book is Win32 API programming with Visual Basic by Steven Roman (O'Reilly book with a monkey on the cover)

I think you'd really like it

Yeah, I've got it too, it's the best book I've read on the API. I'm trying to do it in pure VB though. As an exersize mainly.

Well, if you pull that off I'm sure Dan will give you a job at Desaware :)

According to the powerful term used a few replies above. I just wanna point you on something... The power, I mean the speed of your program usually depends on the compiler and the components you use.

Say you make the same program, same window with 2 buttons on it on both VB and VC++. You're NOT gonna see the speed difference nearly whatever you do using components.

Now imagine a 10^8 loop that multiply 2 by 9. That's what I've coded on both Borland C++ Builder and VB 6. When I runned my programs, the VB one finished it in 30 sec. The C++ in less than 3 secondes :))

Well see you,

keetsh

I'm impressed, Is Borland C++ faster than VC++?

I'm doing some graphics calculations and want to do the back end in C++, it's about 50 calculations per pixel if you work it all out. Is that still going to be faster in C++ or would the connections slow it down? (one call to a dll does all the calcs for the Bitmap)

Yes in loops C is somewhat faster, accessing arrays too (basically all stuff you can switch of with the compiler options).
And you see a slight difference when loading the form with 2 buttons, C is slightly faster.
But on the other hand, in most cases there's not really a need to use C++, especially not if you know VB very well, and C++ "just a little bit".....

OK.. to respond to a couple of things:

* The speed in C comes from the ability to directly manipulate memory. Say you're going to have a need for upwards of 15 meg of memory just for data. How would you do that in VB? Make arrays.. user deffined types? Probably.. and then assign all the data to each element. Do you know how much time would be wasted doing that? In C, you can allocate that 15 meg of memory and manage it yourself. There you get your speed and your power. You are in complete control of what happens to that memory and when. I guarantee that if something of that magnitude took 10+seconds in VB (which it probably would) it would take under 4 seconds in C.. if it was well written. For standard office apps that aren't time dependant, VB is just fine... and that's what it's purpose is.. to be a programming language which provides for rapid development of office applicatons. There's just no compitition as far as power and speed are concerned though. I could understand a little bit if this was about someone trying to say that C++ is as fast as C.. (I don't agree with that either) but between VB and C (or C++), there's just no contest.

* File Access - byte arrays just don't make sense to me. Why not just give the programmer a file pointer and let them move it through the file? With a byte array, you have access to a "word" so to speak. With C, you have access to each char. And if you don't use Byte arrays in VB, you've got sequential file access.. which means in order to get back to the beginning of the file, you have to reopen it. There's no seek() or rewind().


* What C can do that VB can't. - When it comes down to it.. probably not much. That's because a lot of people have written things in C that you utilize in VB. All the API calls.. they are in C DLL's. Now.. the question is, what can you do in VB without using calls to things written in C? Would it even be possible to do half the things that all of us do every day without it? Probably not. Just as a point of refrence... Try to write TCP/IP communication software without a control. i don't even think it's possible in VB. It is, however, possible in C. And.. it would be possible to write that code to be portable between Windows, Linux, Solaris, AIX, HP-UX, IRIX, etc..

OK.. I don't want to sound like I'm bashing VB here. I do appreciate it for what it's purpose is. The fact is that the power of VB comes from the controls and add/ins. the ones that perform lower level stuff are probably written in C.. I don't really care. I'm happy that they exist because I can make something in VB in a fraction of the time that it would take me in C. As efficient? No... But a hell of a lot faster.

hmmm...

I've never noticed much performance increase in Borland C++ builder in the areas of loops and file pointers (or much else really which is why I don't use it much anymore)!

I'm not saying that there is no perfomance benefit, nor am I saying lets write Quake4 or SQL8 in it but if you're in windows and you're expecting a big performance increase in say Math, just by porting to C++ you'll be dissapointed, it's a little better but the difference is rarely worth the trouble to code.

Likewise (for Sam) if you're doing graphics:
1) there's probably a faster way in VB that what you're doing
2) if there's not, then a C++ DLL in VB won't help, you'll need to go all the way and code the thing in C++, or Ansi C like Quake

The portablilty arguement is a lie. Any C++ GUI code for windows won't compile under linux or anything else. nor will anything that calls the API, winsock or whatever.

I like C/C++ as a language, it's fast, it's robust and it's infinitely tunable and tweek-able. But it's time consuming and if you've used it you should know at the outset of a project whether it's really necessary.

Eg, VB still can't create a DLL... :(

If you think that C++ is better than what I write here then you should be using Borland c++ builder. It's pretty much as easy to use as VB (assuming you know C++ syntax that is)

from what I can see C++ will be a lot faster for several reasons, the main one being that in VB I have to shift memory around so much, to write to the bitmap bits in VB I have to

Move the bits to my own array before I operate on them.

The operations I'm doing involve doing transformations on colours, I have to move them around alot to get at the individual bytes, in C++ I can just use a union.

I need to multiply by a number between 0 and 1, this involves f.p. calculations in VB, in C++ I can make my own variable type and overload it's operators to do this faster.
I can even use asm to define these operators which must be a significant speed improvement.

I have been analysing this and by using pointers evvectivly I can write much faster mor efficient code, you just can't do this in VB.

I saw a neat piece of code recently for using a RGB User type with the bitmap bits API functions so that you can have the speed of the API getbitmapbits with the ease of use of RGB, a good way to manipulate colours on the fly. I'll see if I can find it.

Pointers'd be nice though, proper linked lists etc.

You should get a copy of Borland C++ Builder, If I were you I'd give VC++ a miss though.

You could always try Delphi, you'd have your pointers there too, and the borland interface is more tayored around pascal than C anyway. You'd get to keep using a RAD environment too.

Let me know if you're interested in the RGB tripple type code... I've got a sample project I think, from some book or website

Hi there..

One piece of advice.. Paul you're absolutely right about the portability of your code. It fully depends on the operating system. Learn Java if you're interested in writing an O/S dependent-free program. Of course Java is much slower than VB or C++. But there we are, the Java most known sentence is: "Write once, run anywhere".

Whatever you're about to write, you should weight the push and pulling advantages of both programming language.

Hope this helps..