Tuesday, December 13, 2016

Digest for comp.lang.c++@googlegroups.com - 23 updates in 5 topics

Juha Nieminen <nospam@thanks.invalid>: Dec 13 07:26AM

>> possible with linked lists after the first partition, but requires
>> extra bookkeeping.)
 
> If by "works" you mean "works slowly, O(n)".
 
Its asymptotic behavior is exactly the same for linked lists as it is
for random access arrays. There's nothing in the basic quicksort algorithm
that requires random access.
 
Maybe you missed the part where I said that quicksort is one of those
classical quintessential examples in languages where linked lists are
the basic data container? Maybe your problem is that you just don't
know how to implement quicksort for linked lists. It's quite easy,
really.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 13 05:51PM

On 13/12/2016 07:26, Juha Nieminen wrote:
> the basic data container? Maybe your problem is that you just don't
> know how to implement quicksort for linked lists. It's quite easy,
> really.
 
Wrong. Quicksort will be worse than O(n . lg n) for linked lists.
 
/Flibble
Tim Rentsch <txr@alumni.caltech.edu>: Dec 13 02:52PM -0800

>> know how to implement quicksort for linked lists. It's quite easy,
>> really.
 
> Wrong. Quicksort will be worse than O(n . lg n) for linked lists.
 
Maybe you mean something different by quicksort in this context.
A properly implemented quicksort - meaning, select a pivot
element, partition the list into sublists that are less than,
equal to, and greater than the pivot element, recurse on the
two sublists that are not equal, and join the resulting sorted
lists into a single list - will have the same asymptotic order
(ie, within a constant factor) as does quicksort on an array.
 
This isn't the best way to sort linked lists, but it does have
the same order as array-based quicksort.
Ralf Goertz <me@myprovider.invalid>: Dec 13 09:07AM +0100

Am Sun, 11 Dec 2016 15:02:47 +0200
> > am I supposed to initialise a constant reference cr in my class?
 
> What they are trying to say is that such constructors should be
> declared with the 'explicit' keyword.
 
That's what I thought at first, too but then how can this be a
satisfactory answer to the question
 
What is 'X(const int &cr_) : cr(cr_),var(0) {}'?
 
Anyone who knows what
 
explicit X(const int &cr_) : cr(cr_),var(0) {}
 
means, surely knows what to make of that statement without the
„explicit" keyword. And secondly, I was giving a minimal example of my
problem with the *assignment* operator. Having the constructor made
explicit wouldn't have changed anything and would have made the code
longer (less minimal ;-)). Therefore I assumed Öö had something else in
mind.
Paavo Helde <myfirstname@osa.pri.ee>: Dec 13 12:08PM +0200

On 13.12.2016 10:07, Ralf Goertz wrote:
 
> That's what I thought at first, too but then how can this be a
> satisfactory answer to the question
 
> What is 'X(const int &cr_) : cr(cr_),var(0) {}'?
 
I guess this was not an answer to the original question, but rather
another remark which the poster considered worthwhile to share.
 
> explicit wouldn't have changed anything and would have made the code
> longer (less minimal ;-)). Therefore I assumed Öö had something else in
> mind.
 
Welcome to Usenet! Longest threads covering philosophy, religion, etc
often start from some silly question like how many spaces a tab must be.
 
Cheers
Paavo
Juha Nieminen <nospam@thanks.invalid>: Dec 13 01:16PM

> }
> return *this;
> }
 
That looks like a really ugly way of getting around the
non-assignability of references. Is it even supported by the standard?
Paavo Helde <myfirstname@osa.pri.ee>: Dec 13 03:49PM +0200

On 13.12.2016 15:16, Juha Nieminen wrote:
>> }
 
> That looks like a really ugly way of getting around the
> non-assignability of references. Is it even supported by the standard?
 
Yes, it is supported. There is even a verbatim example featuring the
very same "operator=" and "new (this)". See 3.8/7:
 
"If, after the lifetime of an object has ended and before the storage
which the object occupied is reused or released, a new object is created
at the storage location which the original object occupied, a pointer
that pointed to the original object, a reference that referred to the
original object, or the name of the original object will automatically
refer to the new object and, once the lifetime of the new object has
started, can be used to manipulate the new object, if ..."
 
I snipped some sanity checks like requiring same type and most derived
object etc. One must also take care with exceptions as discussed
else-thread.
 
Cheers
Paavo
 
PS. I agree this is ugly and error-prone and one should not use this
unless there is no other way.
Melzzzzz <Melzzzzz@zzzzz.com>: Dec 13 02:05PM

> started, can be used to manipulate the new object, if ..."
 
> I snipped some sanity checks like requiring same type and most derived
> object etc.
 
How would you check that?
 
One must also take care with exceptions as discussed
 
--
press any key to continue or any other to quit...
"Öö Tiib" <ootiib@hot.ee>: Dec 13 08:02AM -0800

On Tuesday, 13 December 2016 16:05:53 UTC+2, Melzzzzz wrote:
> On 2016-12-13, Paavo Helde <myfirstname@osa.pri.ee> wrote:
 
<snip>
 
> > I snipped some sanity checks like requiring same type and most derived
> > object etc.
 
> How would you check that?
 
C++ has whole whopping RTTI available. It can be very useful in
debug checks. Example teaser program:
 
#include <iostream>
#include <typeinfo>
 
// base
struct B
{
B() = default;

virtual ~B() = default; // something virtual to turn on RTTI

B& operator=(const B& that) // assignment we test
{
// just to visualize it; object slicing actually
// deserves major *ABORT* here.
std::cout << (typeid(*this) != typeid(that) ? "wtf\n"
: "ok\n");
return *this;
};
B (B const&) = delete; // because of rule of 3
};
 
// derived
struct D : public B {};
 
int main()
{
B b;
B b2;
b = b2; // ok
D d;
b = d; // wtf
B& dRef{d};
dRef = b; // wtf
D d2;
dRef = d2; // ok
}
Paavo Helde <myfirstname@osa.pri.ee>: Dec 13 07:57PM +0200

On 13.12.2016 16:05, Melzzzzz wrote:
 
>> I snipped some sanity checks like requiring same type and most derived
>> object etc.
 
> How would you check that?
 
By "sanity checks" I actually meant the numerous clauses written in the
standard in the "if ..." section after the above quote. But one can
protect the code against some misusage also automatically. The simplest
way to ensure that the object is the most derived object is do declare
the class as 'final'.
 
Cheers
Paavo
Melzzzzz <mel@zzzzz.com>: Dec 13 07:01PM +0100

On Tue, 13 Dec 2016 08:02:55 -0800 (PST)
> D d2;
> dRef = d2; // ok
> }
 
What about multiple inheritance? Is it ok then to assign d to d?
 
 
--
press any key to continue or any other to quit...
Melzzzzz <mel@zzzzz.com>: Dec 13 07:02PM +0100

On Tue, 13 Dec 2016 19:57:38 +0200
> can protect the code against some misusage also automatically. The
> simplest way to ensure that the object is the most derived object is
> do declare the class as 'final'.
 
Hm, we now have final? ;)
 
Didn't knew that!
 
 
--
press any key to continue or any other to quit...
"Öö Tiib" <ootiib@hot.ee>: Dec 13 10:49AM -0800

On Tuesday, 13 December 2016 20:01:49 UTC+2, Melzzzzz wrote:
> > dRef = d2; // ok
> > }
 
> What about multiple inheritance? Is it ok then to assign d to d?
 
There are no problems if assignments are implemented correctly.
Note that above example was not about correct implementation of
assignment. Classes were stateless so there was nothing to assign.
It was demonstration how typeid works with polymorphic types.
 
The last assignment in example was even "mishandled" by the
program. It was declared "ok" despite it was actually "slicing
assignment" (it used B::operator= to assign D to D). ;)
Popping mad <rainbow@colition.gov>: Dec 13 07:59PM

On Tue, 13 Dec 2016 12:08:53 +0200, Paavo Helde wrote:
 
> Welcome to Usenet! Longest threads covering philosophy, religion, etc
> often start from some silly question like how many spaces a tab must be.
 
3
 
or

42
Tim Rentsch <txr@alumni.caltech.edu>: Dec 13 02:38PM -0800

> the new object, if ..."
 
> I snipped some sanity checks like requiring same type and most
> derived object etc. [...]
 
One of those checks says
 
the type of the original object is not const-qualified, and,
if a class type, does not contain any non-static data member
whose type is const-qualified or a reference type
 
Doesn't this requirement rule out the example being asked about,
which had a non-static data member of reference type?
bleachbot <bleachbot@httrack.com>: Dec 04 03:18AM +0100

bleachbot <bleachbot@httrack.com>: Dec 04 07:45PM +0100

bleachbot <bleachbot@httrack.com>: Dec 04 11:37PM +0100

bleachbot <bleachbot@httrack.com>: Dec 04 11:45PM +0100

bleachbot <bleachbot@httrack.com>: Dec 05 03:37AM +0100

bleachbot <bleachbot@httrack.com>: Dec 05 11:46PM +0100

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 12 06:59PM -0800

On Tuesday, November 1, 2016 at 11:28:17 AM UTC-4, David Brown wrote:
 
> I'm sorry, I can't figure out what you are trying to describe here - so
> I can't tell you if I think your gut instinct is right or wrong (or even
> if I know enough maths to have an opinion on your gut instinct here).
 
I saw a video recently which conveys this concept graphically. You say
you don't watch any of the links I post ... so ... it can be for other
people to examine:
 
https://www.youtube.com/watch?v=sD0NjbwqlYw
 
And specifically at this part:
 
https://www.youtube.com/watch?v=sD0NjbwqlYw&t=18m49s
 
Best regards,
Rick C. Hodgin
woodbrian77@gmail.com: Dec 12 06:11PM -0800

On Monday, December 12, 2016 at 2:51:45 AM UTC-6, Christian Gollwitzer wrote:
 
> https://github.com/auriocus/VecTcl
 
> HTH,
 
> Christian
 
 
I'm so far unable to figure out how to add/change anything
around the "overview" section. And when I click on the "downloads"
page there are no stats about how many times it has been downloaded.
 
Unfortunately, the software that's out on Atlassian requires
a C++2017 compiler. I'd like to ask compiler vendors to
make make_unique and string_view available with their C++
2011 compilers. That way users could get by with a C++2011
compiler.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
https://bitbucket.org/woodbrian/onwards/
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)