- Prohibit calling a function with a derived class object - 2 Updates
- Why not designated initializers in C++? - 3 Updates
- initializer_list member and constexpr - 1 Update
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 21 09:25PM +0100 On 21/07/2016 21:06, Paavo Helde wrote: > potential signatures is large. Passing an array of some Variant type > would work, but this would make the class code clumsier and more fragile > than necessary. The Liskov substitution principle always works if you follow it. You are DOING IT WRONG (TM). /Flibble |
Paavo Helde <myfirstname@osa.pri.ee>: Jul 22 01:41AM +0300 On 21.07.2016 23:25, Mr Flibble wrote: > The Liskov substitution principle always works if you follow it. You > are DOING IT WRONG (TM). Liskov principle says that a derived class must always be fully functional when accessed via base class interface. That's no problem with my classes. Instead, my problem is that because of callback mechanism the base class object might be accessed via derived class interface, and Liskov principle does not say anything about this. To clarify: my Base and Derived correspond roughly to std::vector::const_iterator and std::vector::iterator. Derived is derived from Base so that casting a pointer/reference of Derived to a pointer/reference of Base would always work seamlessly/automatically, *including* with arrays of Derived (I am guaranteeing sizeof(Derived)==sizeof(Base)). That's Liskov in work, BTW - a mutable object can always be accessed via a non-mutable interface as well. However, regarding arrays of derived class objects - this is where C++ fails hard if the sizes are not the same (and I suspect it might be formally UB even if sizes are the same(?)). So it appears C++ itself has some troubles with supporting Liskov (in arrays of objects). Here is some example code about what I mean by a Liskov substitution of an array: #include <vector> void foo(std::vector<int>::const_iterator* array, int len) { int x = *(array[len-1]); } int main() { std::vector<int> test = {1, 2, 3}; std::vector<int>::iterator arr[3] = {test.begin(), test.begin()+1, test.begin()+2}; foo(arr, 3); } Curiously, MSVC derives std::vector::iterator from std::vector::const_iterator so it compiles and runs this example fine, but g++ does not (effectively failing Liskov): main.cpp: In function `int main()': main.cpp:33:12: error: cannot convert `std::vector<int>::iterator* {aka __gnu_cxx::__normal_iterator<int*, std::vector<int> >*}' to `std::vector<int>::const_iterator* {aka __gnu_cxx::__normal_iterator<const int*, std::vector<int> >*}' for argument `1' to `void foo(std::vector<int>::const_iterator*, int)' foo(arr, 4); |
Ian Collins <ian-news@hotmail.com>: Jul 22 08:35AM +1200 On 07/22/16 04:50 AM, Mr Flibble wrote: >> C++ is the topic of this group. > Ian, it seems obvious to me that Jerry Stuckle is a fucktarded troll so > why do you engage it? Possibly for the same reason you engage Ramine! -- Ian |
woodbrian77@gmail.com: Jul 21 01:44PM -0700 On Wednesday, July 20, 2016 at 7:18:48 PM UTC-5, Chris Vine wrote: > mistake. You however have had the benefit of having the point about > aggregates explained to you in other posts and you still manage to miss > the point. My point is that dictionary definitions of aggregate are relevant. The history/roots have to be considered or those working on the standard end up navel-gazing -- focused on their own thoughts and feelings. Proverbs 3:5,6 says: "Trust in the L-RD with all your heart and lean not on your own understanding. In all your ways submit to Him and He will make your paths straight." > Given that you think you have some kind of > messianic call with respect to leadership of C++ My offer http://webEbenezer.net/about.html to help someone who is willing to use my software in their project could provide life-saving encouragement to someone who needs help developing their ideas. They can refer themselves and get both some cash and a coworker. G-d has blessed me to be a blessing. So when I say "life-saving encouragement" it's from G-d, not me. I'm just a messenger being shot at frequently here. Many have forgotten -- "don't shoot the messenger." > post at > http://comp.lang.cpp.narkive.com/q0Yuq9Cf/comments-on-interview-of-scott-meyer > ) I imagine you have your analysis pre-prepared for us to read. C++ 2017 is a disappointment in my opinion. Std::any, anyone? Brian Ebenezer Enterprises - If you can't join 'em, beat 'em. http://webEbenezer.net |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 21 11:18PM +0100 On Thu, 21 Jul 2016 13:44:44 -0700 (PDT) > On Wednesday, July 20, 2016 at 7:18:48 PM UTC-5, Chris Vine wrote: >> On Wed, 20 Jul 2016 15:53:10 -0700 (PDT) >> woodbrian77@gmail.com wrote: [snip] > relevant. The history/roots have to be considered or those > working on the standard end up navel-gazing -- focused on > their own thoughts and feelings. Sorry Brian, you are still wrong. The point you haven't grasped is that these types are called 'aggregates' in the C standard, and it would be highly misleading to call them anything else in the C++ standard because they are types which can be initialized in C++ in the same way that 'aggregates' can be in C. They are part of the C interface which is accepted in C++, for very good reason. That was a decision that the C++ standard committee took in full knowledge of the background and not as a consequence of (your pathetic reference to) "navel gazing". There are things wrong with C++, mainly because of the piece-meal organic way in which development of it has (of necessity) taken place. But it annoys me that someone without much of a clue like you can mouth off about "detachment from reality", particularly given some of your postings to this group. I would not trust your judgement on any matters relating to C++, and for that matter on your various off topic nonsense on this group as well. |
Ian Collins <ian-news@hotmail.com>: Jul 22 08:39AM +1200 On 07/22/16 02:30 AM, Juha Nieminen wrote: >> I think clang is correct. { 1, 2, 3 } is a temporary initializer_list >> object. > If that's so, why doesn't it complain about the kB initialization? Because there the initialiser list is being directly initialised, not being passed as a constructor parameter. -- Ian |
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