c++ convert to oop(object oriented programing)

Pages: 123
Repeater wrote:
That means "designed with objects". That's all it means. You can write OOP code without classes. You can write OOP style C. OOP is a way of thinking, a way of designing.

Hi, Repeater. I’ve always thought of ‘objects’ as instances of structs/classes.
Am I too naive? In C++ what else may we ‘classify’ as objects?
(Well, ok, templates…)
Ask a dozen people what OOP means, get a dozen answers.

What follow is 100% my opinion and the other eleven people will disagree.

To me, it's about thinking. It's about the solution to a given problem I come up with inside my head (and on paper sketches) being a model that lends itself to object-heavy implementation.

For example, if I was going to write a program to experimentally simulate queues in a post office, I might decide that each person will be represented by an object, and each queue is also going to be an object, and each open window is going to be an object. Each person will know how long it has been waiting, a queue will be an object containing many people, each window will be an object that takes a person from the front of a queue.

I could then create this in a very OOP fashion. I could write it in C. I could write it in C++. I could write it LISP. Some languages would make it easier than others, because some languages come with easy ways to create and manage these independent objects, but OOP isn't in the language; it's in the design.

To me, an int can be an object. A single char can be an object. It's all about the model, and how I'm building it in code, and how the parts interact.

Languages that make this easy often provide classes and structs and class functions and containers to collect groups of objects together and so on, but that's not OOP; that's just tools that make implementing an OOP easier.

If I have some disparate functions, and I stick them all inside a class, I can call that an object if I like, but it's not OOP. That object isn't part of a coherent design that's easy to think about and easy to reason about because I've modeled it as objects interacting.

In situations where there will only be one instance of any given objects, I find myself dubious as to the value of OOP thinking in such case. Sometimes, it just seems like objects for the sake of it. For example, sometimes I see something like this:

1
2
3
4
5
int main()
{
  Gameobject game;
  game.run();
}


and I wonder if there really was a benefit to this single "Gameobject" existing, and would it have been better expressed as something like:

1
2
3
4
5
6
7
8
9
10
11
int main()
{
  // Init code

  while (keepRunning)
  {
    // main loop
  }

  // teardown code
}


Last edited on
... the traditional definition of object-oriented used within broad communities of programmers. A language or technique is object-oriented if and only if it directly supports:
[1] Abstraction – providing some form of classes and objects.
[2] Inheritance – providing the ability to build new abstractions out of existing ones.
[3] Run-time polymorphism – providing some form of run-time binding.


I reckon the 'broad communities of programmers' would number in the 10's of millions?
Expect so, yes, but what you're talking about there is an object-oriented language. You don't need an object-oriented language in order to practice OOP; it just makes it more convenient.

The programming is mostly done inside my head; that's where the OOP happens. The notation (or "programming language") I then use to write that down may indeed contain constructs that make it easy and more concise to express what happened inside my head, and I may well have constrained my thinking in order to make that final expression easier for myself, but to state that OOP can only be expressed in a particular set of notations is to confuse the map for the territory.
Last edited on
or, to drive that home, in the 90s we had a fair sized OOP C program. It used function pointers in structs as methods, and various other tricks with pointers could do much of what was needed.
C++ language and constructs are deliberately included in the traditional definition from its inception/invention. But C++ is not solely dedicated to the OO paradigm as we all know.

Cerebral processes are obviously involved but as you can see they aren’t part of that ‘traditional definition’.
Cerebral processes are obviously involved but as you can see they aren’t part of that ‘traditional definition’.


Yet they are far and away the most important part. I suspect that our progenitors felt that this didn't even need mentioning. However, we now live in a world that conflates programming with typing.
( C has structs but it isn’t object oriented. It doesn’t meet the definition, never claimed to. )

How should cerebral processes be incorporated? As item [4] in the traditional definition?

That definition you've provided is a definition of an OO Language. Not OO programming.
It’ s a traditional definition of OO language or technique. It refers to numerous programming languages, one of which is C++ which isn’t only a OO language.
Yes, that's very clear. But the thread is about OOP. We don't need to add the definition of OOP to the definition of OOL. They're different things.
Last edited on
The quote is from Bjarne Stroustrup.
Does that change the facts? If Stroustrup defines OOL, why should we pretend it's a definition of OOP?

You do understand that OOP and OOL are different things, yes? Different things with different definitions.
Last edited on
@Miskok
the program is to elect a chairman ... the program is ready but I want to change to OOP


That wasn't the answer that I was specting...

You want us to read your code, understand it, modify and give you a cooked pie... It isn't the way...

I'm not a good programmer, I'm not even a good beginer programmer but I'm willing to spend some time on your problem because I think that it's a good way to learn and improve my coding skills. But you don't want help, you want your work done (by others)...

You don't deserve our time.
For what it's worth, I agree, you can do OOP in C.
e.g.
1
2
stack_push(my_stack, 3);
stack_pop(my_stack);
It's just a bit more kludgier.
But parts of OOP (or, at least what is considered OOP by particular audiences), like equivalents to runtime polymorphism (interfaces) and inheritance, require a lot more effort to be in C, to the point where it probably isn't worth it (need function pointers, macros for inheritance).

There's a sort-of interesting talk where Matt Godbolt goes through making the same program in C++ using three different styles (OOP, data-oriented, and functional).
https://www.youtube.com/watch?v=HG6c4Kwbv4I
Last edited on
@Repeater
Take it up with Bjarne.

I think he’s made the relationship between the two crystal clear and I think dhayden and I have been consistent with the same OO principles, especially if you read the quote carefully and read the research paper it came from.

There is nothing to take up.

He's defining OOL.

I'm talking about OOP.

There is no conflict of definition. You're talking about OOL, but for some reason you keep insisting that we redefine OOP, a completely different thing, to match the definition of OOL.
Apologizes for posting such a question in this forum instead of the lounge. I didn’t expect it to bloat to such a discussion.
A language or technique is object-oriented if and only if it directly supports: ...


I'm not talking about OOL (whatever that is), I am however agreeing with Stroustrup when he refers to both a language or a technique, in other words both.

And why wouldn't I agree with him when he presents his case and arguments so well after a great deal of thought and deliberation. Anything but rash opinion. We can safely say he knows what he's talking/writing about.

So far, in the absence of any sensible or valid criticism of his views and the quote, I see no reason to change.

Thank you for your interest. Terimah kasih, in fact.



The lounge in italics, even - does that mean something very serious is happening or about to happen here?
Pages: 123