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

New comment
 
Alexey Navoykov:

I would have done it this way:

I find this style uncomfortable. That is to say, it comes down to 'felt-tip pens'.

 
fxsaber:

So you want warnings too? What is this double standard: in both places the behaviour is unambiguous, but with brackets you are against warnings and here you are in favour?

You need a warning so that you don't make hard-to-find mistakes. So difficulty is a subjective assessment. So with brackets you don't make mistakes, and here you can. And for me it's vice versa.

So which one of us should the rules for issuing warnings be adjusted to?

You seem not to understand the point. Dynamic casting must always be an explicit operation. In any normal language, be it C++, C#, Java or any other OOP language, such code will not compile. This is the basis of reliable OOP. But it was forgotten here for some reason. I didn't think the bracket comparison was appropriate here at all.

 
Alexey Navoykov:

The basis of the fundamentals of a reliable OOP.

The basis in unambiguity.

 
Ilya Malev:

I don't see the point of reference code (although I don't use standard libraries either). If putting an object into an array involves creating a copy of it, then the assignment method or copy constructor must be declared and described explicitly in this class, otherwise no wrappers will help anyway. If you only need to put a reference to an object into an array, you don't need any wrappers at all (why?).

What do you need such an array for? Because it's almost analogous to a plus vector, it should work like vector<int>, vector<class_name>, vector<class_name*>. If you can implement it without wrapping by means of µl, good for you (I don't think you can). You have no way to run through array and call destructors ( _data[i].~Destr() ), no partial specialization and no SFINAE tricks. This wrapping makes the array suitable for pointers to objects in the heap without breaking the possibility of working with vector<int>, for example.

vector<unique_ptr<my_class>> v1;

vector<my_class> v2;

vector<int> v3;

ZS: what to say, vector<class_name*> will not work as expected even in pluses (destructor call at the end of vector's life) there also need wrapping.
 
pavlick_:

ZS: what to say, vector<class_name*> won't work as expected even in pluses (destructor call at end of vector's life) it needs wrapping too.

Will that work? )

template<typename T>
void del(T par){printf("%s не удаляем",typename(T));}

template<typename T>
void del(T *par){printf("%s удаляем",typename(T));delete par;}

class A{public:void~A(void){printf("удаляем %i",&this);}};

void OnStart()
 {
  int var1;
  A *var2=new A;
  del(var1);
  del(var2);
 }

P.S. By analogy, a function can return anything instead of void, and no SFINAE is needed.

 
Yes, that's fine. But we still need a wrapper: we need a universal array, so sometimes it has pointers that need to be deleted, and sometimes not (well, just a set of pointers - the result of finding something in another array).
 
pavlick_:

On the plus side, deleting void* is UB.

By the way, I haven't even thought about it before, thanks for the tip. It turns out that delete in this case is similar to free(). It should be forbidden, since delete is positioned for objects and it simply frees memory bypassing rules.

Although destructors are called here too, but in case of porting code to C++ one may encounter troubles.

 
pavlick_:
Yeah, that'll do. But we still need wrapping: after all we need universal array, so sometimes it has pointers that need to do delete, and sometimes not (well, just a bunch of pointers - the result of finding something in another array).

Well, no one forbids to pass additional option when creating an array - whether to delete elements when deleting it or not, and make it on or off by default (to your liking). After all, you can never guess if you want to delete items or not)).

P.S. By the way, wrapping a pointer before putting it into an array won't solve the question of whether or not you need to delete its base object when deleting the array))
 
fxsaber:

The additional brackets have completely eliminated the influence of language priorities. Everything becomes completely unambiguous. This makes it 100% reliable that nothing will break after the next build.

With this in mind I shall summarize:


A100
Developers
fxsaber
brackets
only in places where they are indispensable
maybe even in places where MQL4 was different before
they are needed everywhere
unnecessary warnings
not necessary
only in places where MQL4 was different before
needed everywhere
priorities
is required
required
not necessary in principle (because brackets replace them)

If I have not stated it correctly - please correct me - I have made my concept short and unambiguous where warnings about brackets are needed

 
Ilya Malev:

Well, no one forbids to pass additional option when creating an array - whether to delete elements when deleting it or not, and make it on or off by default (to your liking). Because it's hard to guess, should you delete items or not)).

In general, yes, you can do it that way.

P.S. By the way, just because you wrap a pointer before putting it into an array, the question of whether you need to delete its base object or not when deleting the array won't get any clearer))


If you don't wrap it, you don't delete it, if you wrap it, you delete it, it's crystal clear.

ZS: but if I did, I'd do as similar as possible to the standard plus library (names, behaviour, etc), so no choice for me. Why bother creating another spec when everything is already written?

1234567891011121314...20
New comment
Reason: