|
Hi Saeed,
Could you clarify exactly what you mean by "textbox at top of my document" ?
I note the variable 'y you define in your code is never used.
It appears to me your code deletes the tags "<NE>" and "</NE>," as well as white-space between them: is that correct ?
yours, Bill
string test = "\r";
string afterTest = test.Trim();
MessageBox.Show(string.IsNullOrEmpty(afterTest).ToString());
MessageBox.Show(string.IsNullOrWhiteSpace(afterTest).ToString());
MessageBox.Show((afterTest == string.Empty).ToString());
“Humans are amphibians: half spirit, half animal; as spirits they belong to the eternal world; as animals they inhabit time. While their spirit can be directed to an eternal object, their bodies, passions, and imagination are in continual change, for to be in time, means to change. Their nearest approach to constancy is undulation: repeated return to a level from which they repeatedly fall back, a series of troughs and peaks.” C.S. Lewis
modified 17-May-13 8:52am.
|
|
|
|
|
Hi,
I have a Java program that signed a token using the private key and SHA1 algorithm. Now I try to verify it using the public key and SHA1. The verification fails. Is there any compatibility issue here or I am missing something? Thanks.
Best,
Jun
|
|
|
|
|
Oops wrong forum. Recommend you delete this thread and post your question in the right forum.
|
|
|
|
|
I am programming a bit counter, a method that returns a List < int > of the positions of the bits that are "on" in a UInt32. I was reviewing the code when I encountered
position--;
bit >>= 1;
To my mind these two statements need to be atomic. To achieve at least the notion of atomicity in C#, I would change the code to
position--; bit >>= 1;
I am fiercely against this in a statement body. But in this case I think it signals atomicity. Is there a better way to do this?
Gus Gustafson
|
|
|
|
|
This is coolest bitcount I've seen.
{
c = (c >> 1 & 0x55555555) + (c & 0x55555555);
c = (c >> 2 & 0x33333333) + (c & 0x33333333);
c = (c >> 4 & 0x0f0f0f0f) + (c & 0x0f0f0f0f);
c = (c >> 8 & 0x00ff00ff) + (c & 0x00ff00ff);
return (c >> 16) + (c & 0x0000ffff);
}
|
|
|
|
|
|
Nice. Thanks.
|
|
|
|
|
Is this an answer to my question?
Gus Gustafson
|
|
|
|
|
I'm wondering what you're actually trying to achieve.
Do you just want some style that implies atomicity?
Do you want a way to ensure atomicity?
|
|
|
|
|
I'll take either.
Gus Gustafson
|
|
|
|
|
For a suggestion of a style to imply/suggest atomicity I'd probably use something like:
{
position--;
bit >>= 1;
}
Code reformatters may remove the redundant curly-braces.
I don't know of any way to ensure the two actions are performed atomically.
But, these operations should not be using values that aren't thread-safe anyway.
At least in a bit counting method.
Why the concern for atomicity?
|
|
|
|
|
Thread safty has nothing to do with it. The expressions are in a private static method.
Thanks for the thought.
Gus Gustafson
|
|
|
|
|
OK, but that's what atomicity is. A thread can safely read a value without having to worry about another thread writing to that value at the same time.
Each o of yout two statements is atomic, but together, they are not. The values can change between the execution of those two statements.
The only way to treat those two statements as a single atomic operation is to wrap it in a lock. You'll also have to modify any code that changes these values to also try and take out a lock before changing the value(s).
very as to what you're doing and why...
|
|
|
|
|
Dave, being thread safe is not the same as atomicity. The former deals with threads within a process. The latter deals with processes across the machine. It requires the compiler writer to mask interrupts during the time that "atomic" instruction will be executed.
Thanks for your thoughts.
Gus Gustafson
|
|
|
|
|
I forgot about the system-wide process part, as I never had to deal with it.
But, in any case, the concept of atomicity, the way you describe it, doesn't exist in .NET.
|
|
|
|
|
Thanks for your thoughts though.
Gus Gustafson
|
|
|
|
|
I am not sure what you mean by "atomicity" given your example of what you'd change the code to (putting them on the same like doesn't affect the runtime behavior at all). If you want the operation to by atomic in a thread safety sense, you'd want to use locking, like this:
lock(lockingVariable)
{
position--;
bit >= 1;
}
You will also have to ensure anything else that has access to those variables does a similar lock. In this way, you can ensure that one thread isn't accessing the variables when only one of them has been changed.
gggustafson wrote: I am fiercely against this in a statement body
Why?
gggustafson wrote: But in this case I think it signals atomicity. Is there a better way to do this?
If you are talking about indicating to other programmers who read the code that the operation is intended to be atomic, could you just put in a comment, such as this?:
position--;
bit >>= 1;
If you really want to be explicit, you could do this:
{
position--;
bit >>= 1;
}
Sorry if that seems like a silly suggestion, but I really am not sure I understand your question.
|
|
|
|
|
I appreciate your thoughts.
I am fully aware that the text of a program does not affect its runtime behavior. lock is useful in concurrent processes to insure that critical regions are not simultaneously executed by multiple processes.
The reason that I am fiercely opposed to multiple statements on a line is for the same reason that I expect that edge detection be enforced. In an earlier article, Minimalist Coding Guidelines, I give an example of why:
Block Declaration
1 [ DllImport ( "gdi32.dll", EntryPoint = "BitBlt" ) ]
public static extern bool BitBlt ( IntPtr hdcDest, int nXDest,
int nYDest, int nWidth, int nHeight,
IntPtr hdcSrc, int nXSrc, int nYSrc,
int dwRop );
2 [ DllImport ( "gdi32.dll",
EntryPoint = "BitBlt" ) ]
public static extern bool BitBlt ( IntPtr hdcDest,
int nXDest,
int nYDest,
int nWidth,
int nHeight,
IntPtr hdcSrc,
int nXSrc,
int nYSrc,
int dwRop );
I don't think that there are those who would claim that the style of Block 1 is superior to that of Block 2.
I'm sorry that I do not agree with your commenting style. A comment that relates to a statement should be placed to the right of the statement, not above it. This coding style makes the comment "part of the statement." Thus if the statement is removed or moved, the comment is removed or moved with it.
I do like the idea of creating a body surrounding the statements.
Thanks for your comments.
Gus Gustafson
|
|
|
|
|
You could write a class (or struct) to hold the two values and have a Decrement method that does both operations.
Or maybe something like bit = ( 1 << --position )
|
|
|
|
|
I like your
bit = ( 1 << --position );
I'll use that form, adding a comment as follows
bit = ( 1 << --position );
I fully realize that the statements are not atomic, but I do think that a reader might be guided during maintenance.
Thanks for the idea.
Gus Gustafson
|
|
|
|
|
You stated elsewhere that the expressions are in a private static method.
I still don't see the need for atomicity here.
Maybe if you explained why you require atomicity, we could understand.
On the other hand, we could just trust that you have a reason.
You have no obligation to justify this to us.
But, maybe, we might learn something new...
|
|
|
|
|
Unfortunately, there's no inherent concept of atomicity in C#, and no guarantee that you could handle it reliably. The classic example would be to provide some form of undo functionality which you could record your changes in (somehow), and then call this if your code were to fail somehow. While this, initially, might seem to be a viable idea, it's not quite as clear cut as this would indicate. For instance, how would you capture operations going on internally? What happens if those operations introduce side effects?
|
|
|
|
|
I agree. It's too bad. Obviously we are dealing with forcing a sequence of machine instructions to be executed without interrupt. In my days of assembly programming, I was able to suspend interrupts and then resume them by masking by a global interrupt mask bit.
It's too bad that C# doesn't support this. For example, a form like
atomic
{
:
statements
:
}
would have sufficed.
Thanks for your thoughts.
Gus Gustafson
|
|
|
|
|
A static method should at least be thread-safe.
|
|
|
|
|
The question is not thread safety; it's atomicity. The concepts are different.
Thanks for your comment.
Gus Gustafson
|
|
|
|