[CLOSED] : Compiler bug with template parameter = void* - page 19

New comment
 
pavlick_:

Self-destruct? - that's new :).

Yeah, self-destruct. I assume you are aware that this is the difference between "stack" objects and dynamic objects - they don't ask you when to delete themselves, they do it when they exit the originating program block :)
 
Ilya Malev:
Yep, self-destruct. I assume you are aware that this is the difference between "stack" objects and dynamic objects - they don't ask you when to delete themselves, they do it when they exit the originating program block :)

You've probably heard of copy/move constructors/operators, right?

obj o;
{
   obj q;
   o = q;
   o = move(q);  // С++ вариант, более эффективный
}
 
pavlick_:

You've probably heard of copy/move constructors/operators, right?

So we'll be on the lookout for that crucial moment and copy it that way, if only we're not too late? :lol:

Just because we really don't like OOP, or are there other ulterior reasons?

 
Ilya Malev:

So we'll be on the lookout for that crucial moment and copy it that way, if only we're not too late? :lol:

Just because we really don't like OOP, or are there other ulterior reasons?

Of course, how else could there be? You as a decent proger must manage dynamic objects via stack ones too (RAII technique)

{
   unique_ptr<Class> p(new Class);
   ...
   // ой, самоуничтожение :)
}
 
And we'll make a lot of wrappers for it, damn it. Because the niche of polymorphism is not so significant, but our crutches have a whole field of application, if we don't use OOP :cry:
 
pavlick_:

Of course, how else could it be? As a decent proger, you have to manage dynamic objects via stack objects as well (RAII technique).

Do you mean the rubbish collector? )))) or about counting number of references. i've been practicing these things lately. but performance of all these approaches is lame in µl unfortunately

 
To manage din.objects via stack ones means to allocate ADDITIONAL 24 bytes of memory for each object (this is how much such "stack pointer "+reference to the object itself will "weigh"). Plus the time cost in terms of speed is not small at all. All this is rather sad on the whole. But we don't feel a great need in it either. As they say, fear hath a great many eyes. If we were programming space stations, then you could not do without strict control. But as it is, with a fine-tuned class system, everything works just fine without it.
 

No, not about rubbish collector, but about smart pointers - unique_ptr, shared_ptr (with reference counting), RAII easily googled. Generally there is no extra cost for unique_ptr in terms of memory (wrapper == pointer size), and calls are over-optimized, but in µl everything is sad, yes. But it's not needed here either (smart pointers).

 
pavlick_:

Or you could take the templates and write something like:

https://www.mql5.com/ru/forum/295485/page18#comment_9971363

Button is also detail-independent, without all the polymorphism and interfaces. Polymorphism has its own niche, but it is much narrower than they say.

In such a simplified example, the template certainly looks more convenient. In fact, you don't even need a template there, since you only have one instance.

 
Alexey Navoykov:

This simplified example certainly makes the template look more convenient. In fact, you don't even need a template there, since you only have one instance.

Button lamp via g with virtuality:

struct SwitchableDevice {
    virtual void switchOn() = 0;
    virtual void switchOff() = 0;
};
struct Lamp : SwitchableDevice {
    void switchOn(){std::cout << "shine bright" << std::endl;}
    void switchOff(){std::cout << "i am not afraid of the dark" << std::endl;}
};
struct Button {
    SwitchableDevice& dev;
    bool state = false;
    Button(SwitchableDevice& d) : dev(d) {}
    void buttonPress(){
        if (state) { dev.switchOff(); }
        else       { dev.switchOn();  }
        state = !state;
    }
};
int main(){
    Lamp lamp;
    Button button(lamp);
    button.buttonPress();
    button.buttonPress();
}

hackneyed examples.

1...121314151617181920
New comment