|
You're not proposing he should use VB are you?
|
|
|
|
|
jibalt wrote: You've missed the point ... all multibyte char literals are endian-sensitive.
To make it endian-insensitive, it should be
That however ignores the point that the code was written to support a specific protocol over TCP.
If the character set of the protocol changed then that would be just one thing that would likely break.
|
|
|
|
|
No, I did not ignore your irrelevant point.
|
|
|
|
|
jibalt wrote:
No, I did not ignore your irrelevant point.
Your comments are only relevent if the character set changes - and thus the protocol changed.
Thus your comment, in terms of the original question, is irrelevant.
And I seriously doubt it would ever be relevant because it presumes that the protocol is compiler dependent. Even if the protocol did specially use a multi-byte character set which varied by OS then then the correct thing for the protocol to do is send a precursor to determine the ordering. Your code presumes and ordering and ignores the possibility that the other end is running on a different OS.
|
|
|
|
|
Was that meant to be English?
|
|
|
|
|
A wee bit of commmenting would be nice, but other than that I cannot see a problem here.
As for porting to big-endian system: First of all, that will never happen. Secondly, there will be more places to fix if it did happen. Thirdly, the code is platform-restricted anyway (to Windows), so there is not a problem...
|
|
|
|
|
Why is that code platform-restricted to Windows?
I've seen DWORDs on many platforms, so there's really nothing here to suggest that.
|
|
|
|
|
Ah, but it was Windows that started it. Nyah, nyah... 
As for the two other points, they are still valid...
|
|
|
|
|
Tom Delany wrote: event that the code is ever ported to a big-endian system, it would be completely broken.
No it wouldn't.
The code POSTED would work regardless of that.
As mentioned it is a TCP stream so it sequential. The switch statement is using ascii. The only way endianess would matter would be if the stream started to use a different character set. And if it did that it would fail if
1. The character system was not using a 8 bit lower representation of that matched ascii (UTF8 does where UTF16 does not.)
2. AND if the protocol changed.
And certainly if item 2 is true then all sorts of problems could result. Such as the rest of the code, following the switch, failing as well.
|
|
|
|
|
That's how you handle tags in ICC profiles, for example. It's a perfectly reasonable thing to do.
Tom Delany wrote: WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.
Still one of my favorite sigs on CP.
Software Zen: delete this;
|
|
|
|
|
No endian-sensitive code (which includes all multibyte chars) is "perfectly sensible".
|
|
|
|
|
'Sensibility' of a particular approach always depends upon the problem being solved. Making code endian-insensitive is necessary only if you plan on porting it between different endian environments.
Software Zen: delete this;
|
|
|
|
|
|
I suppose he didn't liked If - else- ifs...
|
|
|
|
|
It's sort of both... it'd be properly brilliant if the "verb =" line were commented...
|
|
|
|
|
Tom Delany wrote: This is either brilliant, or just bloody awful.
What is the fourth character of the protocol?
Tom Delany wrote: I'm coming down on the side of "bloody awful":
How would you refactor it?
|
|
|
|
|
In my eyes it is ugly, but one of the easies way to compare strings (up to 8 bytes) in a most efficient way.
If it's needed and documented ... ok.
I recently saw a very strange way to copy an object in C++:
- the class defines all its data member attributes within 64 Byte
- the data member attributes are ordered to use alignment efficently
- copying the class is done this way (or similar)
C64bitClass src, dst;
__int64 *pnSrc = static_cast<__int64*>(&src);
__int64 *pnDst = static_cast<__int64*>(&dst);
*pnDst = *pnSrc;
This really ugly, isn't it!
|
|
|
|
|
if (result != Common.ErrorMsg.ErrorNone)
{
this.Dispatcher.BeginInvoke((ThreadStart)delegate()
{
});
return;
}I found this in code that is guaranteed to be called on the dispatcher's thread. Sigh2.
Software Zen: delete this;
|
|
|
|
|
Someone probably planned on coming back and filling this in someday. 
|
|
|
|
|
That explains why he copy/pasted it all over the place.
Software Zen: delete this;
|
|
|
|
|
I guess he liked spaghetti (code) with a side of Copy-Pasta.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
Procedural Object Oriented Programming (POOP).
|
|
|
|
|
Another guy here has his Special High-Interest Task list.
Software Zen: delete this;
|
|
|
|
|
Given you said it was replicated in multiple places, I can see only one possible perceived value -- to block this function from returning until after the dispatcher thread is finished executing something else. Such behavior isn't guaranteed, but it would work just often enough that I can easily see someone clueless thinking it does. Before totally writing it off, I'd look carefully at what's done with the dispatcher prior to executing this code.
As pointed out, this only makes sense if its run with an Invoke, instead of the BeginInvoke that's being used. Nevermind 
We can program with only 1's, but if all you've got are zeros, you've got nothing.
modified 2-Apr-13 14:09pm.
|
|
|
|
|
It's a BeginInvoke call, which only blocks (very) briefly while the work item is queued to the dispatcher. The dispatcher in turn will execute a brief delay at some point executing the 'empty' work item.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
