Sunday, August 14, 2016

Digest for comp.lang.c++@googlegroups.com - 12 updates in 6 topics

"Öö Tiib" <ootiib@hot.ee>: Aug 14 02:27PM -0700

On Sunday, 14 August 2016 18:11:34 UTC+3, bitrex wrote:
> rhs += x;
> return std::move(rhs);
> }
 
Do not forget that the move of C++11 is *only* performance optimization
of reusing value that is going to be discarded. It is simple to get rid
of that optimization:
 
SignalSource operator+(SignalSource const& lhs, SampleType x)
{
SignalSource ret(lhs);
ret += x;
return ret;
}
 
SignalSource operator+(SampleType x, SignalSource const& rhs)
{
SignalSource ret(rhs);
ret += x;
return ret;
}
 
> of objects on the stack when the source/destination is going to be
> destroyed anyway, so I didn't know if there was some "canonical" way to
> backport this.
 
Canonical is to assume that copy or move does not matter and copy is fine.
On majority of cases it actually is correct assumption.
 
C++03 did have smart pointer named 'std::auto_ptr' that did always move
instead of copy. That was nice but dangerous to use because first less
experienced maintainer that touched the code likely screwed it up.
 
Some code used members called 'swap' for achieving move-like effect to
efficiency where needed. There were no rvalue-references (from what it
is safe to move or to swap) so if someone wanted to move from reference
to temporary then he had to cast constness away.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 14 11:58PM +0200

On 14.08.2016 17:11, bitrex wrote:
> rhs += x;
> return std::move(rhs);
> }
 
I think this is probably not your actual code. Your actual code is
probably templated on SignalSource, in which case the && is a universal
reference. In the non-templated code given above, && is an rvalue
reference, which would only permit rvalue expression as actual argument.
 
Anyway, you can either
 
• remove the move optimization (just copy things) or
 
• implement /explicit/ move operations.
 
 
> of objects on the stack when the source/destination is going to be
> destroyed anyway, so I didn't know if there was some "canonical" way to
> backport this.
 
Nope, but if, after measuring the simple copy solution, you find that
moving is really required, then instead of implementing your own
explicit C++03 move operations you could look up Andrei Alexandrescu's
Mojo article in DDJ.
 
 
Cheers & hth.,
 
- Alf
bitrex <bitrex@de.lete.earthlink.net>: Aug 14 06:33PM -0400

On 08/14/2016 05:27 PM, Öö Tiib wrote:
> efficiency where needed. There were no rvalue-references (from what it
> is safe to move or to swap) so if someone wanted to move from reference
> to temporary then he had to cast constness away.
 
Nice, thank you for your insight. I've started using C++11 a bit on the
desktop and the unique_ptr smart pointer syntax does make life a lot
easier.
 
Unfortunately this particular thing is for an embedded platform, so all
that cool automatic memory management stuff that assumes a system MMU is
out the door.
Daniel <danielaparker@gmail.com>: Aug 14 10:11AM -0700

On Sunday, August 14, 2016 at 12:01:52 PM UTC-4, Joseph Hesse wrote:
> Once the array Values is populated it never changes, hence the const in
> "const int d;"
> The problem is how can I give values to Values[i].d?
 
How about
 
class Data
{
private:
const int d;
// ...
public:
Data(int val) : d(val) {}
 
friend class Algorithm;
};
 
class Algorithm
{
private:
std::vector<Data> Values;
// ...
public:
// ctor opens data file and reads ints into Values[i].d
Algorithm(const string & DataFile)
{
Values.reserve(100);
 
// For each integer i in Datafile
{
Values.push_back(Data(i));
}
assert(Values.size() == 100);
}
// ...
};
 
Although I don't think most people would worry about Data having a const
value, I think most people would be fine with d private and no public
modifier.
 
Daniel
Marcel Mueller <news.5.maazl@spamgourmet.org>: Aug 14 09:39PM +0200

On 14.08.16 18.01, Joseph Hesse wrote:
> The problem is how can I give values to Values[i].d?
> I probably have a bad design, nevertheless in the non-simplified version
> it reflects the real problem.
 
Maybe your const is at the wrong place.
 
> {
> private:
> const Data Values[100]; // no need to use vector since 100 will never change
^^^^^
> // ...
> };
> ==========================================================
 
Of course, you still have to take some care about the initialization of
const arrays. std::array might fit your needs.
 
 
Marcel
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 15 12:07AM +0200

On 14.08.2016 18:01, Joseph Hesse wrote:
> // ...
 
> friend class Algorithm;
> };
 
The `const` only makes `Data` non-assignable.
 
Have you considered that that makes it difficult to e.g. sort a sequence
of `Data` values?
 
 
> {
> private:
> Data Values[100]; // no need to use vector since 100 will never change
 
With the present `const`, `std::vector` enables you to put Data values
in the array.
 
Simply use `std::vector<>::push_back` or `std::vector<>::emplace_back`.
 
 
> Algorithm(const string & DataFile); // code not shown
> // ...
> };
 
An instance of Algorithm is an object whose initialization reads values
from a file, and that is not copy assignable. Somehow that doesn't make
much sense to me. I think you should differentiate between algorithms
and the data they operate on, much as the standard library does.
 
 
Cheers & hth.,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 10:42PM +0100

On Sun, 14 Aug 2016 23:17:40 +0200
> EVENTS where you can change the language by adding special syntax and
> ad hoc syntax within an application context. I mentioned several
> examples in my post.
 
It is still compile time computation.
 
I don't buy your examples at all, and I think you are just confusing
yourself.
 
This is not really a point about C++, even though you try to dress it
as such: it is about a new method of generating object code at compile
time. Prove me wrong: raise capital, found a start-up and make a lot of
money. Begin with C, your preferred language.
"Öö Tiib" <ootiib@hot.ee>: Aug 14 03:01PM -0700

On Friday, 12 August 2016 12:12:07 UTC+3, jacob navia wrote:
 
> Chandler-Carruth
> Lead developper of the "clang" compiler project. And before you write "I
> think that..." can you compile that?
 
I did compile it on couple quite recent compilers:
 
g++ -v 2>&1 | grep version; g++ -std=c++11 -O0 -Wall -pedantic -pthread main.cpp && ./a.out
 
gcc version 6.1.0 (GCC)
 
X!
 
clang++ -v 2>&1 | grep version; clang++ -std=c++11 -stdlib=libc++ -O0 -Wall -pedantic -pthread main.cpp && ./a.out
 
clang version 3.8.0 (tags/RELEASE_380/final 263969)
 
X!
 
It is likely some sort of language lawyer level issue with normative
texts and so should be repaired in text of standard if it is dim.
bleachbot <bleachbot@httrack.com>: Aug 14 11:50PM +0200

Ramine <ramine@1.1>: Aug 14 05:51PM -0400

Hello...
 
I will add more about Transactional memory...
 
From my previous logical inference i have said that:
 
To get more safety on Transactional memory, transactions must
wrap the parallel part and the serial part, and this will
get you less performance than locks, now the important question
is since transactions conflicts are probabilistic and i have also
said on my previous logical inference that if the serial part
get more bigger so you will have more chance to get conflicts and
this will get you poor performance, so from my logical inference,
how can we guaranty a latency and throughput that is decent with
Transactional memory ? i think that since with Transactional memory
we can not do calculations that guaranty a more decent performance,
so Transactional memory is not good especially for realtime critical
systems even though transactional memory avoids race conditions and
deadlocks and is then good on composability.
 
 
So from my logical inference, that means that Transactional memory
is not the silver bullet, and locks are more suited for performance
than Transactional memory.
 
 
 
Thank you,
Amine Moulay Ramdane.
Daniel <danielaparker@gmail.com>: Aug 14 09:07AM -0700

On Sunday, August 14, 2016 at 7:11:22 AM UTC-4, Alain Ketterlin wrote:
 
> You could also use a null pointer to A to represent the null state ...
> But this was all before std::optional ...
 
Not really applicable, the context here is that a null value is a valid state,
for example, think of a class that encapsulates a json value, where a
to_string method on an instance in that state has to print "null".
 
> use whatever type lets it be different from the others, and in this case
> I would not choose nullptr_t, but rather define a specific, class-local,
> enum/struct/class, used only for that particular ctor.
 
That's my view too, but there are other C++ libraries that do use nullptr_t in
this context, saving themselves from having to define an additional class,
and I was interested in the thoughts of this community.
 
Best regards,
Daniel
"Öö Tiib" <ootiib@hot.ee>: Aug 14 02:48PM -0700

On Sunday, 14 August 2016 04:50:13 UTC+3, Daniel wrote:
> Consider a class which has a number of states, including a "null" state, e.g.
 
I do not know what is null state but I assume it is "such value does not
exist" state about like silent NaN of floating point numbers.
 
> };
 
> Is this sensible? Saves defining a null_type empty class? Or is it
> inappropriate semantics?
 
I would likely use 'boost::none_t' and 'boost::none'. The 'none' is
anyway missing from standard library. Initialization of C++ is so
screwed up and sloppy IMHO that adding to it is likely bad idea.
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)