Wednesday, March 15, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 9 topics

Ramine <toto@toto.net>: Mar 15 10:59PM -0400

Hello,
 
 
My Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
was updated...
 
 
Please download the new updated version from:
 
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <toto@toto.net>: Mar 15 10:51PM -0400

Hello,
 
 
My C++ synchronization objects library for Windows and Linux was updated..
 
I have corrected a bug with my Ticket Spinlock with a proportional
back-off..
 
And i have thoroughly tested it again and i think that it is more stable
and fast now.
 
 
Be happy with my C++ synchronization objects library !
 
 
You can download the new updated version from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
Frank Tetzel <s1445051@mail.zih.tu-dresden.de>: Mar 15 10:30AM +0100

> I need to pass the arguments to the pair, one of which is going to be
> T(), so I am still making an extra copy of T...
 
> Is there some way around that?
 
There's C++17's try_emplace, if you have a very recent compiler.
 
It only constructs T and the pair if an insertion happens.
Christopher Pisz <christopherpisz@gmail.com>: Mar 15 12:41PM -0700

On Monday, March 13, 2017 at 11:00:53 PM UTC-5, Christopher J. Pisz wrote:
> need to pass the arguments to the pair, one of which is going to be T(),
> so I am still making an extra copy of T...
 
> Is there some way around that?
 
 
Is there anything wrong with the use of std::piecewise_construct and std::forward_as_tuple?
 
#include <iostream>
#include <vector>
#include <unordered_map>
 
//----------------------------------------------------------------------------------------
class SomeClass
{
public:
SomeClass(int x, double y)
:
m_x(x)
, m_y(y)
{
std::cout << " Constructor " << std::endl;
}
 
SomeClass(const SomeClass & rhs)
:
m_x(rhs.m_x)
, m_y(rhs.m_y)
{
std::cout << " Copy Constructor " << std::endl;
}
 
SomeClass(SomeClass && rhs)
:
m_x(rhs.m_x)
, m_y(rhs.m_y)
{
std::cout << " Move Constructor " << std::endl;
}
 
private:
 
int m_x;
double m_y;
};
 
//----------------------------------------------------------------------------------------
int main(int argc, char ** argv)
{
std::vector<SomeClass> myVector;
// The arguments for SomeClass' constructor are used and no temporary is created
myVector.emplace_back(1, 2.0);
 
std::unordered_map<int, SomeClass> myMap;
// I see no way to get around creating the temporary SomeClass to pass as an argument
// myMap.emplace(1, 1, 2.0); // Gives error as it tries to pass 3 args to std::pair
myMap.emplace(1, SomeClass(1, 2.0));
 
myMap.emplace(std::piecewise_construct, std::forward_as_tuple(2), std::forward_as_tuple(4, 4.0));
 
 
 
return 0;
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 15 09:39PM +0100

On 15-Mar-17 8:41 PM, Christopher Pisz wrote:
 
>> Is there some way around that?
 
> Is there anything wrong with the use of std::piecewise_construct and
> std::forward_as_tuple?
 
No, it looks OK.
 
I never used it, it didn't even enter my mind that std::pair had such
support, or I would have suggested it rather than an elaborate (albeit
more generally applicable) workaround.
 
 
Cheers!, & thanks for that pointer,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 15 10:19PM

On Wed, 15 Mar 2017 12:41:29 -0700 (PDT)
Christopher Pisz <christopherpisz@gmail.com> wrote:
[snip]
> std::forward_as_tuple(4, 4.0));
 
> return 0;
> }
 
Yes, this is the exact use case that the std::piecewise_construct
overload for the std::pair constructor was intended to serve in
C++11/14.
 
C++17 will apparently make this unintuitive (and probably nearly
unknown) overload unnecessary by providing a new std::map::try_emplace()
method. It would apparently allow your original proposal as follows:
 
myMap.try_emplace(1, 1, 2.0);
 
See §23.4.4.4/4 of N4640 for further information. If your compiler
supports it, try the -std=c++1z or -std=c++17 option.
Lynn McGuire <lynnmcguire5@gmail.com>: Mar 15 12:31PM -0500

"LLVM 4.0.0 released"
http://www.osnews.com/story/29713/LLVM_4_0_0_released
 
"This release is the result of the community's work over the past six months, including: use of profile data in ThinLTO, more
aggressive dead code elimination, experimental support for coroutines, experimental AVR target, better GNU ld compatibility and
significant performance improvements in LLD, as well as improved optimizations, many bug fixes and more."
 
I am continuing to hear more and more good things about the LLVM compilers and backend code generator. I just wish that there was an
platform independent IDE for them.
 
While I am at it, a platform independent user interface maintained by the compiler writers and a part of the C++ standards would be
good also.
 
Lynn
Daniel <danielaparker@gmail.com>: Mar 15 11:19AM -0700

On Wednesday, March 15, 2017 at 1:32:04 PM UTC-4, Lynn McGuire wrote:
 
> While I am at it, a platform independent user interface maintained by the compiler writers and a part of the C++ standards would be
> good also.
 
We don't have date, we don't have string (we only have what in other
languages is called a byte buffer or word buffer), we don't have strtod_l (or
any efficient locale independent integer or double conversion), we still
don't have the most basic things, and you want standard body to spend time on
platform independent user interface?
 
Daniel
Ian Collins <ian-news@hotmail.com>: Mar 16 07:21AM +1300

On 03/16/17 06:31 AM, Lynn McGuire wrote:
> experimental AVR target, better GNU ld compatibility and significant
> performance improvements in LLD, as well as improved optimizations,
> many bug fixes and more."
 
I've been using the developer versions for a while, nothing bad to report.
 
> I am continuing to hear more and more good things about the LLVM
> compilers and backend code generator. I just wish that there was an
> platform independent IDE for them.
 
Do what? Most IDE's are compiler agnostic.
 
--
Ian
legalize+jeeves@mail.xmission.com (Richard): Mar 15 08:45PM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
 
>I am continuing to hear more and more good things about the LLVM
>compilers and backend code generator. I just wish that there was an
>platform independent IDE for them.
 
I'm not sure what you're asking for.... are you intending to work in
LLVM itself and you want an IDE that facilitiates development of
changes to LLVM, or are you asking for an IDE that uses LLVM as the
back end?
 
For the former, the whole thing is CMake based, so any environment
that supports CMake will let you contribute to LLVM/Clang.
 
For the latter, Clang uses LLVM as the backend, so anything you
compile with clang will go through LLVM.
 
In either case, CLion will support the environment on linux/MacOS.
 
For Windows, it's a little trickier, but it's possible to install the
clang compiler into VS so that you can compile with clang. (VS has an
offering built-in that uses the clang front end and the MSVC code
generator allowing you access to the language parsing of clang and
code generation of MSVC.)
 
>While I am at it, a platform independent user interface maintained by
>the compiler writers and a part of the C++ standards would be
>good also.
 
No other language (standardized or not) has this, so I see no reason
to impose this on the C++ standards committee. The standards
committee doesn't even maintain a reference implementation of the
language for C++. Asking them to support a reference IDE is
unrealistic. Supplying this is the proper role of the community
and/or marketplace.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Joseph Hesse <joeh@gmail.com>: Mar 15 08:57AM -0500

/*
I wrote a test program where I insert 2 objects into a vector. The
objects have a contrived copy constructor and their destructors print a
message.
When the program ends I expect to see 4 destructor calls, 2 from the
death of the objects and 2 when the vector dies.
An extra object appears and I don't know where it came from.
Thank you,
Joe
*/
///////////////////////////////////////////////////////
#include <iostream>
#include <vector>
using namespace std;
 
class X
{
private:
int x;
public:
X(int u = 0) : x(u) {}
~X() { cout << "Bye from X with x = " << x << endl; }
X(const X & rhs) : x(10*rhs.x) {}
};
 
int main()
{
X xobj1(1), xobj2(2);
 
vector<X> vec;
 
vec.push_back(xobj1);
vec.push_back(xobj2);
 
return(0);
}
///////////////////////////////////////////////////////
$ g++ --std=c++11 Test.cpp
$ ./a.out
Bye from X with x = 10
Bye from X with x = 100 <== Where did this come from?
Bye from X with x = 20
Bye from X with x = 2
Bye from X with x = 1
guy.tristram@gmail.com: Mar 15 07:43AM -0700

On Wednesday, March 15, 2017 at 1:57:28 PM UTC, Joseph Hesse wrote:
> Bye from X with x = 100 <== Where did this come from?
 
When you push_back xobj2, vec is resized and the first copy of xobj1
is copied to the newly allocated memory. The old copy (x=10) is destroyed
during the push_back. You then see the destructor calls you expected, except
because the first element of vec has been copied twice, you see x=100.
 
If you call vec.reserve(2) before the push_back calls, you should see what
you were expecting.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 15 03:57PM +0100

On 15-Mar-17 2:57 PM, Joseph Hesse wrote:
> Bye from X with x = 20
> Bye from X with x = 2
> Bye from X with x = 1
 
When I add some tracing output to your `main`,
 
 
int main()
{
X xobj1(1), xobj2(2);
 
vector<X> vec;
 
cout << "Capacity " << vec.capacity() << " before adding o1\n";
vec.push_back(xobj1);
cout << "Capacity " << vec.capacity() << " before adding o2\n";
vec.push_back(xobj2);
cout << "Capacity " << vec.capacity() << " after adding o2\n";
}
 
 
then with both g++ and Visual C++ I get this output:
 
 
Capacity 0 before adding o1
Capacity 1 before adding o2
Bye from X with x = 10
Capacity 2 after adding o2
Bye from X with x = 100
Bye from X with x = 20
Bye from X with x = 2
Bye from X with x = 1
 
 
Here you can see that that the vector increased its buffer size, by
replacing its buffer, both for the first insertion and for the second
insertion. In the last buffer replacement the copy of the o1 object was
copied a second time, invoking the 10*rhs.x in the copy constructor, a
second time.
 
I believe the standard doesn't specify the initial capacity of a vector,
and anyway it for sure doesn't specify the capacity after adding an
item, so the behavior here is compiler-specific. You cannot rely on any
particular buffer management strategy except the general complexity
guarantees, which imply a geometric increase of capacity.
 
You can however guaranteed avoid the buffer replacements during the
insertion sequence by calling `.reserve(a_suitable_initial_capacity)`.
Since this avoids multiple dynamic allocations, which are notoriously
slow, it's often done as a matter of course. I guess if `std::vector`
were designed today, with what we now know of usage patterns, it would
have had constructors that supported specification of an initial
capacity, and it might possibly have provided access to uninitialized
parts of the buffer for POD item type, for use as API function result.
 
 
Cheers & hth.,
 
- Alf
Joseph Hesse <joeh@gmail.com>: Mar 15 02:04PM -0500

On 03/15/2017 08:57 AM, Joseph Hesse wrote:
> vec.push_back(xobj2);
 
> return(0);
> }
 
Thank you for the replies.
 
I added a Move Constructor to Class X, thinking that vector<X> would use
it when moving things around after space reallocation.
X(X && rhs) : x(rhs.x) {}
 
Same result.
 
I learned something from this example. "Don't put side effects into Copy
Constructors."
Paavo Helde <myfirstname@osa.pri.ee>: Mar 15 10:21PM +0200

On 15.03.2017 21:04, Joseph Hesse wrote:
> X(X && rhs) : x(rhs.x) {}
 
You need to make this
 
X(X && rhs) noexcept : x(rhs.x) {}
 
as explained by Scott in another thread.
jonkalb@boost.org: Mar 14 07:20PM -0700

As Alf and Paavo have pointed out, you can used insert() on vector with the begin iterator to get the correct prepend behavior. The reason that vector doesn't have push_front is that it is O(N) instead of O(1). For same value of N (such as 3) this is not an issue.
 
If you need to prepend on a sequential container containing a larger number of elements consider std::deque, for which push_front is constant time.
 
std::deque is a considerable more complicated container than std::vector with large constant times on almost all operations, so std::vector is preferred.\
 
Jon
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 14 08:13PM -0700

Use a traditional link list. You can insert anywhere inexpensively.
 
Thank you,
Rick C. Hodgin
Alvin <Alvin@invalid.invalid>: Mar 15 01:39PM +0100

On 2017-03-14 22:05, Mike Copeland wrote:
> { parse CSV line }
> while(parseArray.size() < 3) { prepend "0" object }
 
> Perhaps there's another container which will work: any thoughts? TIA
 
If you have a lot of those size 3 vectors, look at boost::small_vector.
It can store a configurable number of objects in the small_vector object
itself.
woodbrian77@gmail.com: Mar 15 08:01AM -0700

On Tuesday, March 14, 2017 at 10:14:17 PM UTC-5, Rick C. Hodgin wrote:
> Use a traditional link list. You can insert anywhere inexpensively.
 
There's rarely a good reason to use a linked list and I wouldn't
recommend it in this case.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 15 12:24PM -0700

> > Use a traditional link list. You can insert anywhere inexpensively.
 
> There's rarely a good reason to use a linked list and I wouldn't
> recommend it in this case.
 
You lose the ability to access directly via index, but if that's not an
issue, the gains for random insertion and movement are desirable,
as in the OP's need to push_front().
 
Thank you,
Rick C. Hodgin
bitrex <bitrex@de.lete.earthlink.net>: Mar 15 12:06PM -0400

I'm a little confused on how to properly use the "noexcept" keyword. I
recall reading a blog entry a while back saying that it wasn't
particularly useful, except in the circumstance on certain constructors
and assignment operators to indicate to certain STL containers that the
structures would not throw, which could speed some operations, but I
don't recall the details.
 
If anyone could elaborate I'd appreciate it...
scott@slp53.sl.home (Scott Lurndal): Mar 15 04:28PM

>structures would not throw, which could speed some operations, but I
>don't recall the details.
 
>If anyone could elaborate I'd appreciate it...
 
from http://en.cppreference.com/w/cpp/language/noexcept_spec
 
"Note that a noexcept specification on a function is not a compile-time
check; it is merely a method for a programmer to inform the compiler
whether or not a function should throw exceptions. The compiler can
use this information to enable certain optimizations on non-throwing
functions as well as enable the noexcept operator, which can check
at compile time if a particular expression is declared to throw any
exceptions. For example, containers such as std::vector will move
their elements if the elements' move constructor is noexcept, and
copy otherwise (unless the copy constructor is not accessible, but
a potentially throwing move constructor is, in which case the strong
exception guarantee is waived)."
Stuart Redmann <DerTopper@web.de>: Mar 15 04:55PM +0100

Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote:
[snip] after
> this particular crash was easily reproduced and hence, I reported it.
 
> Hope this helps someone,
 
> - Alf
 
When I first tried to open a project with Xcode 5, it didn't even get as
far as the splash screen, it crashed right away. Nowadays I try to wait 3-6
months before I use any new product, be it software or hardware.
 
Regards,
Stuart
ram@zedat.fu-berlin.de (Stefan Ram): Mar 14 11:32PM

> Is there a way to "prepend" objects into a std::vector? That is, I'd
>like to "push_front" instead of "push_back".
 
The vector with push_front is called "deque" in C++,
one could also use a kind of a list.
 
Lists and deques might be more efficient than "vector" when only
insertations at the front are observed. However, when other
operations are used too, "vector" might have the best overall
performance.
 
>Perhaps there's another container which will work: any thoughts? TIA
 
You don't need a different container, you need abstraction.
ram@zedat.fu-berlin.de (Stefan Ram): Mar 15 02:33PM

>Bye from X with x = 100 <== Where did this come from?
 
When »xobj2« was copied into »vec«, the value from »xobj1«
(which already was contained in the vector), was copied too.
 
Replace
 
vector<X> vec;
 
by
 
vector<X> vec; vec.reserve(9);
 
, and the »100« should go away.
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)