|
|
1- Write a class Counter include a method preincrement() that increments a
private variable count and a method predecrement() that decrements a data member count but only using prefix notation. Using inheritance, add the ability to use postfix notation for both incrementing and decrementing. In the main method call all the methods from the object of child class
modified 6-May-17 17:57pm.
|
|
|
|
|
First you do some research into prefix notation, what a weird concept!
The you start writing the code for the classes required to meet your homework requirement.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Do you know what prefix notation is? Do you know what postfix notation is? Do you know what inheritance is? Combine these to get your answer.
This space for rent
|
|
|
|
|
gentle reader: please recall this forum is also intended to be a C# language discussion forum. Yes, it may have evolved into a kind of parallel QA forum, but, I hope it is still a place for some exchanges around language features, and issues.
I'd guess most of us have noticed at some time there's no lexical qualifier for Types 'short or 'byte, like there are for 'long, 'double, etc. ... and wondered why ... even looked for a "why" ... perhaps come across Eric Lippert's standard why-no-feature rationale: "... because no one ever designed, implemented, tested and shipped that feature. More specifically: why should there be?"
Big-deal: you gotta cast, or specify Type, and these are compile-time operations:
var brain = (short) 3;
short damage = 222; However, today, while exploring 'BitVector32, I came across this:
> ? ((short)1) << 2
4
> ? ((short)1) << 2 is short
false
> ? ((short)1) << 2 is int
true
> ? ((long)1) << 2
4
> ? ((long)1) << 2 is long
true
> ? ((long)1) << 2 is int
false
> ? ((uint)1) << 2
4
> ? ((uint)1) << 2 is uint
true
> ? ((uint)1) << 2 is int
false
> I conclude bit-shifts cast a 'short to an 'int": ergo they are not short-shifted. Of course, I would never dare think the language designers were short-sighted !
fyi: the largest possible 'BitVector32.Section size is 0x7FFF (15 bits).
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
|
|
|
|
|
Quote: I conclude bit-shifts cast a 'short to an 'int"
What does this (I'm not very firm in C# and can't test it here):
? ((short)1) << ((short)2) is short When this is true it might not be the bit-shift but the common rule that the largest operand type defines the result type.
Or are short operations always executed as int and converted to short afterwards when requested?
|
|
|
|
|
There is an implicit conversion going on in your shift code. To achieve a short result, you would have to do the following:
(short)(1 << 2) To test which part of the operation is causing the conversion, you can use the following
((short)1) << ((short)2) is short; This will return false, telling us that the << operator is returning the int.
This space for rent
|
|
|
|
|
I conclude bit-shifts cast a 'short to an 'int"
That is true. It also applies to all other arithmetic and bitwise operators. It happens because there are no pre-defined operators for them, for example the list of pre-defined left shift operators is, according to ECMA 364:
Quote: int operator <<(int x, int count);
uint operator <<(uint x, int count);
long operator <<(long x, int count);
ulong operator <<(ulong x, int count);
(note also that all shift counts are int)
Since an implicit conversion exists from short to int, you can still write someShort << k and it will pick the first overload and insert an implicit conversion.
As for why, I suspect this is a case of "because C does it and there was not enough reason to change it". Personally I don't like it, I would have preferred the extra overloads to exist, I find that most of the time when I work with a narrow type it is either widened immediately upon loading it (which without this implicit conversion could still use the implicit conversion that happens when assigning it to a temporary variable) or it has to stay narrow forever (which would become a lot less messy by changing it from C-style to "all the overloads").
A commonly cited non-reason is that, supposedly, "processors are optimized for their word size". But they aren't really, and "word size" is a badly defined can of worms to begin with. Even for "problematic cases" such as 16bit arithmetic on x86, x64, MIPS and a bunch of others, it would be completely trivial for the compiler to do the math in 32bit as much as possible and only insert the bare minimum of operations required to keep the range down to 16bits. Most operations don't propagate information from the msb down to the lsb, so you can work with "crap in the higher bits" without it affecting anything until one of the exceptions to the rule is encountered (division, right shift, comparison, function call).
As a bonus for "future work", keeping calculations narrow would make it easier to auto-vectorize effectively. The amount of parallelism is SIMDwidth / elementsize so the element size should be as small as possible. Not that the .NET JIT compiler does much auto-vectorization, but it could, and with the auto-widening semantics as they are it takes extra analysis to narrow everything back down again and keep the parallelism up. Even ahead-of-time compilers are still pretty bad at that, often taking the simple route of vectorizing the code extremely literally, including all useless widening and subsequent narrowing.
modified 5-May-17 9:16am.
|
|
|
|
|
Thanks, Harold; that's just the type of informative response I was hoping for !
It intrigues me why the BitVector32.Section designers made the c'tor size parameter a signed short, limiting you to 0x7FFF: there is no barrier to using the entire 32 bits; for example:
BitVector32.Section s0 = BitVector32.CreateSection(0xFF);
BitVector32.Section s1 = BitVector32. CreateSection(0xFF, s0);
BitVector32.Section s2 = BitVector32.CreateSection(0xFF, s1);
BitVector32.Section s3 = BitVector32.CreateSection(0xFF, s2);
BitVector32 BvValue = new BitVector32();
BvValue[s0] = 0xFFFF;
BvValue[s1] = 0xFFFF;
BvValue[s2] = 0xFFFF;
BvValue[s3] = 0xFFFF;
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
|
|
|
|
|
Well, I don't know that one. It does make the Section type a nicely round 4 bytes instead of something slightly bigger that would be padded to 8.. that doesn't sound like sufficient motivation but it's the only thing I can think of.
Frankly I find most of the design of BitVector32 strange and generally more painful than manipulating bits manually, it seems to me more like an attempt to make bitfields "more objecty" than a legitimately useful tool, but I'm biased because I work with bits so much.
|
|
|
|
|
I share (I think) a sense of BitVector32 being a kind of strange creature: not close enough to the metal to be suitable for hard-core bit-twiddling; not high-level enough to carry with it state information: if I send you a BitVector32 value you can know nothing about whether it uses masks or sections, etc.
I wrote an extended 'BitVector32 a while ago (as a Class), but realizes I was duplicating what you can do with [Flags] Enums more easily/
cheers, Bill
«When I consider my brief span of life, swallowed up in an eternity before and after, the little space I fill, and even can see, engulfed in the infinite immensity of spaces of which I am ignorant, and which know me not, I am frightened, and am astonished at being here rather than there; for there is no reason why here rather than there, now rather than then.» Blaise Pascal
|
|
|
|
|
|
|
So where do you stuck on this?
modified 20-Sep-20 21:01pm.
|
|
|
|
|
Hello,
I have several data collecting points, each connected to different equipment type; i.e. WorkStation A with DataCollector type DC2, WS B with DC3, WS C with DC2 etc... Each data collector having different protocols.
It is my intention to write a DLL for each DC type with a getData() function in a uniform way, and thus encapsulate communication details for each type.
The idea is to have a config file with the local DC type for each station and link the proper DLL at runtime.
Is that possible?
Thank you,
modified 2-May-17 7:41am.
|
|
|
|
|
icristut wrote: Is that possible?
Yes.
|
|
|
|
|
Well... thank you, I guess...
Should I post another one with "How" ??
|
|
|
|
|
Well your question is not very clear. If you know how to create the DLL, and you know how your applications can access the config data, and you know how to load a DLL at runtime ... then it should be quite simple. But maybe you have an actual programming question.
|
|
|
|
|
I don't know how to link to a specific DLL at runtime. Thank you.
I actually didn't know WHAT to google 
|
|
|
|
|
icristut wrote: WHAT to google
C# plugin frameworks.
This space for rent
|
|
|
|
|
|
I take it you know about interfaces, writing code to implement them, and how plugin frameworks work, correct?
|
|
|
|
|
|
|
Hi Dev,
I am using your form designer, it's too good for me. I just want to know about Form Designer is that,
how can i develop the same with your demo source. I need the complete source, how can i get the same. Please suggest.
Thanks
Mangesh Sachane.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
