Thread: Is this really true ?

Originally Posted by Swoorup

We can use it without grasping the "bad habits", but it is difficult to do so, while C/C++ on the other hand forces us to avoid bad practices.

That is not true. There are plenty of bad habits exhibited in C/C++ as well. It's just a VB person will develop a very different set of bad habits than will a C/C++ person.

Some good habits in a VB programmer are bad habits for a C/C++ programmer, and vice versa.

Originally Posted by Swoorup

My friends don't ever declare variables, bad naming of the variables( haven't realized how the same block and small-ed lettered variable would behave).

Granted, it is not possible to get away with an undeclared variable in C/C++, but a lot of C/C++ programmers routinely name their variables quite badly.

Originally Posted by Swoorup

Nobody even realizes about the difference between passing by ref and by value.

You'd be surprised how often a C/C++ person fails to understand that difference. I've seen professionals make serious mistakes based on that.

Originally Posted by Swoorup

VB keeps students mind off the structure of the program, it just focuses on the input and output of the program. While a language like C considers optimization, the flow of the program, its implementation and forces us to consider how the same code would run on other platforms. So when a person chooses first to learn VB, it keeps his/her mind off these things, just makes him/her focus on the outcome. And the same behavior is developed through his VB years.

Yes, C and C++ "considers" optimisation. The flip side is that a lot of C/C++ people indulge in premature optimisation. They will spend a week hand-crafting some excruciatingly cryptic bit of code, only to find in testing that it lops 2.4 milliseconds of execution time from the program, if they run it more than an hour. Although most don't realise the benefits of their efforts are that small, because they don't actually test to find out.

A primary source of problems in C/C++ code is incorrect flow control.

C/C++ does not force anyone to consider portability of their code. In fact, it is more common to encounter people using compiler-specific extensions, while insisting their code is portable because they wrote it in C or C++.

And don't even get me started on how many C/C++ folks misuse pointers.

I'm not trying to discourage you from learning C/C++. In fact, I think it would be good for you. But don't make the mistake of assuming that C or C++ provides a panacea to VB's faults.