@@elonmusk7283 From my understanding an Interface is just a special kind of class that consists of virtual functions ONLY.

@@Levelworm No ONLY. You can have any function and any data(int, float, char,...) in your class but if you have at least ONE pure virtual f then that class is kind a interface(you cant Instantiate it).

@@aleksandarfranc1094 You are right! I need to brush up my C++...

@Aleksandar Franc I'd actually call that an abstract class not an interface...

@@martinprochazka3714 It behaves as an interface, but that makes it an abstract class

dude you need a hobby. it is like having a knife and try to cut yourself here and there.

And it set the body to 'return "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"''

@@ezshroom why?

I'm sure the thinking method of your brain class is pure virtual and a subclass has it returning: "Im strange."

@@smileynetsmileynet7922 I am very cool and exemplary. Almost like Jesus.

is 'thinking' a pure method? what i mean by that is that 'thinking' is equal to zero.

same man exact same

You got it clear now?

the same feeling

watch dark docs videos and you won't ever say that again.

@@TheSiprianus Haha. Not only his voice... but the whole video seems speed up to 1.5x speed.

He completely convoluted the topic. Interface are very simple. You just declare a class with pure virtual methods[use virtual keyword and "=0" at the end of function], and then inherit that class/interface, and implement that method.

@@heksogen4788 you just saved me 6mins...

It's late, but If you are new to c++, I recomend watching thenewboston's playlist on c++, then coming back and watching these. They elaborate on the topic very well.

right,except =0 to make it pure

@@heksogen4788 still don't get it! why would i use this? i know the usage of virtual keyword but i don't know to why we use the pure virtual!

Did you finish the series and did you understand? because I'm currently at this episode 28/100 and I'm starting to not understand.

@@ytzzn I'll be honest, I watched several more tutorials, even repeated a few chapters.. I kinda gave up. I switched to the Godot engine and that has been a blast.

​@@Special4ce293 Alr ty

me too. I am not catching up anymore from constructures

@sepehrariaei8123 you have to stop watching these, go and just write like 30 programs in C++ using only the knowledge you have now, and then come back to watch these videos again. Also, these last two videos have been in a poor position in the playlist. Skip these two for now and come back later.

tried to learn cpp in 2020, quit, learn python, quit, back to cpp in 2021 and actually understand the concepts idk why lmfao

@@Laevatei1nn i tried to learn cpp in 2018, quit, went back to learning it again at 2020, quit, back to cpp in 2022 but this time i understand it idk why lmaoo

@@xarki768 same, i went to college this year and learning this definitely pays off

Yes

NICEEEEEEE!!!!!

TheChernoProject You should do that next if you don't have another video planned. It seems really interesting!

All the information you are giving us is already available on the internet so It would be nice for the "not beginners" to get also a good tutorial on complex stuff such as streams, memory management and whatever you think is more advance. Awesome Tutorials!

i was just going to ask him

magic

Let’s say “Entity” has a function named “getAge” that returns an int. “Entity” can either have its own version of the function, or be 'pure' (but not both). for example: version with implementation: virtual int getAge( ) { return 10; } OR “Pure” version: virtual int getAge() = 0; If “ENTITY” declares implementation, then sub-classes (like “Player”) can optionally override or just ignore it. But if “ENTITY” declares as “pure” (virtual int getAge() = 0;) then sub-classes (like “Player”) have the obligation to provide an implementation for themselves.

First. C++ is stupid as heck when it comes to abstract/pure classes. TL;DR create base class, define constructor and virtual destructor as empty `base() {} virtual ~base() {}` (or just leave a default constructor who cares) Then create the pure functions as virtual without a body `{}` and it will fail to compile when you make a class `void pure(int _unused);` However. C++ is AWFUL at doing inheritance and the error messages are terrible. And you can easily "shadow" or "override" virtual function names with no error. It's particularly bad if you make a mistake. To mitigate it you have a few options - Pure specifier. `virtual void pure(int _unused) = 0` the =0 part is the pure specified and will give an error message if it's unimplimented. - Error messages (mainly just clang) `-Werror=overloaded-virtual` will cause a compile error - Override attribute. Tell the compiler you *intend* to override a virtual function and it will error if the definition differs. This is easily one of my least favourite parts of C++ the fact you have to do it at all is madness. It relies on the writer being smart. `void overriden_pure(int _unused) override {}`

Using(Printable obj) makes a copy of that object which can be memory expensive. Thats why (Printable *obj) is a better option since it now points to already existing memory , you could also use (Printable &obj), a reference to Printable obj :D

Mateo G Thank you for explanation =)

difference is that first one is pointer and second is instance. we can't create instance from abstract class, but pointer we can and exactly this is a powerful tool

you‘re all missing the most important point: object slicing. In C++ you have to be super careful with polymorphism, it requires a pointer or a reference. Otherwise the copy constructor gets called and slices your subclass

How does Print() function call private function of A?

Thank you so much for this example. You won't believe how much it helped dude, now I get why interfaces are useful! Your amazing!!

That's actually one of the worst cases to use virtual functions/interfaces or even inheritance IMHO because the code for Windows typically won't build on Mac and vice versa. So even if you make a subtype for Windows and a subtype for Mac of a particular virtual interface, you'll still have to rely on the preprocessor or the build system to filter out all implementation code except the one for the platform being built against, and at that point virtual/dynamic dispatch becomes useless since there's no varying runtime condition/input to use to select which function to call. All that can and should be resolved at compile time. For cross-platform code, it's often much simpler to just use a concrete class, possibly with a pimpl, like so: // Gui.h #pragma once class Gui { public: ... private: class Impl; std::unique_ptr pimpl; }; Then you might have like a 'GuiWindows.cpp' for Windows, 'GuiOsx.cpp' for OSX, maybe one or more for Linux, and have your build system include the right source file(s) based on the platform. Or you might just have a large 'Gui.cpp' with a bunch of #ifdefs/#ifndefs based on the platform we're targeting. The branching occurs at compile-time, so to speak, rather than runtime. It makes no sense to branch at runtime here. This is a job for your preprocessor or your build system, so to speak, not virtual dispatch. Of course, the virtual dispatch might be useful for event-handling or something. You might still put some virtual functions in the Gui class above and allow people to inherit the base class and override those functions. But it makes no practical sense to me to be using virtual dispatch based on the runtime condition of what operating system/platform is being used... at least until operating systems establish enough of a standard that code designed for other operating systems build on a particular system and we have cross-platform binaries (ex: a single binary executable that can be executed on Windows, OSX, and Linux without requiring separate binaries for each target). An example that's still close but where virtual dispatch might be suitable is to select an underlying rendering target. For example, you might create a virtual interface for rendering which abstracts both the capabilities of OpenGL and DirectX in a single abstract interface, then implement one subtype for OpenGL and another for DirectX. That makes more sense because if the user is running Windows, they have both available and might be able to change which one to use at runtime by changing preferences or a config file. In any case, you should generally reserve the use of virtual dispatch for cases where the actual overridden function that is called is based on a runtime condition/user input. Otherwise, it's just a needless overhead both for the programmer (virtual interfaces and ABCs tend to be more clunky to use) and CPU if the actual functions to call can be resolved at compile-time. If this seems a bit confusing just think about where if/else is appropriate first. Would it make sense to write code like this? if (os == windows) { ... } else if (os == osx) { ... } else if (os == linux) { ... } No, right? Typically you'd need to use the preprocessor here to write code that even builds, and the operating system we're using is not a variable that can be changed at runtime. In those cases, virtual dispatch makes little sense. Meanwhile using if/else for render target might make sense: if (render_target == directx) { ... } else if (render_target == opengl) { ... } And likewise, virtual dispatch makes sense as an alternative to the if/else here.

@@darkengine5931 Thanks for the explanation, and thanks for giving an example of when it could be used. I do understand what you said.

2/ -> Everytime you use the "new" operator for dinamyc memory allocation you also need to free that memory manualy with "delete" or "delete[].

Thank you

In Java the difference between Abstract classes and interfaces is pretty much it : Methods of a Java interface are implicitly abstract and cannot have implementations (pure virtual). A Java abstract class can have instance methods that implements a default behavior.

Different implementations of Java Sets for example (HashSet, LinkedHashSet,...) that all have to have some functionality. This functionality is guaranteed by implementing a common interface

I have just had the need to make an interface for the first time ever (when I learned about them I used them but I didn't see why I would use them in those situations, it just seemed unnecessary. I never had a situation where writing my own interface seemed necessary or convenient. I had implemented interfaces that already existed in libraries such as awt and swing and I saw value in those interfaces but I have never had the need to write my own interfaces until now). I was dealing with a Mongo database. I wanted to make a method which will change id of collection members in the database. I want every object in the database to have a unique identification number, I called it pid. So, my method takes as an argument an object which has a pid field and then changes it. How would you write that? How would you tell the compiler that this method receives an object which has a field called pid? By having the method take an instance of the interface as the argument. Interface has getPid and setPid methods. If you don't do that, you will have to write separate methods for every single class that you want to put in your database. I wrote this in Java and I used generics (if you were to do this in C++ you would use templates, they are similar to generics in Java).

Another example where you can write your own interface is if you write your own Event Object. Event Objects hold references to bunch of objects. Those objects are called event listeners. When some event happens the event object activates a certain method of its event listeners. That's why they are called event listeners, they will be "told" when an event happens, because the event object will activate their method. We would like objects of various classes to be event listeners, so we use an interface. For instance, interface has a method itIs7Am() and all object listeners implement that interface. If you have a class employee, they implement it by going to a job, class student implements it by going to university, class Bird implements it by starting to sing. Event object will activate the method itIs7Am of all of its listeners even though its listeners belong to various different classes and they implement this method in very different ways. Examples for when you use an interface which was already written can also be event listeners, like ActionListener interface in Java awt library which is used a lot. When button is pressed, it activates action Performed method of all of its listeners. All of its listeners have the method actionPerformed because they implement interface ActionListener, even though they implement the method actionPerformed in various different ways.

The method that I wrote goes like this public void changeId(MongoCollection mgCollection, int pidIncrease){ for(T object : mgCollection.find()){ int pid = Integer.parseInt(object.getPid()); int newPid = pid + pidIncrease; Bson QUERY = Filters.eq("pid", String.valueOf(pid)); Bson UPDATE = Updates.set("pid", String.valueOf(newPid)); mgCollection.updateOne(QUERY, UPDATE); } } I am going through collection and changing pid of members. This method will work for collection of any objects in the database, because I only have collection of objects which implement PidInterface and I have getPid method in the PidInterface. I can have objects of various different classes in the database but they all need to implement PidInterface so that I can do operations on them. As you can see, the method which does operation on those objects in the database (changes their pid in this case) receives a MongoCollection which is made out of objects that implement the PidInterface. If I don't use an interface I would have to write a separate method for each class whose instances are in the database.

it is virtual although the keyword isn't there ( you can add it for more clarity).

I doubt he would do any videos on malloc() and free(), as those are functions in the C Standard Library for dynamic memory allocation. In C++ you would use the 'new' and 'delete' keywords instead, or smart pointers (which he has a video for). That's not to say you can't use malloc() and calloc() and free(), but you probably shouldn't as new and delete keywords are cleaner.

you're not setting anything to zero, it's just a part of c++ syntax. if you'll get used to it, you'll be able to read c++ code like shown in this video with ease.

Because it is old language and I think the concept of interface wasn't really clarified at that moment. I don't know if it's in new C++ releases though, if not, then maybe it's for backwards compatibility reasons.

Well, you COULD if you want to define interface yourself with "#define interface struct" and everytime you write interface it will become a struct (class with public variables as standard). As a new-ish person to C++ I have no idea if this would have SOME kind of negative income, but I tried it out and it works. I'd guess maby compiling-time increases **slightly** but meh. /shrug

RadiationAlert N/A Doing it like this allows you to define some methods in the "interface" by not adding an "=0" at the end of some functions.

+valrossenOliver, yes, "#define interface struct" is generally a bad idea, because c-style macros are dangerous, obscuring, and hard to debug. there's tons and tons of articles about how bad it can get when a person uses too many #define macros, look it up. compiling time will not be affected at all (well, actually, preprocessor will have to do more work substituting every occurrence of "interface" to "struct" in your code).

@PeterolenThanks for your explanation! I overlooked the drawback of having a private constructor. It's obvious now that you mention it. I'll have to check out more on the public/private/protected inheritance as it seems like a topic that would contain a reasonable level of complexity. Thanks again :)

I have just had the need to make an interface for the first time ever (when I learned about them I used them but I didn't see why I would use them in those situations, it just seemed unnecessary. I never had a situation where writing my own interface seemed necessary or convenient. I had implemented interfaces that already existed in libraries such as awt and swing and I saw value in those interfaces but I have never had the need to write my own interfaces until now). I was dealing with a Mongo database. I wanted to make a method which will change id of collection members in the database. I want every object in the database to have a unique identification number, I called it pid. So, my method takes as an argument an object which has a pid field and then changes it. How would you write that? How would you tell the compiler that this method receives an object which has a field called pid? By having the method take an instance of the interface as the argument. Interface has getPid and setPid methods.

yes, thanks for that.

Cheers for helping ppl but vid is 4 years old, doubt he reads comments that much.

Also, assuming I understood correctly; if a child's (parent class) inherits an interface, the child class will also be able to implement the interface's methods without having to inherit the interface as well.

@Peterolen first of thank you for the reply and second thing is that you won't believe it but right now I'm watching your c++ series video

Here is my example for when using an interface is useful. I have just had the need to make an interface for the first time ever (when I learned about them I used them but I didn't see why I would use them in those situations, it just seemed unnecessary. I never had a situation where writing my own interface seemed necessary or convenient. I had implemented interfaces that already existed in libraries such as awt and swing and I saw value in those interfaces but I have never had the need to write my own interfaces until now). I was dealing with a Mongo database. I wanted to make a method which will change id of collection members in the database. I want every object in the database to have a unique identification number, I called it pid. So, my method takes as an argument an object which has a pid field and then changes it. How would you write that? How would you tell the compiler that this method receives an object which has a field called pid? By having the method take an instance of the interface as the argument. Interface has getPid and setPid methods.