Tuesday, August 18, 2015

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

Christopher Pisz <nospam@notanaddress.com>: Aug 18 11:44AM -0500

I am trying to use a boost::variant type to set values that go into the
Windows registry in my wrapper class, since they can be strings or 32bit
ints or 64 bit ints.
 
According to thier write up, you use a visitor pattern with it. I've
never used the visitor pattern.
 
I can't seem to figure out how to pass other needed data to the class
that implements the visitor pattern and how to get a return value from it.
 
I've got this visitor so far:
 
// Write the current set of value name - value pairs
class WriteVisitor : boost::static_visitor<>
{
public:
 
LONG operator() (HKEY registryKey, int & value) const
{
return RegSetValueExA(registryKey, NULL, 0, REG_DWORD,
reinterpret_cast<const BYTE *>(&value), sizeof(int));
}
 
LONG operator() (HKEY registryKey, std::string & value) const
{
return RegSetValueExA(registryKey, NULL, 0, REG_SZ,
reinterpret_cast<const BYTE *>(value.c_str()), value.size() + 1);
}
};
 
 
 
and I've got this type I want to pass to it as "value"
typedef boost::variant<std::string, int> RegistryValueType;
 
 
and I want to get the LONG result.
 
I'm not sure how to call it or if I made the visitor correctly. Help pls.
 
 
 
 
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
"Öö Tiib" <ootiib@hot.ee>: Aug 18 03:07PM -0700

On Tuesday, 18 August 2015 19:44:46 UTC+3, Christopher Pisz wrote:
> never used the visitor pattern.
 
> I can't seem to figure out how to pass other needed data to the class
> that implements the visitor pattern and how to get a return value from it.
 
Typically parameters are passed with constructor of visitor object and
return value type as template argument of base type. I try to comment inline.
 
 
> I've got this visitor so far:
 
> // Write the current set of value name - value pairs
> class WriteVisitor : boost::static_visitor<>
 
That to be "static_visitor<LONG>"
 
> {
> public:
 
 
Constructor from 'HKEY' and store it as member. IOW:
 
WriteVisitor( HKEY registryKey )
: registryKey_(registryKey)
{}
 
HKEY registryKey_;
 

> return RegSetValueExA(registryKey, NULL, 0, REG_SZ,
> reinterpret_cast<const BYTE *>(value.c_str()), value.size() + 1);
> }
 
Change these to unary operators that use 'registryKey_' member instead
of first argument.
 
> typedef boost::variant<std::string, int> RegistryValueType;
 
> and I want to get the LONG result.
 
> I'm not sure how to call it or if I made the visitor correctly. Help pls.
 
If you did the changes then something like:
 
RegistryValueType rval = ...; // fill the ...
HKEY hkey = ...; // fill the ...

if ( boost::apply_visitor( WriteVisitor(hkey), rval ) != ERROR_SUCCESS )
{
// handle windows api error ...
}
 
It might do the trick. ;)
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 18 02:43AM -0700

I recently get some thought about some
programming milestone:
 
I remember when i was a newbie compile errors
scary me: i was newer sure if i will be able to
mend them, what some mean, how to ment them
 
with years they become less scary and finally
quite recently i found the situation that compile
errors are like absolute zero-scary (they are only like underscore in english syntax checker)
 
I found this situation as a some kind of programming milestone.. wonder if others
go also thru that and WHEN they pass thru such
milesone (how may years ago)
 
maybe some other seen milestones you find important on the way of becoming more advanced programmer?
Paavo Helde <myfirstname@osa.pri.ee>: Aug 18 02:05PM -0500

Prroffessorr Fir Kenobi <profesor.fir@gmail.com> wrote in
 
> I remember when i was a newbie compile errors
> scary me: i was newer sure if i will be able to
> mend them, what some mean, how to ment them
 
Compiler errors are a way how the compiler writers try to help me in
developing programs, why on earth they should scary me?
 
> milesone (how may years ago)
 
> maybe some other seen milestones you find important on the way of
> becoming more advanced programmer?
 
Maybe when I really understood that any code which is not properly covered
by unit tests is deemed to get rotten and buggy in a very short timeframe
(especially when it is a part of an actively developed large project or
system, of course, but that's basically all I do).
 
Cheers
Paavo
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 18 12:44PM -0700

W dniu wtorek, 18 sierpnia 2015 21:06:06 UTC+2 użytkownik Paavo Helde napisał:
> system, of course, but that's basically all I do).
 
> Cheers
> Paavo
 
well they scared me in older times..
right now for example protection-fault
crashes can scary me a bit* (though not much -
more probably im scared by library imcompatinbilities, (potential) lack of documentations and such things
 
but maybe im too easily scared
 
* doeas maybe someone know how to setup
a handler for such things as sse misalignment
fault to get as much info as i can get?
(win32/mingw)
Vir Campestris <vir.campestris@invalid.invalid>: Aug 18 09:18PM +0100

On 18/08/2015 20:05, Paavo Helde wrote:
> Compiler errors are a way how the compiler writers try to help me in
> developing programs, why on earth they should scary me?
 
I've seen template compilation errors that scare me.
 
Because I know I'll have to spend the next 15 minutes decoding what was
actually wrong.
 
Andy
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 18 01:30PM -0700

W dniu wtorek, 18 sierpnia 2015 22:18:45 UTC+2 użytkownik Vir Campestris napisał:
 
> I've seen template compilation errors that scare me.
 
> Because I know I'll have to spend the next 15 minutes decoding what was
> actually wrong.
 
ye thats the main reason of being scared - you will spend sometimes undefinite amount of time
on aggreviating error repairs
 
im most scared when begining to set in motion some new things with a lot of potential pitfalls
jt@toerring.de (Jens Thoms Toerring): Aug 18 09:01PM


> I've seen template compilation errors that scare me.
 
> Because I know I'll have to spend the next 15 minutes decoding what was
> actually wrong.
 
I had several cases lately where, for a single mistake (I think
it was a missing comma or something trivial like that), the com-
piler spewed about 1800 lines of error messages at me (and
most lines were several hundreds of characters wide). Ok, that
was in conjunction with boost::python, but there was no chance
of ever "decoding" that, not even using the tactic of "let's
skip everything that looks like gibberish and concentrate on
the first line that seems to make a bit of sense";-) Not really
scary but a bit annoying. Sometimes I wouldn't mind having a
compiler flag to request "tone it down a bit on the details,
I don't need to be reminded 500 times what a std::string is
in all the gory details" to be able to see the actual trees in
all of that forest...
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Paavo Helde <myfirstname@osa.pri.ee>: Aug 18 04:01PM -0500

Vir Campestris <vir.campestris@invalid.invalid> wrote in
 
> I've seen template compilation errors that scare me.
 
> Because I know I'll have to spend the next 15 minutes decoding what was
> actually wrong.
 
That's counterproductive. There is a simple way how to fix scary template
compile errors: first, try to add 'typename' somewhere; if not helping, try
to add 'template' somewhere; if all else fails, google for how the template
should actually be written.
 
I'm only half-joking!
 
Cheers
Paavo
drawoh201@gmail.com: Aug 18 04:34AM -0700

> system(connstr);
> }
 
> When I use gdb, it says that the segsegv happened at the last curly brace, but that doesn't make sense, it always happens at logout. Any clues what is causing this would be immensely helpful.
 
Hi
 
Thanks guys, I have changed my code to use std::string instead of raw character strings and I have rid me of segmentation violations.
 
Thanks all for pointing the problem areas out for me.
 
ciao
scott@slp53.sl.home (Scott Lurndal): Aug 18 01:58PM


>I'm not really sure how this is a "counter example".
 
>A counter example would be an example of why you *should* use C-isms
>in C++.
 
snprintf vs. "<<" and ">>" should be sufficient to show
how the readability (and maintainability) of C++ code is
improved by selective use of C run-time library functions.
 
You, like Stefan, seem to think that only "pure" C++ is
useful or valid, which is far from the actual truth.
 
 
 
>By all means, if you want to write C, then please head on over to
>comp.lang.c, contribute to the unix kernel, or whatever.
 
Believe that I _have_ contributed to both the unix kernels and
the linux kernels (and even the oracle RDBM core).

 
>However,
>please stop teaching people that writing good C++ means using C-isms.
 
However, you have no right to make such a silly demand. There
are many cases where using C run-time library functions and C
idioms in C++ code is perfectly valid. It's perfectly legal use
of the C++ language as well.
 
 
>multi-decadal cumulative experience with real-world teams. This advice
>is echoed by Bjarne Stroustrup in "C++ Programming Language", 4th ed. as
>well as recent talks he has given on the nature of C++:
 
I tend to find appeals to authority less of interest than the
experience gained over 30+ years developing very large C++ software projects.
 
 
>while still yielding efficient code execution. In many cases the
>abstractions are literally free when compared to the low-level detail
>oriented code you would need to write in C to achieve the same end result.
 
I don't discount at all the advantages provided by object
abstraction - I use them heavily; particularly pure abstract classes
as 'interfaces' in the java sense.
 
I don't believe in the fanatical pursuit of language purity at the
expense of functionality, readability or performance.
legalize+jeeves@mail.xmission.com (Richard): Aug 18 03:56PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
 
>snprintf vs. "<<" and ">>" should be sufficient to show
>how the readability (and maintainability) of C++ code is
>improved by selective use of C run-time library functions.
 
I disagree because of the large number of errors that I have seen
w.r.t. use of printf style functions over the years. You are, of
course, free to do whatever you want. But I will continue to counsel
against it based on many years of experience on many teams where
entire classes of bugs simply disappeared from our code because we
stopped using printf style code.
 
I would make an exception where the performance is important and measured
to be slower with stream insertion operators and this was the dominant
factor in the performance analysis. However, this is a case where we
are intentionally using more error-prone means to achieve a given end
because other factors are an overriding concern. Even here, there
are wrappers C++ around printf that can alleviate some, but not all,
of it's problems and these would be preferred over direct usage of printf.
 
>You, like Stefan, seem to think that only "pure" C++ is
>useful or valid, which is far from the actual truth.
 
I have no idea what "pure" C++ is according to you. I haven't said
any such thing in any of my posts.
 
I'm saying that C programming habits routinely introduce problems that
are easily avoided by using C++ programming habits instead. Among
other things, that means preferring the C++ standard library over the
C standard library. Please read that sentence carefully, because I
don't want it to be re-interpreted into another straw-man argument
about some absolutist style "demand".
 
>>comp.lang.c, contribute to the unix kernel, or whatever.
 
> Believe that I _have_ contributed to both the unix kernels and
>the linux kernels (and even the oracle RDBM core).
 
Great for you. Please do continue to write C and contribute to C
based projects as you see fit. However, I will continue to counsel
against C-style programming when programming in C++. While C++ may be
mostly compatible with C, my advice has been and will continue to be
that you should stop thinking C when writing C++ and think in C++
terms instead.
 
>>However,
>>please stop teaching people that writing good C++ means using C-isms.
 
> However, you have no right to make such a silly demand.
 
Where am I making a "demand"? That is you creating a straw man
argument by making up things I haven't said. I will continue to
advise and request that people stop using C style habits when
programming in C++.
 
>are many cases where using C run-time library functions and C
>idioms in C++ code is perfectly valid. It's perfectly legal use
>of the C++ language as well.
 
Another straw-man argument. Nowhere have I said it was invalid or
illegal to use C style programming habits.
 
I have said, and will continue to say, that programming with C-isms
(e.g. using C style programming habits) is an error-prone, unnecessarily
low-level (e.g. devoid of higher levels of abstraction) and therefore
much more verbose than the C++ equivalent mechanisms.
 
>I tend to find appeals to authority less of interest than the
>experience gained over 30+ years developing very large C++ software projects.
 
My point was less an appeal to authority as simply pointing out that
I am not sone "lone usenet net.crank" in advocating this point of
view. It is, in fact, quite commonly advocated among the leading C++
practitioners in the field, which includes the designer of the language.
If you want to interpret that as an appeal to authority, then fine,
by all means ignore my advice as well as the similar advice of people
like Herb Sutter, Bjarne Stroustrup, James McNellis, Kate Gregory,
all the wonderful speakers at places like CppCon, C++ Now! and so-on.
I am not saying that automatically all those people agree with me 100%
on everything, but I am saying that the advice I've been giving here in
this newsgroup is consistent with the same advice I hear from them when
I listen to their talks on youtube or when I have had the pleasure of
talking to them in person.
 
I state my recommendations and advice based on real-world experience in
many teams at different companies over a long period of time. I have led
instruction in the C++ standard library to make teams aware of how C++
and the standard library provides tools for common programming problems
(such as string manipulation; which is how this whole tangent got started)
that are less error-prone than their C counterparts. As a result,
entire classes of problems simply disappeared from our code because we
stop writing code in the C style and embraced C++ fully.
 
>I don't believe in the fanatical pursuit of language purity at the
>expense of functionality, readability or performance.
 
The "fanatical pursuit of language purity" you speak of seems to be
embodied by the straw man arguments cited earlier in this post. I
don't even know what "language purity" means; you are the one who is
introducing these terms, not me.
 
I don't even understand how one can argue that C style programming
embraces more functionality than C++ style programming since you've
already admitted C++'s ability to be (largely) backwards compatible
with C.
 
Readability is a subjective phenomenon and I don't know any way to
objectively measure it in a manner that all programmers can agree with
the measurement. I am more than willing to describe examples of C style
programming that I think impair readability. It almost always is a
result of insufficient use of abstraction that impairs the ability to
express directly the intention of the programmer. In my day-to-day
programming within a team my suggestions to improve readability almost
always revolve around eliminating duplication, simplifying syntax and
introducing abstractions with intention revealing names in order to
improve readability.
 
As for performance there are specific examples where C++ code outperforms
C standard library functions and programming habits. There are also
cases where the performance of a C style approach, such as printf,
exceeds C++. However, the exception shouldn't become the rule. By that I
mean that simply because printf can outperform stream insertion for some
particular piece of code, doesn't mean that one should systematically
reject all things C++ for all things C. Nor does it mean "stream
insertion operators are bad" because most of the time the performance
difference isn't significant and there are advantages of stream
insertion operators over printf.
 
If you want to use printf and other C style programming habits
routinely, then my recommendation is to not program in C++ and instead
program in C. Then you can advocate C style programming practices to
the C community instead of advocating C style programming to the C++
community. I will continue to advocate C++ style programming habits
and the avoidance of C style programming habits to the C++ community.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 18 01:15AM -0700

This night run my first gpu c code that is doing something and made some tests
 
this is a simple mandelbrot drwing code, first i
run scalar version
 
 
 
int mandelbrot_n( float cRe, float cIm, int max_iter )
{
float re = cRe;
float im = cIm;
 
float rere=re*re;
float imim=im*im;
 
for(int n=1; n<=max_iter; n++)
{
 
im = (re+re)*im + cIm;
re = rere - imim + cRe;
 
rere=re*re;
imim=im*im;
 
if ( (rere + imim) > 4.0 )
return n;
 
 
}
 
return 0;
 
}
 
for 256 x256 x 1000 iteration it take 90 ms
 
 
then i made sse intrinsic version
 
__attribute__((force_align_arg_pointer))
__m128i mandelbrot_n_sse( __m128 cre, __m128 cim, int max_iter )
 
{
__m128 re = _mm_setzero_ps();
__m128 im = _mm_setzero_ps();
 
 
__m128 _1 = _mm_set_ps1(1.);
__m128 _4 = _mm_set_ps1(4.);
 
__m128 iteration_counter = _mm_set_ps1(0.);
 
 
for(int n=0; n<=max_iter; n++)
{
 
__m128 re2 = _mm_mul_ps(re, re);
__m128 im2 = _mm_mul_ps(im, im);
__m128 radius2 = _mm_add_ps(re2,im2);
 
__m128 compare_mask = _mm_cmplt_ps( radius2, _4);
iteration_counter = _mm_add_ps( iteration_counter, _mm_and_ps(compare_mask, _1) );
if (_mm_movemask_ps(compare_mask)==0) break;
 
__m128 ren = _mm_add_ps( _mm_sub_ps(re2, im2), cre);
__m128 reim = _mm_mul_ps(re, im);
 
__m128 imn = _mm_add_ps( _mm_add_ps(reim, reim), cim);
 
re = ren;
im = imn;
 
 
}
 
__m128i n = _mm_cvtps_epi32(iteration_counter);
 
return n;
}
 
this run 20 ms (more that 4 times faster, dont know why)
 
(the procesor i run is anyway old core2 e6550 2.33GHz - i got better machine with avx support but didnt use it here yet)
 
 
then i make opencl code
 
"__kernel void square( \n" \
" __global int* input, \n" \
" __global int* output, \n" \
" const unsigned int count) \n" \
"{ \n" \
" int i = get_global_id(0); \n" \
" if(i < count) \n" \
" { \n" \
" int x = i%256; \n" \
" // if(x>=256) return; \n" \
" int y = i/256; \n" \
" // if(y>=256) return; \n" \
" float cRe = -0.5 + -1.5 + x/256.*3.; \n" \
" float cIm = 0.0 + -1.5 + y/256.*3.; \n" \
" float re = 0; \n" \
" float im = 0; \n" \
" int n = 0; \n" \
" for( n=0; n<=1000; n++) { \n" \
" if( re * re + im * im > 4.0 ) { output[256*y+x] = n + 256*n + 256*256*n; return;} \n" \
" float re_n = re * re - im * im + cRe; \n" \
" float im_n = 2 * re * im + cIm; \n" \
" re = re_n; \n" \
" im = im_n; \n" \
" } \n" \
" output[256*y+x] = 250<<8; \n" \
" } \n" \
"} \n" \
"\n";
 
this works with not a problem and works at 7 ms
(i got weak gpu gt610)
 
How to optimise this gpu version? Is it common to write such scalar code on gpu, maybe there is some way of writing something like sse intrinsics here? or other kind of optimisation?
 
 
(anyway i must say that thiose critics of gpu /opencl coding i dont fully agree this works
easy and fine - at least for some cases, (esp good is that it has not to much slowdown when
runing gpu from cpu and getting back results
- it seem i can run it in the 1 milisecond
window, so its very fine) i belive that with harder codes it may getting slower, but also belive with better card i may go also better than 7 ms)
Juha Nieminen <nospam@thanks.invalid>: Aug 18 01:02PM

> " if( re * re + im * im > 4.0 ) { output[256*y+x] = n + 256*n + 256*256*n; return;} \n" \
 
> How to optimise this gpu version?
 
GPU shaders don't like conditionals. They are usually very slow. (A loop with
a fixed number of iterations is usually ok, though.) You could to see if you
could get rid of that conditional, and whether it makes it faster or slower.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Aug 18 07:11AM -0700

W dniu wtorek, 18 sierpnia 2015 15:02:31 UTC+2 użytkownik Juha Nieminen napisał:
 
> GPU shaders don't like conditionals. They are usually very slow. (A loop with
> a fixed number of iterations is usually ok, though.) You could to see if you
> could get rid of that conditional, and whether it makes it faster or slower.
 
maybe it would be good way but how..
well i will try to google something
1971 powerChina <chinapower1971@gmail.com>: Aug 17 06:44PM -0700

Title: The core of the big data solutions -- Map.
Author: pengwenwei
address: Xianggan Batang District 17-18 xiangtan City, Hunan China
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. Its performance is critical to programs' performance. Especially in big data and the scenarios which can't realize data distribution and parallel processing.
 
I have been working on big data analysis for many years in telecommunition and information security industry. The data analysis is so complicated that they can't work without map. Especially in information security industry, the data is much more complicated than others. 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 is based on binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of collision. For big data analysis, the collision probability is unacceptable.
 
Now I would like to publish pwwMap. It includes three different maps for different scenarios:
1. Memory Map(memMap): It 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, pwwhash are perfect hash algorithms with zero collision probability. 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)