[CLOSED] : Compiler bug with template parameter = void* - page 17
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Was there a pyramid code of supporters by any chance? If anything, I'll be the first. )))))
Was there a pyramid code of supporters by any chance? If anything, I'll be the first. )))))
This could be attributed to the horizontal code supporters' camp.
This can be attributed to the horizontal code supporters' camp.
I agree, it was a poor effort. The best examples were so transcendent that they did not survive the transition to our mortal reality...
Was there a pyramid code of supporters by any chance? If anything, I'll be the first. )))))
This is an obfuscation.
It's an obfuscation.
Yeah, I'm a long way from you. I have, so to speak, something to strive for ))
In general, yes, you can do that.
If without wrapping, it is not deleted, with wrapping, it is deleted, everything is crystal clear.
ZS: but if I did, I'd do it 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?
- Creating automatic structures within dynamic OOP is nonsense
- Dynamic structures should be divided into those created for a specific process (like a query on a selection) or as a selection from an existing set of elements (and there can be mixed types)
- So far I can see a solution in accounting number of "own" references to an object, it's not necessary to create wrappers on it (not really sure how that would solve the problem), but I would have to duplicate pointer mechanism already existing in µl, adding my methods to them, at least including reference counter (it was discussed in your article from hubra by the way, I was just reading it a couple days ago, when I was looking for solution about pointers and realized I already came to the same solution myself).
- I'll try to realize it all, if something worthwhile comes out, I'll post it on the forum and/or in kodobase anyway :).
- Creating automatic structures within a dynamic OOP is nonsense
- Dynamic structures should be divided into those created for a specific process (like a query on a selection) or as a selection from an existing set of elements (and there can be mixed types)
- So far I can see a solution in accounting number of "own" references to an object, it's not necessary to create wrappers on it (I can't really see how that would solve the problem), but I have to duplicate mechanism of pointers already existing in µl, adding my methods to them, at least including reference counter (it was discussed in your article from hubra by the way, I was reading it just a couple days ago, when I looked for solution about pointers and realized I already came to the same solution myself).
- I'll try to implement all that and if something good comes out of it, I'll post it on the forum and/or in kodobase anyway :)
Very interesting. Tired of pi@#$holes.
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)).
So you've written such an array and get a surprise: how to disable the copying operator=() and copying constructor (by default it's absent in µl anyway) in an array of pointers that require deletion? This will make it clear that the parameter via constructor is junk. Two ideas will arise:
1. pass the type with the deleted statement through the template parameters and make it a member of the class (and that's an unnecessary waste of resources).
2. pass a pointer in a wrapper :) (yes, yes - that damn wrapper).
3. you could use partial specialization to get out of it, but there is none.
In general the plus library is a masterpiece, if you think you can write better, you're probably wrong.
0. So you've written such an array and end up with a surprise: how to disable copying operator=() and copying constructor (by default it's not in µl anyway) in an array of pointers that require deletion? This will make it clear that the parameter via constructor is junk. Two ideas will arise:
1. pass the type with the deleted statement through the template parameters and make it a member of the class (and this is an unnecessary waste of resources).
2. pass a pointer wrapper :) (yes, yes - that damn wrapper).
3. you could use partial specialization to get out of it, but it's not there.
In general the plus library is a masterpiece, if you think you'll write better, you're probably wrong.
Most likely it is, and it is a masterpiece, but written for a much wider range of tasks than needed to build most sensible TCs. I don't consider variants like neural networks, using graph processor and other dances with tambourines.
0. I told you that the dynamic already created objects are transferred. This is either objects specifically created for selection (you have to delete them later), or references to objects which are used but not deleted. The list object is not responsible for creating. only for addressing, accessing and storing as long as it's needed.
1. ...
2. ...
3...
In short, you need to consider specific detailed tasks, not abstract ones. If you have to write some gui, that's not what I mean either. Some guy in a nearby thread seems to have written a nice gui using pure structures.)