Friday, May 8, 2015

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

Bo Persson <bop@gmb.dk>: May 08 05:39PM +0200

On 2015-05-07 23:08, Doug Mika wrote:
> I'm kind of curious when it would be an advantage to use std::move. I know it turns an lvalue to an rvalue, but not much else. When would it be adventagous to use std::move?
 
Whenever you need an lvalue turned into an rvalue. :-)
 
> int y=5;
> test(move(y));
 
> //after my code returns from test() should I avoid using y?)
 
Of course, that depends on what test() does to the object.
 
Standard library types are guaranteed to be in "a valid but inspecified
state" after being moved from. User defined types are in whatever state
their move constructor or move assignment leave them in.
 
Generally, you use std::move(y) to give the value away. After that you
should be able to destroy y (like when going out of scope) or assign it
a new value. That's about it.
 
 
Bo Persson
Doug Mika <dougmmika@gmail.com>: May 08 08:51AM -0700

Here I have another two short extracts from a document I was reading. The first is:
 
vector<String> vs;
String s(15);
vs.push_back(s); //uses String's copy constructor
 
does this use String's copy constructor because it uses the void push_back (const value_type& val); method which inside of it copies the string passed as reference into the vector vs?
 
Also, here is another short code extract:
 
vector<String> vs;
String s1(15), s2(20);
vs.push_back(static_cast<String&&>(s1)); //uses String's move constructor
vs.push_back(std::move(s2)); //uses String's move constructor
 
Does this use String's move constructor because inside the overwritten push_back method which is void push_back (value_type&& val); the method inside guarantees the implementation of the string's move constructor and not the copy constructor?
Victor Bazarov <v.bazarov@comcast.invalid>: May 08 12:19PM -0400

On 5/8/2015 11:51 AM, Doug Mika wrote:
> String s(15);
> vs.push_back(s); //uses String's copy constructor
 
> does this use String's copy constructor because it uses the void
push_back (const value_type& val); method which inside of it copies the
string passed as reference into the vector vs?
 
Yes.
 
> overwritten push_back method which is void push_back (value_type&&
> val); the method inside guarantees the implementation of the string's
> move constructor and not the copy constructor?
 
Too many words for me to understand, honestly. "The method inside
guarantees.."? There are two overloaded 'push_back' member functions,
one takes a prvalue (a ref to const lvalue) just like it did in 1998,
and the other that takes an xvalue (an rvalue ref), which is new in
C++11. *Both* create the element by constructing it, so essentially
their code ought to be identical. However, due to the existence of
overloaded constructors in the element type (std::string in this case),
the two 'push_back' functions will use different c-tors, the copy c-tor
in the case of the old 'push_back' and the move c-tor in the case of the
newer 'push_back'.
 
V
--
I do not respond to top-posted replies, please don't ask
Paavo Helde <myfirstname@osa.pri.ee>: May 08 11:51AM -0500

Doug Mika <dougmmika@gmail.com> wrote in
 
> does this use String's copy constructor because it uses the void
> push_back (const value_type& val); method which inside of it copies
> the string passed as reference into the vector vs?
 
Yes, as s is a lvalue (it has a name and can be assigned to) this is
passed to the const reference overload. A conforming std::vector
implementation will finally copy the value to inside the vector by using
the copy constructor. Some other evil container class could use std::move
() inside and move away the value instead, but std::vector would not do
that.
 
Well, if the compiler notices that s is not accessed afterwards then it
is allowed to optimize away the copy constructor call and construct the
value directly in the correct place.
 
> push_back method which is void push_back (value_type&& val); the
> method inside guarantees the implementation of the string's move
> constructor and not the copy constructor?
 
These examples are basically identical. Yes, if String has a move
constructor this ought to be used here by a conformant std::vector
implementation. I cannot find the guarantee in the standard text right
now, but this is at least the intended behavior.

hth
Paavo
Doug Mika <dougmmika@gmail.com>: May 08 10:21AM -0700

If I have a short function called from main that returns an object t of type T by value, would the compiler below know to move the value t if it goes out of scope, or would it copy it upon return?
 
T someFunc(){
T t;
//do something
return t; //would this t be returned via move semantics?
}
 
or if the compiler wouldn't know, should I write:
 
T someFunc(){
T t;
//do something
return std::move(t); //explicitly force t to be an rvalue
}
Victor Bazarov <v.bazarov@comcast.invalid>: May 08 01:55PM -0400

On 5/8/2015 1:21 PM, Doug Mika wrote:
> If I have a short function called from main that returns an object t
of type T by value, would the compiler below know to move the value t if
it goes out of scope, or would it copy it upon return?
> //do something
> return std::move(t); //explicitly force t to be an rvalue
> }
 
You can't force anything into something it already is. A value returned
from a function is already a prvalue unless it's a reference. There is
no need to use 'std::move' on something that is about to be destroyed
due to going out of scope anyway.
 
V
--
I do not respond to top-posted replies, please don't ask
Doug Mika <dougmmika@gmail.com>: May 08 09:30AM -0700

I have the following implementation of a move constructor: (it assumes our string class has a char* buf, and int len (char length) as members)
 
String::String(String&& other) //the canonical signature of a move constructor
//first, set the target members to their default values
: buf(nullptr)
, len(0)
{
std::cout << "In String's move constructor. length = "
<<other.len << "." << std::endl;
 
//next, pilfer the source's resources
buf=other.buf;
len=other.len;
//finally, set the source's data members to default values to prevent aliasing
other.buf = nullptr;
other.len=0;
}
 
Shouldn't we delete the this->buf pointer before we set it to nullptr? Or does buf(nullptr) automatically delete what the objects this->buf points to?
red floyd <no.spam@its.invalid>: May 08 09:41AM -0700

On 5/8/2015 9:30 AM, Doug Mika wrote:
> other.len=0;
> }
 
> Shouldn't we delete the this->buf pointer before we set it to nullptr? Or does buf(nullptr) automatically delete what the objects this->buf points to?
 
Why? We're *CREATING* "this". Therefore its buf pointer didn't point
to anything.
Victor Bazarov <v.bazarov@comcast.invalid>: May 08 01:00PM -0400

On 5/8/2015 12:30 PM, Doug Mika wrote:
> I have the following implementation of a move constructor: (it
> assumes
our string class has a char* buf, and int len (char length) as members)
 
> String::String(String&& other) //the canonical signature of a move constructor
> //first, set the target members to their default values
> : buf(nullptr)
 
This is unnecessary if you're writing into it pretty much right away...
 
> , len(0)
 
Same here.
 
 
> //next, pilfer the source's resources
> buf=other.buf;
> len=other.len;
 
It's actually better to initialize *than* assign to. Read the FAQ, I
think there was something like "prefer initialization over assignment"
section, but I can be mistaken.
 
> other.buf = nullptr;
> other.len=0;
> }
 
Generally speaking with the implied declaration of 'String' class, you
need to do
 
String::String(String&& other)
: buf(other.buf)
, len(other.len)
{
other.buf = nullptr;
other.len = 0;
}
 
 
> Shouldn't we delete the this->buf pointer before we set it to
> nullptr?
Or does buf(nullptr) automatically delete what the objects this->buf
points to?
 
See floyd's reply.
 
V
--
I do not respond to top-posted replies, please don't ask
ram@zedat.fu-berlin.de (Stefan Ram): May 08 03:25AM

A compiler compiled this:
 
#include <new>
 
int main()
{ { class ::std::bad_alloc b; }
{ struct ::std::bad_alloc b; }
{ typename ::std::bad_alloc b; }}
 
I was trying to explain, why »class«, »struct«, and
»typename« is allowed here. I found this grammatical
derivation for »class« and »struct«:
 
compound-statement: "{" [statement-seq] "}"
statement-seq: statement | statement-seq statement
statement: declaration-statement
declaration-statement: block-declaration
block-declaration: simple-declaration
simple-declaration: [decl-specifier-seq] [init-declarator-list] ";"
decl-specifier: type-specifier
type-specifier: trailing-type-specifier
trailing-type-specifier: elaborated-type-specifier
elaborated-type-specifier: class-key nested-name-specifier identifier
class-key: "class" | "struct"
 
. But this does not apply to »typename«. Should the
compiler issue a diagnostics?
ram@zedat.fu-berlin.de (Stefan Ram): May 08 03:38AM

>? The second »::« is the binary "scope resolution operator",
>but is the first unary one also called "scope resolution
>operator"?
 
I now see that 5.1.1p8 also calls it a »nested-name-specifier«
(but there are other nested-name-specifiers as well).
bleachbot <bleachbot@httrack.com>: May 08 06:25PM +0200

bleachbot <bleachbot@httrack.com>: May 08 06:25PM +0200

Jorgen Grahn <grahn+nntp@snipabacken.se>: May 08 12:40PM

On Thu, 2015-05-07, Paavo Helde wrote:
> your class as much as possible, to reduce the recompilation times. Having
> simple and straightforward code is way much more important in the long
> term.
 
Yeah. There are sometimes reasons to use pimpl or run-time
polymorphism, but it's not these reasons.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
maddoxr@acm.org: May 08 06:33AM -0700

On Thursday, May 7, 2015 at 6:53:29 PM UTC-4, Norman J. Goldstein wrote:
> cannot do something similar with polymorphism, since the new
> implementation can be an object of a larger size (if you were to try
> using the placement "new" operator, say).
 
So with pimpl you get run-time "hot switching" by virtue of being able to
reassign the internal pointer to refer to a different implementation.
 
How is that very different from having a pointer to a base class and
reassigning that to point to a different derived object? Would you
not consider that to be "hot switching" as well?
 
Randy.
"K. Frank" <kfrank29.c@gmail.com>: May 08 08:00AM -0700

Hello Randy!
 
 
> How is that very different from having a pointer to a base class and
> reassigning that to point to a different derived object? Would you
> not consider that to be "hot switching" as well?
 
You and Norman raise some interesting issues. (Hi Norman!
I see what you mean by "hot switching" now.)
 
I think reassigning a polymorphic pointer is similar to
hot switching with a pimpl class, but not entirely the same.
 
As I understand it, if your class has no state (e.g., it
has member functions, but no data member variables), then
reassigning the polymorphic pointer should count as hot
switching (but, in effect, you're really only reassigning
a function pointer).
 
If your class has state, then (unadorned) polymorphism
won't let you hot switch because if you were to reassign
the polymorphic pointer, you would lose the state of the
pointed-to class.
 
You don't get around this issue for free with pimpl, but
perhaps it lets you package the machinery better.
 
With pimpl in its simplest form, the pointer-to-implementation
points to the entire implementation -- both state and the
member functions of the implementation class. If you have
state and reassign the pointer-to-implementation, you will
also lose the state.
 
So, in this regard, you're right. Reassigning a polymorphic
pointer is pretty much the same as reassigning the
pointer-to-implementation.
 
But if you elaborate pimpl a little, for example, by having
both a pointer to implemented state (member variables) and a
pointer to implemented behavior (member functions), you
could hot switch behavior by reassigning just the latter
without losing state.
 
Of course, if you add some "stuff" to the polymorphic-pointer
approach, you could also keep state while hot switching,
but maybe pimpl lets you encapsulate this more cleanly.
One way of looking at this is that -- from the perspective
of the client code -- the pimpl class has (can have), as
Norman mentioned, value semantics, so it can have state that
survives hot switching (provided, of course, that the author
of the pimpl class has implemented the machinery that gives
the pimpl class proper values semantics and/or manages state).
 
 
> Randy.
 
 
Best regards!
 
 
K. Frank
Kristin Miller <bulldogmommy17@gmail.com>: May 08 06:20AM -0700

Email: kmiller@corus360.com
 
Our client is looking for a knowledgeable senior/principal systems engineer with experience in software development (C++/ OOD, Python, Automation) to join the team to build/ enhance a very cool and successful connected car platform.
 
The team is an exciting, cutting edge, cloud based, large scale processing team. We are looking for a self-motivated, team-player who has experience working with R&D teams to design, develop and deploy production infrastructure.
 
The position requires: a self-starting team player with strong technical and analysis skills, who is excited about working in a high performing team. . Candidates should have 5+ years of professional software development and deployment experience including working knowledge in continuous integration and deployment.
 
Facts about this job:
 
You can work from Chicago, Boston, Atlanta or pretty much where our client has a presence .
 
OO Developer mindset with SCRUM experience
 
Multi- Cloud deployments are part of this project- AWS experience is a plus ad you will be integrating with multiple platforms!
 
Open source practice experience is important
 
Client uses Jira for code reviews
 
Must have C++ - can pick up Python
 
Contract to perm preferred, will consider straight perm for the right candidate.
Ben Bacarisse <ben.usenet@bsb.me.uk>: May 08 12:31PM +0100

> decl-specifier: type-specifier
> type-specifier: trailing-type-specifier
> trailing-type-specifier: elaborated-type-specifier
 
Another production is /typename-specifier/ which has almost the same
syntax as /elaborated-type-specifier/:
 
typename ["::"] nested-name-specifier identifier
 
 
--
Ben.
qunimade168@126.com: May 08 03:05AM -0700

Cheap D&G Shoes Prada shoes Tod's Shoes Hermes Shoes Gucci Shoes Dsquared2 Shoes LV Shoes Dior Shoes Bally Shoes wholesale www.FashionLeader.nl
qunimade168@126.com: May 08 03:03AM -0700

www.FashionLeader.nl
 
Discount Cheap Free Shipping Wholesale D&G Shoes,Gucci Shoes,Dsquared2 Shoes,Prada shoes,LV shoes,Ugg Boots,Nike Shoes Jordan shoes,Shox NZ R4 shoes,Aidias
 
shoes,Puma shoes,Timberland boots,t-shirts,jeans,underwear,handbags,belts,wallets,sunglasses,caps,watches,jerseys,clothes,Monster headphones...
 
 
 
 
Cheap UGG Boots men's women's wholesale www.FashionLeader.nl
Cheap Moncler down Jackets Moncler shoes t-shirts www.FashionLeader.nl
Cheap Air Max 2015 Shoes Air Jordan 29 Shoes wholesale www.FashionLeader.nl
Cheap Air Jordan XX9 Shoes Air Jordan 29 Shoes wholesale www.FashionLeader.nl
Cheap Air Max 2015 Shoes Air Max Classic BW Shoes Air Max 90 Shoes Air Max 87 LTD Shoes wholesale www.FashionLeader.nl
 
Cheap Air Max 2015 Shoes men's women's wholesale www.FashionLeader.nl
Cheap Air Max 90 Shoes men's women's wholesale www.FashionLeader.nl
Cheap Air Max 87 Shoes men's women's wholesale www.FashionLeader.nl
Cheap Air Max Classic BW 91 Shoes cccccmen's women's wholesale www.FashionLeader.nl
Cheap Air Max LTD Shoes men's women's wholesale www.FashionLeader.nl

Cheap Air Max 90 Shoes Air Max 90 Hyperfuse/Hyp Prm Shoes Air Max 90 VT Shoes wholesale www.FashionLeader.nl
 
Cheap Air Max 87 Shoes Air Max 87 Hyperfuse Shoes wholesale www.FashionLeader.nl
 
Cheap Air Max Classic BW Shoes Air Max Classic BW VT Shoes wholesale www.FashionLeader.nl
 
Cheap D&G shoes D&G Jackets D&G Jeans D&G Handbags D&G sunglass D&G wallets D&G belts wholesale www.FashionLeader.nl
 
Cheap Gucci shoes Gucci Jackets Gucci Jeans Gucci Handbags Gucci sunglass Gucci wallets Gucci belts wholesale www.FashionLeader.nl
 
Cheap Dsquared2 Shoes Dsquared2 Jackets Dsquared2 Jeans wholesale www.FashionLeader.nl
 
Cheap Prada shoes Prada T-shirts Prada Jeans Prada Handbags Prada sunglass Prada wallets Prada belts wholesale www.FashionLeader.nl
 
Cheap D&G Shoes Prada shoes Tod's Shoes Hermes Shoes Gucci Shoes Dsquared2 Shoes LV Shoes Dior Shoes Bally Shoes wholesale www.FashionLeader.nl
 

Cheap Ugg Boots wholesale Ugg Boots men's women's kid's wholesale www.FashionLeader.nl
 
Cheap Jordan 29 Shoes Timberland boots,Aidias shoes,Puma shoes wholesale www.FashionLeader.nl
 
Cheap A&F Jackets A&F T-shirts A&F Jeans men's women's wholesale www.FashionLeader.nl
 
Cheap D&G Jackets Gucci Jackets Dsquared2 Jackets A&F Jackets Moncler Down Jackets Canada Goose Down Jackets www.FashionLeader.nl
 
Cheap Gucci T-shirt A&F T-shirts Armani T-shirts LV T-shirt D&G T-shirt Burberry T-shirt CK T-shirt G-Star T-shirt Prada T-shirt www.FashionLeader.nl
 
Cheap Armani Jeans,G-Star Jeans,GUCCI Jeans,Levi's Jeans,Laguna Beach Jeans,LV Jeans,Prada Jeans,TR Jeans,Versace Jeans,CK Jeans,Dsquared2 Jeans,D&G
 
Jeans,DIESEL Jeans,Evisu Jeans wholesale www.FashionLeader.nl
 
 
Cheap AE Bikini A&F Biniki Armani Bikini Burberry Bikini CA Christian Audigier Bikini Chanel Bikini Chloe Bikini Coach Bikini D&G Bikini Dior Bikini ED Hardy
 
Bikini Fendi Bikini Gucci Bikini www.FashionLeader.nl
 
Cheap Ray.Ban Sunglass Armani Sunglass burberry Sunglass Cartier Sunglass Cavalli Sunglass Chanel Sunglass Coach Sunglass Dior Sunglass D&G Sunglass Fendi
 
Sunglass Gucci Sunglass LV Sunglass Prada Sunglass Versace Sunglass www.FashionLeader.nl
 
Cheap Hermes Handbag Gucci Handbag D&G HandBag Burberry Handbag Chanel Handbag MK Handbag LV Handbag Prada Handbag Chloe Handbag Coach Handbag Fendi Handbag
 
www.FashionLeader.nl
 
Cheap Herve Leger Dress Bandage Dress and Skirts Wholesale.Best Herve Leger Dress online dealer,supplying Herve Leger Dresses www.FashionLeader.nl
 
Cheap Ray.Ban Sunglass Armani Sunglass burberry Sunglass Cartier Sunglass Cavalli Sunglass Chanel Sunglass Coach Sunglass Dior Sunglass D&G Sunglass Fendi
 
Sunglass Ferragamo Sunglass Gucci Sunglass LV Sunglass Okey Sunglass Prada Sunglass Versace Sunglass CARRERA Sunglass Wholesale www.FashionLeader.nl
 
 
Cheap D&G HandBags Burberry Handbag Chanel Handbag Hermes Handbag LV Handbag Prada Handbag Chloe Handbag Coach Handbag Fendi Handbag Gucci Handbag
 
www.FashionLeader.nl
 
Cheap Audemars Piguet Watches,Blancpain Watches,Breguet Watches,Cartier Watches,Jaeger LeCoultre Watches,Patek Philippe Watches,Piaget Watches,Rolex
 
Watches,Vacheron Constantin Watches www.FashionLeader.nl
 
 
Cheap Alexander McQueen Heels,Armani Hells,Chanel Heels,Chloe Hells,Christian Louboutin Heels,D&G Heels,Dior Heels,Fendi Heels,Ferragamo Heels,Gucci
 
Heels,Hermes Heels,Jimmy choo Heels,LV Heels,wholesale www.FashionLeader.nl
 
Cheap Manolo Blahnik Heels,Miu Miu Heels,Prada Heels,Roger Vivier Heels,Sergio Rossi Heels,Tory Burch Heels,Versace Heels,YSL Heels wholesale
 
www.FashionLeader.nl
1971 powerChina <chinapower1971@gmail.com>: May 08 12:02AM -0700

在 2004年11月30日星期二 UTC+8上午5:28:46，Matthias Käppler写道：
 
> Any suggestions?
 
> Thanks,
> Matthias
 
Title: The core of the big data solutions -- Map
Author: pengwenwei
Email: pww71 foxmail.com
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: A high performance map algorithm
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)
 
Map is widely used in c++ programs. And the bottleneck of program performance is often the performance of map. especially in big data field and the scenarios which can't realize data distribution and parallel processing. Therefore, the performance of map becomes the most critical technology.
 
My many years of work experience in telecommunition and information security industry Is all about big data analysis. especially in the information security industry, the data analysis is the most complicated. They can't work without map. For example, ip table, mac table, telephone numbers table, dns table etc.
 
 
Currently, the STL map and Google's hash map are the most popular maps. But they have some disadvantages. The STL map utilizes binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of repeat collision. For big data analysis, the probability of repeat collision is unacceptable.
 
Now I would like to publish my algorithms. It includes three different maps for different scenarios:
1. Memory Map(memMap): It resides in memory and has a good access speed. But its size is limited by memory size.
2. Harddisk Map(diskMap): It utilizes hard disk to store data. So it could accept much more data than memory map.
3. Hashmap(hashMap): It has the best performance and a great lookup speed, but it doesn't have 'insert' and 'delete' functionality.
 
memMap and diskMap could be converted to hashMap by function memMap2HashMap and diskMap2HashMap. According to the test result, my algorithms' collision probability is zero. About performance, memMap has a comparable performance with google, and hashMap's performance is 100 times better than Google's hashmap.
 
In summary, my algorithms are perfect zero collision probability hash algorithms.You can refer to following artical to find the key index and compress algorithm theory:
http://blog.csdn.net/chixinmuzi/article/details/1727195
 
Source code and documents:
https://sourceforge.net/projects/pwwhashmap/files/?source=navbar
1971 powerChina <chinapower1971@gmail.com>: May 08 12:01AM -0700

Title: The core of the big data solutions -- Map
Author: pengwenwei
Email: pww71 foxmail.com
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: A high performance map algorithm
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)
 
Map is widely used in c++ programs. And the bottleneck of program performance is often the performance of map. especially in big data field and the scenarios which can't realize data distribution and parallel processing. Therefore, the performance of map becomes the most critical technology.
 
My many years of work experience in telecommunition and information security industry Is all about big data analysis. especially in the information security industry, the data analysis is the most complicated. They can't work without map. For example, ip table, mac table, telephone numbers table, dns table etc.
 
 
Currently, the STL map and Google's hash map are the most popular maps. But they have some disadvantages. The STL map utilizes binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of repeat collision. For big data analysis, the probability of repeat collision is unacceptable.
 
Now I would like to publish my algorithms. It includes three different maps for different scenarios:
1. Memory Map(memMap): It resides in memory and has a good access speed. But its size is limited by memory size.
2. Harddisk Map(diskMap): It utilizes hard disk to store data. So it could accept much more data than memory map.
3. Hashmap(hashMap): It has the best performance and a great lookup speed, but it doesn't have 'insert' and 'delete' functionality.
 
memMap and diskMap could be converted to hashMap by function memMap2HashMap and diskMap2HashMap. According to the test result, my algorithms' collision probability is zero. About performance, memMap has a comparable performance with google, and hashMap's performance is 100 times better than Google's hashmap.
 
In summary, my algorithms are perfect zero collision probability hash algorithms.You can refer to following artical to find the key index and compress algorithm theory:
http://blog.csdn.net/chixinmuzi/article/details/1727195
 
Source code and documents:
https://sourceforge.net/projects/pwwhashmap/files/?source=navbar
1971 powerChina <chinapower1971@gmail.com>: May 08 12:01AM -0700

在 2000年5月9日星期二 UTC+8下午3:00:00，Joe Higgins写道：
> classic iostreams issue.
 
> Any suggestions/pointers or help appreciated.
 
> Regards, Joe
 
Title: The core of the big data solutions -- Map
Author: pengwenwei
Email: pww71 foxmail.com
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: A high performance map algorithm
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)
 
Map is widely used in c++ programs. And the bottleneck of program performance is often the performance of map. especially in big data field and the scenarios which can't realize data distribution and parallel processing. Therefore, the performance of map becomes the most critical technology.
 
My many years of work experience in telecommunition and information security industry Is all about big data analysis. especially in the information security industry, the data analysis is the most complicated. They can't work without map. For example, ip table, mac table, telephone numbers table, dns table etc.
 
 
Currently, the STL map and Google's hash map are the most popular maps. But they have some disadvantages. The STL map utilizes binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of repeat collision. For big data analysis, the probability of repeat collision is unacceptable.
 
Now I would like to publish my algorithms. It includes three different maps for different scenarios:
1. Memory Map(memMap): It resides in memory and has a good access speed. But its size is limited by memory size.
2. Harddisk Map(diskMap): It utilizes hard disk to store data. So it could accept much more data than memory map.
3. Hashmap(hashMap): It has the best performance and a great lookup speed, but it doesn't have 'insert' and 'delete' functionality.
 
memMap and diskMap could be converted to hashMap by function memMap2HashMap and diskMap2HashMap. According to the test result, my algorithms' collision probability is zero. About performance, memMap has a comparable performance with google, and hashMap's performance is 100 times better than Google's hashmap.
 
In summary, my algorithms are perfect zero collision probability hash algorithms.You can refer to following artical to find the key index and compress algorithm theory:
http://blog.csdn.net/chixinmuzi/article/details/1727195
 
Source code and documents:
https://sourceforge.net/projects/pwwhashmap/files/?source=navbar
1971 powerChina <chinapower1971@gmail.com>: May 07 11:41PM -0700

Title: The core of the big data solutions -- Map
Author: pengwenwei
Email: pww71 foxmail.com
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: A high performance map algorithm
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)
 
Map is widely used in c++ programs. And the bottleneck of program performance is often the performance of map. especially in big data field and the scenarios which can't realize data distribution and parallel processing. Therefore, the performance of map becomes the most critical technology.
 
My many years of work experience in telecommunition and information security industry Is all about big data analysis. especially in the information security industry, the data analysis is the most complicated. They can't work without map. For example, ip table, mac table, telephone numbers table, dns table etc.
 
 
Currently, the STL map and Google's hash map are the most popular maps. But they have some disadvantages. The STL map utilizes binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of repeat collision. For big data analysis, the probability of repeat collision is unacceptable.
 
Now I would like to publish my algorithms. It includes three different maps for different scenarios:
1. Memory Map(memMap): It resides in memory and has a good access speed. But its size is limited by memory size.
2. Harddisk Map(diskMap): It utilizes hard disk to store data. So it could accept much more data than memory map.
3. Hashmap(hashMap): It has the best performance and a great lookup speed, but it doesn't have 'insert' and 'delete' functionality.
 
memMap and diskMap could be converted to hashMap by function memMap2HashMap and diskMap2HashMap. According to the test result, my algorithms' collision probability is zero. About performance, memMap has a comparable performance with google, and hashMap's performance is 100 times better than Google's hashmap.
 
In summary, my algorithms are perfect zero collision probability hash algorithms.You can refer to following artical to find the key index and compress algorithm theory:
http://blog.csdn.net/chixinmuzi/article/details/1727195
 
Source code and documents:
https://sourceforge.net/projects/pwwhashmap/files/?source=navbar
1971 powerChina <chinapower1971@gmail.com>: May 07 11:38PM -0700

Title: The core of the big data solutions -- Map
Author: pengwenwei
Email: pww71 foxmail.com
Language: c++
Platform: Windows, linux
Technology: Perfect hash algorithm
Level: Advanced
Description: A high performance map algorithm
Section MFC c++ map stl
SubSection c++ algorithm
License: (GPLv3)
 
Map is widely used in c++ programs. And the bottleneck of program performance is often the performance of map. especially in big data field and the scenarios which can't realize data distribution and parallel processing. Therefore, the performance of map becomes the most critical technology.
 
My many years of work experience in telecommunition and information security industry Is all about big data analysis. especially in the information security industry, the data analysis is the most complicated. They can't work without map. For example, ip table, mac table, telephone numbers table, dns table etc.
 
 
Currently, the STL map and Google's hash map are the most popular maps. But they have some disadvantages. The STL map utilizes binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of repeat collision. For big data analysis, the probability of repeat collision is unacceptable.
 
Now I would like to publish my algorithms. It includes three different maps for different scenarios:
1. Memory Map(memMap): It resides in memory and has a good access speed. But its size is limited by memory size.
2. Harddisk Map(diskMap): It utilizes hard disk to store data. So it could accept much more data than memory map.
3. Hashmap(hashMap): It has the best performance and a great lookup speed, but it doesn't have 'insert' and 'delete' functionality.
 
memMap and diskMap could be converted to hashMap by function memMap2HashMap and diskMap2HashMap. According to the test result, my algorithms' collision probability is zero. About performance, memMap has a comparable performance with google, and hashMap's performance is 100 times better than Google's hashmap.
 
In summary, my algorithms are perfect zero collision probability hash algorithms.You can refer to following artical to find the key index and compress algorithm theory:
http://blog.csdn.net/chixinmuzi/article/details/1727195
 
Source code and documents:
https://sourceforge.net/projects/pwwhashmap/files/?source=navbar
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)