|
mtn*rain wrote: Transaction does not contain a constructor that takes 7 arguments
I suggest you take compiler messages quite literally.
Your Item and Transaction classes don't have explicit constructors (well, you haven't shown any); so all they have is an implicit or default constructor that takes NO arguments.
Furthermore, your 7 parameters suggest they describe a new Item, not a new Transaction. Rethink your structure, add constructors, and check your code carefully.
If you're new to C# (and to object orientation?) you might want and consider something simpler to start with.
|
|
|
|
|
I am entering a new item to test with for NUnit. I am new to this and this is a project required for school, so I cannot do something simpler.
Do you know if I have already listed a constructor in another class that I might use or do I need to completely redo this entire thing?
|
|
|
|
|
How many constructors did you show so far? Have you any idea what a constructor is? Did you pay any attention in class, assuming you were present?
|
|
|
|
|
I don't go to class, I go online. So, yeah, I paid attention to the slides that were sent to me from my professor. I have read several books, done several searches and yes, I am a little lost on exactly how it all works and the answers from my professor are at least better than yours but they are vague.
Thought I could get help here but I guess I will go somewhere else where they realize that not everyone has been doing this for any length of time.
|
|
|
|
|
And you got to learn to walk before you run (dontcha' know)
|
|
|
|
|
Been walking for a while. I know mainframe coding, not much in the way of oop. I understand that what I have coded is incorrect, but I am not sure how and was looking for help in figuring out how to pull from an array in a different class. I would appreciate it if you would hold your comments and hopefully someone else can actually provide what this forum says it will provide.
|
|
|
|
|
1) You don't have any constructors, so the only constructor that exists is the default constructor, which accepts 0 parameters. You are trying to use a constructor with 7 parameters, which doesn't exist.
2) The first constructor you call with the last parameter of type bool, and the second time you call it the parameter is of type string. While it is possible to overload constructors, I doubt this is what you want.
3) You are constructing new instances of type Transaction, though class Item is the one with 7 properties that need to be initialized. I wonder if, perhaps, this is another mistake.
4) You say you are working with an array, yet I don't see any arrays... all I see is a list stored as an IList.
5) As Luc said, it helps to interpret the exceptions, which I'm sure will come more naturally as you work with them more. An excellent source of information is Google (e.g., try Googling for "C# constructor").
6) Inside...
7) Joke.
|
|
|
|
|
Thanks for your reply. I am used to working with Arrays, while it was the List I was talking about. I have done searches looking for some type of examples that have similar lists as what I am using, I am just getting confused with all the different classes and how to access different classes in another class, along with using NUnit.
I will keep looking and probably redo everything I have to see if I can come up with something that does work.
|
|
|
|
|
Do yourself a favour and follow Luc's advice: Buy or borrow a book which takes you into basics of object orientation and C#. This 'trial and error' method does not make much sense.
|
|
|
|
|
Hi all,
I'm working with a machine vision package which uses a proprietary internal image format. Their package will convert to many common formats (jpg/bmp/png/etc) but this conversion is only done to disk and I want to do an in-memory conversion because the to-disk conversion is just plain too slow (>200ms).
Their format for 8bit color images is 3 separate planes (R,G&B) which easily combine into a 24bpp BitMap like this:
private static unsafe void CopyColorPlanes( BitmapData bmp, IntPtr _b, IntPtr _g, IntPtr _r )
{
byte* imgPtr = (byte*)bmp.Scan0;
int h = bmp.Height;
int w = bmp.Width;
int s = bmp.Stride;
byte* b = (byte*)_b;
byte* g = (byte*)_g;
byte* r = (byte*)_r;
for ( int row = 0; row < h; row++ ) {
for ( int col = 0; col < w; col++ ) {
*imgPtr++ = *b++;
*imgPtr++ = *g++;
*imgPtr++ = *r++;
}
imgPtr += ( ( s / 3 ) - w ) * 3;
}
}
This works well and is "reasonably" fast - a 1600x1200 color image conversion takes roughly 42ms on a 1.8MHz VIA C7 (the target system).
Two questions:
1) Does anyone see anything in the above method that could be tweaked (staying within "pure" C#) to make it faster? (I've already tried partitioning the source planes into halves and quarters to make them fit better in the CPU cache and while this has a small impact it's not significant and interestingly, doing columns in the outer loop runs about 10% faster on an AMD DualCore 4200 - go figger).
2) Is there some native Windows API that will do this job?
I know I probably end up crafting this in assembly but I view that as a last resort... and deadlines loom...
Subvert The Dominant Paradigm
|
|
|
|
|
Give the compiler a clue and precalculate the alignment adjustment - it may or may not optimise it out of the loop.
It would be worth experimenting with a 32bpp bitmap (ARGB) instead of a 24 (RGB) - that way you can assemble it in an Int32 and save only once - depending on your cache etc it may be faster to do one 32 bit write than three 8 bit ones.
Rather than assembler, I would go to native C/C++ code first. That will probably be fast enough and a lot more maintainable.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Ahhhh... assemble into a single uint and then store. I'll try that.
Thanks.
Subvert The Dominant Paradigm
|
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: About as fast as C# will get. C++ is must faster.
Ther's nothing like horsepower to cover lazy programmers.
For giggles I tried this:
Parallel.For( 0, bmp.Height, row => {
byte* b = (byte*)_b + ( row * bmp.Width );
byte* g = (byte*)_g + ( row * bmp.Width );
byte* r = (byte*)_r + ( row * bmp.Width );
byte* dst = row <= 0 ? (byte*)bmp.Scan0 : (byte*)bmp.Scan0 + ( ( bmp.Width * 3 ) * row ) + ( ( bmp.Stride / 3 ) - bmp.Width ) * 3;
for ( int col = 0; col < bmp.Width; col++ ) {
*dst++ = *b++;
*dst++ = *g++;
*dst++ = *r++;
}
} );
On my dual I9 it's pretty fast (well, reallllyyyy fast). Unfortunately that's not the production target.
Subvert The Dominant Paradigm
|
|
|
|
|
jkohler wrote: Unfortunately that's not the production target.
What are you targeting, Core2?
|
|
|
|
|
VIA C7 @ 1.8 MHz
It does pretty well until images get large and they no longer fit in the onboard caches....
Subvert The Dominant Paradigm
|
|
|
|
|
I don't know much about the architecture they use..
|
|
|
|
|
One of the other replies suggested using a 32 bit destination - which means you've probably changed the 'next destination pixel' calculation - but if you're still working with 24 bit destination pixels, moving the ( ( s / 3 ) - w ) * 3 expression outside the loops may make a difference (although, the C# compiler may have already done this in an optimization step). Division is timeconsuming - and this whole expression is constant for all loop iterations.
|
|
|
|
|
I just tried the 32bpp image format which on my development system gives a ~5% improvement. Unfortunately, on the target system (VIA C7) it makes little measurable difference. I expect any gain in execution speed is consumed in the increase in bitmap size (adding an additional byte per pixel to a 1600x1200 image is a significant increase in terms of CPU cache, etc.).
Moving the loop invariant outside the loop does indeed make a small difference when running in the debugger but release code? No difference at all. And interstingly the 32bpp format does not require that little calculation to be done at all.
In case you're interested, the 32bpp image version:
private static unsafe void CopyColorPlanes32( BitmapData bmp, IntPtr _b, IntPtr _g, IntPtr _r )
{
int* imgPtr = (int*)bmp.Scan0;
const int h = bmp.Height;
const int w = bmp.Width;
const int alphaValue = 0xff << 24;
byte* b = (byte*)_b;
byte* g = (byte*)_g;
byte* r = (byte*)_r;
for ( int row = 0; row < h; row++ )
for ( int col = 0; col < w; col++ )
*imgPtr++ = alphaValue | *b++ | ( *g++ << 8 ) | ( *r++ << 16 );
}
Subvert The Dominant Paradigm
|
|
|
|
|
Although it propably won't give you much, you could try to optimize your for-loop in the following ways:
- Instead of having nesting the 2 for-loops - you could try to have just one
- Counting backwards
- Use != instead of <
- Use ++n instead of ++n
for( int n=(h*w)-1; n!=-1; --n)
for( int n=h*w; n!=0; --n)
Although the compiler/JIT should already have done some the above optimizations, I have seen measurable improvements doing the above in certain areas.
/Michael
Edit: Modified the for-loop as you aren't using the 'n' for indexing.
Need a 0 false positive SPAM filter? Try the free, industry leading spam filters from SPAMfighter
|
|
|
|
|
Michael B. Hansen wrote: Although the compiler/JIT should already have done some the above optimizations, I have seen measurable improvements doing the above in certain areas.
As Have I...
And although it is ugly, you may want to look @ the target environment architecture and optimize the loop (unroll manually) to make a write equal to the available size of register, this should boost speed a Lot.!
-I have a related post.. not to toot my own horn... but TOOT. 
I'd blame it on the Brain farts.. But let's be honest, it really is more like a Methane factory between my ears some days then it is anything else...
-"The conversations he was having with himself were becoming ominous."-.. On the radio...
|
|
|
|
|
Have you thought of declaring a union of a int and four chars for imgPtr and allowing the compiler to effectively decided how to do the bit shifts when you assign r g and b ? Also decrementing loops are faster since they simply require a compare with 0 and loop instruction rather than loading two values comparing and then looping.
|
|
|
|
|
A union.... Apparently I've forgotten the basics.
Thanks for the reminder - even if it doesn't shave any cycles it'll definitley have a higher cool factor.
As to reversing the loop - your point is taken and appreciated.
Subvert The Dominant Paradigm
|
|
|
|
|
Write the loop as suggested by Michael. The processor might even have its own instructions for copying a byte from one register into a different byte in another (or even combining multiple byte copies into a single instruction). Look at the assembler for the bit shift and or solution and the union and see which is more efficient. I'm interested to hear how much faster it becomes.
|
|
|
|
|
It isn't a division. It's a constant division by k, which any sane compiler (even the .NET JIT compiler, though its sanity is debatable) turns into a multiplication with approximately 0x100000000 / k (and possibly a few extra instructions for correct signed rounding) or some other constant, depending on the data size.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
