| Thiago Adams <thiago.adams@gmail.com>: Oct 13 07:05AM -0700 On Saturday, October 13, 2018 at 10:45:00 AM UTC-3, Thiago Adams wrote: > visit(f, a); > } > } This is the way I do today (using my transpiler http://thradams.com/web/cprime.html ) struct Bee { int tag /*= 1*/; }; void Bee_talk(struct Bee* p) { printf("buzz"); } void Bee_serialize(struct Bee* p) { printf("serialize"); } struct Bear { int tag /* = 2*/; }; void Bear_talk(struct Bear* p) { printf("growl"); } void Bear_serialize(struct Bear* p) { printf("serialize"); } struct Bird { int tag /* = 3*/; }; void Bird_talk(struct Bird* p) { printf("chirp"); } void Bird_serialize(struct Bird* p) { printf("serialize"); } struct /*Bee | Bear| Bird*/ Animal { int tag; }; //This function is managed by the transpiler void Animal_talk(struct Animal* p) /*default*/ { switch (p->tag) { case 3: Bird_talk((struct Bird*)p); break; case 2: Bear_talk((struct Bear*)p); break; case 1: Bee_talk((struct Bee*)p); break; default: break; } } struct Car { int tag /*= 4*/; }; void Car_serialize() { printf("serialize"); } struct /*Animal | Car*/ Item { int tag; }; //This function is managed by the transpiler void Item_serialize(struct Item* p) /*default*/ { switch (p->tag) { case 3: Bird_serialize((struct Bird*)p); break; case 2: Bear_serialize((struct Bear*)p); break; case 1: Bee_serialize((struct Bee*)p); break; case 4: Car_serialize((struct Car*)p); break; default: break; } } //Not possible because Car_talk doesn't exists //void Item_talk(struct Item* p) /*default*/; int main() { } Having some similar feature in the C++ compiler also would require cast analysis. static_cast and dynamic cast could have an especial version for this kind of object. The dynamic_cast would allow only objects that are listed as possible. I have a name for 'closed polimorphism' where all classes are know and 'open polimorphism' where we don´t know all classes that implement some interface like 'plugins'. 'closed polimorphism' can be implemented in this way and 'open polimorphism' must use interfaces. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 13 05:46PM +0100 On 13/10/2018 09:19, Juha Nieminen wrote: > Why shouldn't interfaces have member variables? Just because other > languages don't support them? Why limit yourself, and let yourself > be governed by the limitations of other languages? Of course there is nothing to stop you adding member variables it just can no longer be described as an "interface" (idiomatically at least) it would then be just an abstract base class. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Öö Tiib" <ootiib@hot.ee>: Oct 13 10:03AM -0700 On Saturday, 13 October 2018 16:45:00 UTC+3, Thiago Adams wrote: > be inside the object. > I can say Animal is a pointer to Dog or Cat. It doesn't hold dog > or cat memory . I cannot instantiate an Animal object, just a pointer. That concern is also already solved since one can certainly use std::variant<Dog*,Cat*> if they so wish. > } > }; > using Items = std::variant<Animal, Car>; The issue here is that std::variant<Animal, Car> is not same as std::variant<Bee, Bear, Bird, Car> like you seemingly expect. If there is desire to merge type lists of two variants then that takes some meta-programming with variadic templates. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 13 05:47PM > Of course there is nothing to stop you adding member variables it just can > no longer be described as an "interface" (idiomatically at least) it would > then be just an abstract base class. So it works exactly like an interface, and is used exactly like an interface, and serves the exact same role as an interface, but it can't be called an interface because it happens to have some member variable (which might even be private so it isn't even visible from the outside)? |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 13 08:39PM +0100 On 13/10/2018 18:47, Juha Nieminen wrote: > can't be called an interface because it happens to have some member > variable (which might even be private so it isn't even visible from > the outside)? Correct, it doesn't work exactly like an interface if it has member variables. Also interface methods cannot have an implementation having private member variable would serve no purpose. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Bo Persson <bop@gmb.dk>: Oct 13 10:31PM +0200 On 2018-10-13 19:47, Juha Nieminen wrote: > can't be called an interface because it happens to have some member > variable (which might even be private so it isn't even visible from > the outside)? Yes, it apparently violates the "pure" part. :-) I some other languages we know we have to do the interface part separately and then perhaps add a default implementation as a separate layer in a derived class. C++, being a multi-paradigm language, will let you do it all in one class. And it even allows you multiple inheritance from several non-pure base classes. Heresy or just being practical? Bo Persson |
| Juha Nieminen <nospam@thanks.invalid>: Oct 13 08:52PM > Correct, it doesn't work exactly like an interface if it has member > variables. Also interface methods cannot have an implementation having > private member variable would serve no purpose. What exactly is the advantage of such interfaces, compared to "interfaces" with function implementations and perhaps even member variables? I don't see any practical (or otherwise) difference from the perspective of a piece of code that wants an object that implements a given "interface". Why should that code care whether the implementation is (partially) in the interface class itself or in a derived class? (After all, usually this kind of code doesn't even know, nor care, what the actual class of the object behind that pointer/reference is. So why should it care whether some function implementation is in the interface or that derived class? In what situation could it even make that distinction, even if for some unfathomable reason it would want to care about the difference?) |
| JiiPee <no@notvalid.com>: Oct 14 12:04AM +0100 On 13/10/2018 21:31, Bo Persson wrote: > Yes, it apparently violates the "pure" part. how about naming them "pure interface" and "interface"? that would give space for both point of views. I kinda think if something looks like an interface, acts like an interface it probably is an interface . We do the same "class" interface: class is not defined clearly, but we accept that if it looks roughly like an class we can call it class. See: class Dog { public: .. private: int age; }; // in the same file: void printAge(Dog& dog) { // get dogs age and print } now printAge is not inside class but many see it part of the class interface (because it is in the same file and delivered with class Dog). But its not 100% clear whether it should belong there or not....there surely are many functions which we are not 100% sure if they belong to this class interface or not. |
| Horizon68 <horizon@horizon.com>: Oct 13 12:05PM -0700 Hello, Read this: About C++ and Delphi and FreePascal generic (template) style containers.. Generics.Collections of Delphi and FreePascal for generic (template) style containers that you can download from here: https://github.com/maciej-izak/generics.collections TList of Generics.Collections of Delphi and FreePascal is implemented the same as STL C++ Vectors: they are array-based. And since data structureS are the same then also performance should be comparable. So I've done a small test between Tlist of Generics.Collections of Delphi and FreePascal and C++ vector, it's an addition of 3000000 records of 16 byte length, in one loop, here is the results: Tlist time = 344ms Vector time = 339ms It seems they are the same, the test use only the function ( List.add , vector.push_back). STL vectors with the at() and Delphi TList of Generics.Collections of Delphi and FreePascal perform bounds checking. Thank you, Amine Moulay Ramdane. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 13 07:13AM -0700 On Saturday, 13 October 2018 16:03:58 UTC+3, Alf P. Steinbach wrote: > the case of > * defined by the standard, but not implemented or incorrectly > implemented by at least one major compiler. That does also happen and sometimes such defects won't be fixed for decade but usually it helps when to wait for about two years before using some new feature in production code. Otherwise the difficulties will be similar but accusations will be reverted: "Who cares what standards say? We need to deliver working programs!" > default settings of a Visual Studio project, because with the Visual C++ > option for "Program Database for Edit and Continue", `/ZI`, Visual C++ > expanded `__LINE__` to some gobbledygook, not valid in an identifier. Somehow it seems changed, or I can't find __LINE__ in it. > that matter, Andrei never agreed that it was a programming defect to > just silently swallow exceptions in the Scope Guard cleanup code. And > nobody now (well except me) remembers Petru Marginean... :) Oh, he likely got tired of being public guru and works on some sort of investment banking or cryptocurrency project. > Notes: > ¹ <url: > http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758> Yes that one ... where they use __LINE__ there? |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 13 05:20PM +0200 On 13.10.2018 16:13, Öö Tiib wrote: >> ¹ <url: >> http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758> > Yes that one ... where they use __LINE__ there? The source code was available as a .zip file. The article was not a description of a technique. It was a description of a ready-to-use mini-library, that later was incorporated into the Loki library. The code was in two parts: Petru's original Scope Guard implementation, which Andrei had helped improve, and some higher level wrapper stuff by Andrei only, as I understood it. Alas, it seems that the source code has been removed. At least it's not in this list: <url: http://www.drdobbs.com/archives/sourcecode/2000>. Cheers!, - Alf |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment