Friday, June 11, 2021

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

Manfred <noname@add.invalid>: Jun 11 05:11PM +0200

On 6/11/2021 4:35 PM, Bonita Montero wrote:
> You say:
 
> ...
Her interpretation of proper attribution - lol.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 11 05:12PM +0200

>> You say:
>>  ...
 
> Her interpretation of proper attribution - lol.
 
If there's nothing more to say I'm satisfied. ;-)
Christian Gollwitzer <auriocus@gmx.de>: Jun 11 09:15PM +0200

Am 11.06.21 um 16:35 schrieb Bonita Montero:
 
> And this can't be true since the container-implementation has
> to stick with what an allocator provides. Otherwise it wouldn't
> be replaceable.
 
By replaceable you mean that the template for, say, std::vector uses the
same code reagrdles off the allocator. Can this not be circumvented by
partial specialization on the allocator template argument?
 
Christian
Bo Persson <bo@bo-persson.se>: Jun 11 09:58PM +0200

On 2021-06-11 at 13:54, Bonita Montero wrote:
>> allocators.
 
> The allocator template-parameter is replaceable, so the code has to
> content itself with the API a allocator provides.
 
So you don't think it is possible to do something like:
 
if constexpr (is_same_v<_Alloc, std::allocator<_Ty>>)
// use special knowledge
else
// fall-back for user defined allocator
Sam <sam@email-scan.com>: Jun 11 07:11PM -0400

Bonita Montero writes:
 
> -interface which is specified under the link I've shown you. And
> with this there is no opportunity to get the size of the memory
> actually allocated.
 
C++ library allocators are free to export additional, implementation-
specific interfaces that C++ library container templates can check for and
use, if available.
 
The C++ standard does not require allocators to provide ONLY the interfaces
that are specified in the standard. They are free to have implementation-
specific interfaces too, that other templates in the C++ library know how to
use, and will use them when instantiated with a standard allocator, from the
C++ library.
 
Of course, those C++ container templates cannot require the allocator they
use to implement these non-standard interfaces. The C++ standard reserves
certain symbol names for implementation-specific usage. If an allocator
implements the implementation-specific interface (using symbol names that
are reserved for the implementation's use), then the C++ template can take
advantage of it; otherwise the template will fall back to the interface
that's specified in the C++ standard. This is fairly simple to do using
SFINAE or concepts.
Sam <sam@email-scan.com>: Jun 11 07:12PM -0400

Bonita Montero writes:
 
 
> The allocator template-parameter is replaceable, so the code calling
> it has to adhere to its interface. So there's no opportunity to get
> the size actually physically allocated.
 
SFINAE, or concepts, can be used to determine whether the allocator
implements an extended interface that's supported by the library and then
use it, if it exists. Otherwise the container template will use only the
standard-specified interface.
Lynn McGuire <lynnmcguire5@gmail.com>: Jun 11 02:13PM -0500

On 6/11/2021 3:17 AM, Ian Collins wrote:
>> disaster.
 
> Well it very much depends on whether you have multiple writers.  If you
> have a more readers than writers, std::shared_mutex is worth a look.
 
The problem is specifically too many writes slowing the user interface down.
 
Lynn
SIMON <invalid@invalid.invalid>: Jun 11 05:55PM

Does anybody know the significant difference between:
 
> myStack.push(30);
 
> myStack.emplace(30);
 
It does the same thing as far as I can see but surely there must be
something that I don't know about these two methods.
SIMON <invalid@invalid.invalid>: Jun 11 06:08PM

On 11/06/2021 18:55, SIMON wrote:
 
>> myStack.emplace(30);
 
> It does the same thing as far as I can see but surely there must be
> something that I don't know about these two methods.
 
These two links says the same thing in different words, of course:
 
<https://www.alphacodingskills.com/cpp/notes/cpp-stack-push.php>
<https://www.alphacodingskills.com/cpp/notes/cpp-stack-emplace.php>
scott@slp53.sl.home (Scott Lurndal): Jun 11 06:21PM


>These two links says the same thing in different words, of course:
 
><https://www.alphacodingskills.com/cpp/notes/cpp-stack-push.php>
><https://www.alphacodingskills.com/cpp/notes/cpp-stack-emplace.php>
 
Try a better reference.
 
https://en.cppreference.com/w/cpp/container/stack/push
https://en.cppreference.com/w/cpp/container/stack/emplace
Richard Damon <Richard@Damon-Family.org>: Jun 11 02:29PM -0400

On 6/11/21 1:55 PM, SIMON wrote:
 
>> myStack.emplace(30);
 
> It does the same thing as far as I can see but surely there must be
> something that I don't know about these two methods.
 
It depends on the type that the stack is made from.
 
push() takes an object of that type, and copies it to the stack.
emplace() takes the arguments needed to construct an object of that type
an makes a new object from the arguments given.
 
For a type like int, there isn't a difference.
 
If it was a stack of so Point, with a contructor that two arguments it
would.
 
to push you would do something like:
 
myStack.push(Point(x, y));
 
or
 
Point point(x,y);
myStack.push(point);
 
while emplace would be
 
myStack.emplace(x,y);
Kli-Kla-Klawitter <kliklaklawitter69@gmail.com>: Jun 11 08:35PM +0200

push and emplace are the same for stack - always!
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: