Reputation
3,699
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
5 14
Newest
 Nice Answer
Impact
~260k people reached

  • 0 posts edited
  • 0 helpful flags
  • 165 votes cast
Jun
1
comment Is byte stuffing required when using a packet field length
The other situation where byte stuffing is useful is when sending data over an unreliable medium. Use of length-prefixed data with no escapes or byte stuffing is fine if every byte of data will get sent reliably, but loss of a byte may render everything afterward unintelligible. Use of byte stuffing and escapes will make it possible to resynchronize parsing following some corrupted data.
May
29
comment Why are cryptic short identifiers still so common in low-level programming?
...look at the MCU manual to find out how the prescalar interacts with other parts of the timer; given TMR4->PSREG=12; one manual suffices for everything.
May
29
comment Why are cryptic short identifiers still so common in low-level programming?
@detly: The CCS compiler had such methods, and some other processors do to. I generally dislike them. The register spec is sufficient to write code that uses the registers and it's sufficient to let someone reading code that uses registers to see what those registers do. If the act of writing a value of N to a hardware prescalar sets the period to N+1 (quite common), the proper meaning of set_prescalar(TMR4,13); is IMHO a lot less clear than would be TMR4->PSREG=12;. Even if one looks at the compiler manual to find out what the first code does, one will likely still have to...
May
29
answered What's the proper way to model this real-world activity that seems to need circular references in OOP?
May
27
comment Should I build a multi-threaded system that handles events from a game and sorts them, independently, into different threads based on priority?
@MichaelBorgwardt: If one places all the objects in the world on top of each other that could dog performance, but in a lot of games such situations can be classified as "ain't gonna happen". Further, I would posit that while it may be possible to resolve collisions among small cliques in such a fashion that objects don't overlap at all, if cliques can get very large I think it's better to accept and handle the possibility of overlap that could occur if object states at each timestep are calculated based solely on object states from the previous timestep.
May
27
comment Should I build a multi-threaded system that handles events from a game and sorts them, independently, into different threads based on priority?
@MichaelBorgwardt: My point is that the old state should be kept until everything has been resolved. The only calculations that should use the new state of an object are those which involve other objects colliding with it; adding another object to the clique of colliding objects would require that all calculations associated with that clique be redone from scratch, but that should represent a small portion of the total workload.
May
27
comment Is there any “real” reason multiple inheritance is hated?
@cHao: There are advantages to having a "reference to anything" type to which any reference may be cast in identity-preserving fashion. I think COM "solved" the problem by limiting its "inheritance" to the .NET interface pattern: don't allow a type to expose fields and require all methods be re-implemented by any implementing class. Does COM offer some other form of inheritance (multi- or otherwise) I don't know about?
May
27
comment Automatic Type Promotion in JAVA
...items of any integer type to/from an integer array. Within the JVM there is no difference among any of the shorter-than-int types except that before storing a value to a variable of such a type the JVM adds instruction to sign-extend the lower portion of a word into the upper portion. From a language perspective, the only ability one would lose if all variables of type byte were replaced with int would be the ability to store a byte variable directly into a byte[] array slot without a typecast--an ability that could be added via storeByte method.
May
27
comment Automatic Type Promotion in JAVA
Basically, I think the creators of Java decided that it would be useful require cluttering code with typecasts when storing into byte variables anything other than the contents of other byte variables, but when they discovered that the arithmetic promotion rules would render the compound operators useless with such variables, they dropped the restriction in that case so as to make such variables useful. Personally, I think Java would have been simpler and better if they had left out byte, short, and maybe char as types, but included native methods to fetch and store...
May
27
comment Should I build a multi-threaded system that handles events from a game and sorts them, independently, into different threads based on priority?
...by the second step? If every calculation starts by generating new object states based upon old object states and when two or more things collide, generates all their new states based upon all their old states, I would think it should be possible to get good performance with minimal interlocking.
May
27
comment Should I build a multi-threaded system that handles events from a game and sorts them, independently, into different threads based on priority?
In a typical game, it would seem like many objects aren't going to interact with each other; would you see any problem with dividing the game world into boxes, and then processing in parallel everything that stays entirely within a box, then switching to a different layout of boxes and processing everything that straddled boxes in the old layout but not the new, using the old states of objects as input to the calculation and invalidating the new states of objects that get unexpectedly disturbed, and then finally using one thread to clean up everything that was missed or invalidated...
May
27
comment What is the accepted best practice for Java type conversions?
@MichaelBorgwardt: I don't think closures are the solution here--the right solution would be for Java to offer native methods to do things like copy numeric values between arrays of different types, copy data between arrays of different size integer types as though bitwise copied on big-endian or little-endian architectures (on a big-endian machine, the big-endian method could use a straight block copy; likewise the little-endian method on a little-endian machine), copy every Ith element within a range of one array to every Jth element of another, etc.
May
27
comment Why can't there be any implicit conversions?
@funkwurm: I would suggest that what is fundamentally dangerous is combining implicit conversions with overloaded operators whose semantics vary with type. In systems with a "universal" numeric type, saying that "+" always converts its operands to that type and adds them, while & always concatenates the string representations of its operands, the meanings of "12"+"3" and 4 & 56 would not be problematic (they'd be 15 and "456", respectively); the system would have to document whether "12,345" meant 1.2345E+05, 1.2345E+01, 12.0E1, or NaN, but the meaning of "+" wouldn't change.
May
27
comment Is there any “real” reason multiple inheritance is hated?
@cHao: If Moo:Zoo casts this to Object, should the result be the same as if Goo:Zoo does so, or if a Foo is cast directly? I don't think C++ would allow a direct cast from Foo to a multiply-inherited base type, but identity-preserving upcasts and downcasts are an essential and useful feature of Java and .NET.
May
26
comment Why can't there be any implicit conversions?
...implement neither equivalence relations nor ranking, and Python doesn't provide any convenient operators which do.
May
26
comment Why can't there be any implicit conversions?
IMHO, a good language/framework should often have multiple ways of doing things which handle common corner cases differently (better to handle a common corner case once in a language or framework than 1000 times in 1000 programs); the fact that two operators do the same thing most of the time should not be considered a bad thing, if when their behaviors differ there would be benefits to each variation. It should not be difficult to compare two numeric variables x and y in such a way as to yield an equivalence relation or ranking, but IIRC Python's comparison operators...
May
26
answered The need for Explicit Type Conversion in C#
May
26
comment Is there any “real” reason multiple inheritance is hated?
...that would be very different semantics from a ((typeName)anythingElse) cast.
May
26
comment Is there any “real” reason multiple inheritance is hated?
@cHao: In an MI language, if Foo derives from Moo and Goo, each of which overrides a common inherited method Zoo in its own way, unless one inherited class is designated "primary", I'm not sure what base.Zoo could mean. Having a means for the derived class to invoke Moo's override of Zoo or Goo's override of Zoo would be fine, and one could define a syntax ((typeName)base).member which was only valid when typeName was either the type of the enclosing class or an immediate parent thereof, which would bypass any overrides by classes derived from it, but...
May
26
comment Why can't there be any implicit conversions?
...that kind of conversion seems like it would be more appropriately performed via method than via cast (too bad .NET doesn't include efficient round-and-convert functions, and Java's are overloaded in somewhat silly fashion).