quick question 4 C programmers

[yetifoot]

I found c quite easy to learn, but c++ i've been learning for ages now, and i still don't understand it.

[na_th_an]

That's 'cause what me and LooseCaboose said: C++ is not a good idea to learn OOP. It's better to understand OOP, then learn C++.

As LooseCaboose explained, there are techniques you can apply to pain procedural languages, encapsulation being the most important. In fact, on its very beginning, OOP was just a syntax change to make authomatic and/or obligued some techniques you could perform easily with procedural languages.

You can code in QB in "the OOP way". Encapsulation is the key. Master it, and you'll be a faster coder and the results will be way more robust and expandable.

I say that C++ is not a good idea to learn OOP 'cause it doesn't obligue the coder to use OOP stuff. In Java, it's mandatory or your program won't even compile.

[yetifoot]

by 'encapsulation' do you mean putting things into types and stuff like that?

ie

Code:

Type MYDATA_T
  _data As uByte ptr
  w As Integer
  h As Integer
End Type

Something_Init(m As MYDATA_T)
...
End Sub

Something_Work1(m As MYDATA_T)
...
End Sub

Something_Work2(m As MYDATA_T)
...
End Sub

Something_DeInit(m As MYDATA_T)
...
End Sub

I do a lot of this type of coding, but its mainly so that code is more modular/portable.

[na_th_an]

Encapsulation can be defined, in a very loose way, like this: only make visible what has to be visible. That way you use your classes (in OOP) or program modules (in procedural languages) like black boxes. You just know their interface, not the way they work. I.e. from outside, you know what they do, but not how.

Imagine you are using a list. With a list you can add objects to it, or extract objects from it. All you have to know are those function prototypes, but you don't care about how the list is built: if it uses a static array, if it does dynamic memory allocation... You don't care. That means that you can switch implementations, or change them completely, or many more things.

Non-encapsulated programs are those where the way you use their facilities depends on the implementation of those facilities. For example, imagine that you want to cheat and you know that your list is in fact an array and you access that array directly from somewhere else in your program. That's a no-no, 'cause if you want to replace your list implementation for something better you'll have to change many more stuff.

Same happens to functions inside that class/module: you just need to add/get elements from the list, so those are the only symbols that have to be exported. Another inner functions are not needed elsewhere so you just pour them out your header files. The rest of the world doesn't need to know about their existence.

In sum, encapsulation aids with maintainability, robustness (invented word, btw ), scalability, security and many more things.

[torstum]

Visual Basic is Object-Oriented isn't it? Would it be the best language for learning OOP? I confess that C looks a lot simpler (and better, not to mention perhaps faster) than C++. But I'm by no means an experienced C programmer, I'm still sticking with Qbasic, and then I'm moving to FORTRAN (it's kind of a time travel really).

There are also a couple of freeware interpreters that should be great for learning C: Cint and Ch. Just do a search and you'll find them easily.

[WaffleMan]

Um... this post is several months old.

[torstum]

...didn't notice that.

[na_th_an]

VB6 is not OO. It has OOish syntax, but it's not OO at all. VB.NET is OO, though.

If you want to learn OOP, learn Java. Then go to C++, once you've learn the (important) concepts.

[NecrosIhsan]

VB6 is object-based but not object-oriented. People like to parrot the differences all the time, especially people who are VB6-haters. VB6 will give you some of the basics of OOP but it is not specifically an OOP compiler. Understanding objects in VB6 will give you a good foundation for "proper" OOP later on though.

[na_th_an]

It provides some conceptual basis. The Private/Public concept, visibility concepts, notation (Module.Funcion or Module.SharedVariable), and some other things. But it is not an object oriented language per se. It doesn't let you create true classes of objects, just something that comes close.

I love VB6, btw.