How to translate >> to VB

[swatty]

I've seen a syntax line in C like

*crcres = *crcres >> 1

does someone know what this does and how to write it in VB

Advanced thanks

[parksie]

It does a binary right-shift by one bit.

As far as I know, VB can't do that...

[si_the_geek]

It's similar to this:

crcres = crcres \ 2

..but I don't think that maps exactly to the function you specified

[jim mcnamara]

Lokks like you're doing CRC32 - attached is a VB version plus dll

[Zaei]

Originally posted by swatty
*crcres = *crcres >> 1

Shoulda been

(*crcres) >>= 1;

=).

Z.

[jim mcnamara]

Yeah - like strlen is really something like:

 for(buf=string, i=0;*buf;buf++) i++; return i;

when it's not assembler.

Our core C code is: -abstracted, inlined, jammed, proffed, and reduced to the max. But, that doesn't mean a new guy should ever try it.

[parksie]

/me completely fails to grok that last sentence...

[Zaei]

You know it jim, but regardless, it should be drilled into the brain of newcomers that using the <operator>= operators when appropriate is GOOD!

=).

Z.

[jim mcnamara]

Z.
uh huh... But most people who post here couldn't really read the stuff. I routinely 'tone down' everything I post. The idea is to communicate, not obfuscate. 90% of what I do is in ANSI C.

Parksie -
don't you try to inline, jam, etc, your core code? ie., optimize the living doo-doo out of your code? Especially the core code - primitives? We clock() on everything because the stuff gets called hundreds of millions of times a day. Literally. 5% gets you five minutes.

We have tables that have 100 million+ records. Full table scans net lots of traffic into the core modules. For example, Archive-purge runs over 10 hours. We want it to run in 5 or less.
It cleans out datasets.

[Zaei]

100 million... my mind boggles at that number =).

I know what you mean. Things that seem really obvious to me now wont even occur to someone who has only been using c/c++ for a few months... and again, in a year or so, there will be things that are just natural where they wouldnt even have occured to me now.

Z.

[CornedBee]

If you have such heavily frequented code you might consider writing the tightest loops in assembler.

To translate bitshifts to VB you can use division/multiplication, it's just that it is much slower.

var <<= i;
=
var = var * 2^i

var >>= i;
=
var = var / 2^i

[Zaei]

Use the integer divide, in this case, as it is faster:

var  = var \ 2^i

Z.

[CornedBee]

And prduces better results, as you don't want it to be converted to a floating point number (usually).

[Zaei]

Yupper.

Z.

[parksie]

Originally posted by jim mcnamara
Parksie -
don't you try to inline, jam, etc, your core code? ie., optimize the living doo-doo out of your code? Especially the core code - primitives? We clock() on everything because the stuff gets called hundreds of millions of times a day. Literally. 5% gets you five minutes.

Yeah, I do. We have to do about 100 calculations per finite element, of which some meshes have a few hundred thousand.

I did some *really* horrible-looking parser code a few days ago, but it sped it up from 6 hours to about 40 seconds.

There's nothing wrong with optimising. Just don't do it too early. Get it working first!