Friday, August 11, 2017

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

Lynn McGuire <lynnmcguire5@gmail.com>: Aug 11 05:11PM -0500

What is the fastest way to store a list of unique pointers ?
 
We were storing a list of unique pointers in a std::vector list. But
searching it is slow before deciding to add a new pointer. So one of my
programmers changed the std::vector list to a std::map. That way we
always "add" the pointer to the list but never have to look it up. But,
the resulting value is always just set to 1. The resulting std::map
uses about 10% of the time that the std::vector did.
 
std::map <DataGroup * ptr, int> aList;
 
void addNewPointer (DataGroup * newPtr)
{
aList [newPtr] = 1;
}
 
Thanks,
Lynn
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 12 12:30AM +0200

On 12.08.2017 00:11, Lynn McGuire wrote:
> {
> aList [newPtr] = 1;
> }
 
Have you tried a `std::unordered_set`?
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Aug 11 03:40PM -0700

On Saturday, 12 August 2017 01:12:11 UTC+3, Lynn McGuire wrote:
> What is the fastest way to store a list of unique pointers ?
 
What program does with such storage? It creates reads updates and
deletes (CRUD) its elements. So "fastness" of the way to store depends
upon what patterns and proportions of elementary operations of that
CRUD the program will have.
 
 
> We were storing a list of unique pointers in a std::vector list. But
> searching it is slow before deciding to add a new pointer.
 
If searching is important why didn't you sort the vector?
 
> So one of my programmers changed the std::vector list to a std::map.
> That way we always "add" the pointer to the list but never have to
> look it up. But, the resulting value is always just set to 1.
 
If the value is bogus then why you did not use set or unordered_set?
 
> {
> aList [newPtr] = 1;
> }
 
It can sure be that speed of adding new pointers is most important feature
of container but it can also be that it is not.
Manfred <invalid@invalid.add>: Aug 12 01:21AM +0200

On 08/12/2017 12:30 AM, Alf P. Steinbach wrote:
>> aList [newPtr] = 1;
>> }
 
> Have you tried a `std::unordered_set`?
 
I think that std::set is the closest to the current behaviour (std::map
using only keys). And I think it is faster than unordered_set too,
although I have to say I did not check.
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 12 01:27AM +0200

On 12.08.2017 01:21, Manfred wrote:
 
>> Have you tried a `std::unordered_set`?
 
> I think that std::set is the closest to the current behaviour (std::map
> using only keys).
 
Can't say that I understand what you're thinking of here.
 
 
> And I think it is faster than unordered_set too,
> although I have to say I did not check.
 
Not this either. Since when did hashing become slower than a tree search?
 
 
 
Cheers!,
 
- Alf
ram@zedat.fu-berlin.de (Stefan Ram): Aug 11 10:39PM

Lynn McGuire <lynnmcguire5@gmail.com> writes: The resulting std::map
>uses about 10% of the time that the std::vector did.
 
The first idea that would spring to my mind would be a
sorted vector with a binary search, because it should
have a better memory locality than a tree or linked list
(which might be used to implement a map). But maybe for
your special case, the ::std::map is better. If it is
sufficiently fast now, I would just keep it.
Kalle Olavi Niemitalo <kon@iki.fi>: Aug 11 10:01AM +0300


> Alas, *without* a 'this' reference (the value 0x1 appeared in its place) as
> the first argument (contrary to what the "__stdcall" does on other virtual
> methods mind you). ECX was loaded with the correct 'this' reference though.
 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0722r0.htm
mentions that the Microsoft ABI gives destructors a hidden parameter
that indicates whether the destructor itself should free the memory.
 
I have not found any documentation in MSDN Library for that.
"R.Wieser" <address@not.available>: Aug 11 11:40AM +0200

Kalle,
 
> [snip link] mentions that the Microsoft ABI gives destructors a hidden
> parameter that indicates whether the destructor itself should free the
> memory.
 
Thank you very much for that. :-)
 
Although I was already quite sure it was infact a parameter I had no (real,
as opposed to some guessed) idea what it was used for.
 
I do still have a question about it though: any idea why the "__stdcall"
applied to the virtual destructor doesn't cause the 'this' reference to
appear as the first argument, and (maybe) how to fix that ? As it now is
I can't use the virtual destructor at all.
 
Regards,
Rudy Wieser
 
 
-- Origional message:
Kalle Olavi Niemitalo <kon@iki.fi> schreef in berichtnieuws
878tiqr3jw.fsf@Niukka.kon.iki.fi...
> "R.Wieser" <address@not.available> writes:
 
> > Alas, *without* a 'this' reference (the value 0x1 appeared in its place)
as
> > the first argument (contrary to what the "__stdcall" does on other
virtual
> > methods mind you). ECX was loaded with the correct 'this' reference
though.
Kalle Olavi Niemitalo <kon@iki.fi>: Aug 11 03:33PM +0300


> any idea why the "__stdcall" applied to the virtual destructor
> doesn't cause the 'this' reference to appear as the first
> argument,
 
I don't know, but it might be for the sake of exceptions. If you
throw an instance of that class and catch it using 'catch (...)'
without rethrowing, then the catch site has to call the
destructor but the compiler does not know which type of exception
it is, so the call has to be done via some kind of function
pointer. That could then require every destructor to use the
same calling convention, unless the compiler generates wrappers.
 
> and (maybe) how to fix that ?
 
Most likely you cannot.
 
If you describe why you are trying to change the calling
conventions, perhaps someone can suggest an alternative solution.
(If you are trying to modify vtables at run time, I think
it'd be OK to insert an asm wrapper to deal with ECX, because
the program won't be portable anyway.)
"R.Wieser" <address@not.available>: Aug 11 05:42PM +0200

Kalle,
 
> If you describe why you are trying to change the calling
> conventions,
 
I'm calling an external (to the VC++ program) object (stored in a
dynamically loaded DLL) which methods are based on the COM model, meaning
that the first argument is supposed to be a 'this' reference.
 
The reason for that is that object might be written in a language other than
VC++, meaning that I can't even be certain it can access the processors
registers.
 
But don't worry. I would have been nice to use the build-in class
mechanisms (both the destructor as well as the constructor) as well as the
"delete(object)" command), but I can as easily do away with it and use the
shown "Destructor" method instead.
 
> because the program won't be portable anyway.
 
Because of the use of that "__stdcall" ? That would, even though it does
affect me personally, be unfortunate ...
 
And thanks for your help, I appreciate it.
 
Regards,
Rudy Wieser
 
 
-- Origional message:
Kalle Olavi Niemitalo <kon@iki.fi> schreef in berichtnieuws
874lteqo75.fsf@Niukka.kon.iki.fi...
Richard Damon <Richard@Damon-Family.org>: Aug 11 12:10PM -0400

On 8/10/17 2:14 PM, Scott Lurndal wrote:
> pool/heap.
 
> One cannot delete an abstract class (since one cannot instantiate it), so
> the destructor will never be called and no memory will be free'd.
 
delete doesn't take an object, but a pointer to an object. It is quite
possible to use delete on a pointer to an abstract class, as that
pointer is allowed to point to an object of any class derived from that
abstract base class.
 
If that destructor is not virtual, then you have invoked undefined
behavior (if the destructor is not virtual, the apparent type must match
the actual run time type, and being abstract, that can't be).
 
The default code for a destructor is to invoke the destructors for all
objects declared in that class, and then invoke the destructors for the
base classes. If you implement code for the destructor, that code will
get run before that automatically generated code, there is no way to
suppress the destructors from being called (as far as I know).
Kalle Olavi Niemitalo <kon@iki.fi>: Aug 11 10:51PM +0300


>> because the program won't be portable anyway.
 
> Because of the use of that "__stdcall" ?
 
I meant, the C++ standard does not define the format or existence
of vtables, so any manipulation of those cannot be portable.
Compilers that target Microsoft Windows pretty much have to match
the Microsoft ABI, though; otherwise they wouldn't be able to use
C++ class definitions generated by MIDL.
 
IIRC, neither __stdcall nor __cdecl will prevent arguments from
being passed in registers if you target AMD64 or IA64.
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Aug 10 10:43PM -0700

On Wednesday, August 9, 2017 at 6:40:29 PM UTC+5:30, Öö Tiib wrote:
> archaic is tried to be used then on at least 90% of cases it is some
> cargo cult misuse because of misunderstanding of random text
> that was read in internet. How is it on your case?
My main concern is to send huge strings via socket which may include any special character so my major concern would be to preserver all those strings on the other side of the recieving socket too.So thats whyi would prefer some good encoding mechanism here
"Öö Tiib" <ootiib@hot.ee>: Aug 10 11:35PM -0700

On Friday, 11 August 2017 08:44:06 UTC+3, kushal bhattacharya wrote:
> > cargo cult misuse because of misunderstanding of random text
> > that was read in internet. How is it on your case?
> My main concern is to send huge strings via socket which may include any special character so my major concern would be to preserver all those strings on the other side of the recieving socket too.So thats whyi would prefer some good encoding mechanism here
 
Goodness is not universal. Otherwise everybody would use same encoding
for everything. It can depend on lot of factors like who will make the things
involved, what is at these sides, what sort of data is sent and over what
kind of channel and what are priorities of capabilities (like average
/worst latency and throughput) of result.
 
One thing in software development is to realize that we do not carve
our software into rock. So if we do not know what to choose then we can
make arbitrary pick what is simplest for us right now and change it
later when we become more aware of situation.
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Aug 10 11:39PM -0700

On Friday, August 11, 2017 at 12:05:58 PM UTC+5:30, Öö Tiib wrote:
> our software into rock. So if we do not know what to choose then we can
> make arbitrary pick what is simplest for us right now and change it
> later when we become more aware of situation.
 
thanks for the time being i am choosing base 64 encoding :)
Ian Collins <ian-news@hotmail.com>: Aug 11 08:39PM +1200

On 08/11/17 05:43 PM, kushal bhattacharya wrote:
>> tried to be used then on at least 90% of cases it is some cargo
>> cult misuse because of misunderstanding of random text that was
>> read in internet. How is it on your case?
 
[please wrap!]
 
> preserver all those strings on the other side of the recieving
> socket too.So thats whyi would prefer some good encoding mechanism
> here
 
Sockets are typically used to transfer binary data, why do you see
special characters as a problem?
 
--
Ian
kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Aug 11 02:25AM -0700

On Friday, August 11, 2017 at 2:09:39 PM UTC+5:30, Ian Collins wrote:
> special characters as a problem?
 
> --
> Ian
 
I am sending data from my c++ program to php and i am using it to show it to the browser so the browser ,to my opinion may misnterpret or cant recognise some character
Paavo Helde <myfirstname@osa.pri.ee>: Aug 11 10:16PM +0300

On 11.08.2017 12:25, kushal bhattacharya wrote:
 
>> --
>> Ian
 
> I am sending data from my c++ program to php and i am using it to show it to the browser so the browser ,to my opinion may misnterpret or cant recognise some character
 
It looks like you are having troubles with different text encodings.
This has nothing to do with sockets, uuencode or base64.
 
Suggesting to convert all textual data into UTF-8 at the first
possibility and ensure that all produced HTML pages have the correct
UTF-8 charset declaration.
 
hth
Paavo
Ian Collins <ian-news@hotmail.com>: Aug 11 08:42PM +1200

On 08/11/17 12:12 AM, R.Wieser wrote:
 
>> Please don't top-post. Thank you.
 
> I'm not going to argue this with you, but I suggest you look again. At my
> posting style as wel as what "top posting" means.
 
Your "posting style" is a good shortcut to kill files...
 
If you come here looking for help, follow the rules.
 
--
Ian
"R.Wieser" <address@not.available>: Aug 11 01:30PM +0200

Ian,
 
> Your "posting style" is a good shortcut to kill files...
 
Its your perogative to choose whom you want to answer to, for whatever
reason. I can only hope you use it and get outof my hair.
 
Regards,
Rudy Wieser
 
 
-- Origional message:
Ian Collins <ian-news@hotmail.com> schreef in berichtnieuws
ev58v4Fao28U2@mid.individual.net...
> > Alf,
 
> >> Please don't top-post. Thank you.
 
> > I'm not going to argue this with you, but I suggest you look again. At
my
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)