3,559 reputation
514
bio website
location Illinois
age 45
visits member for 2 years, 10 months
seen 10 hours ago

May
8
comment c# naming - What are common conventions for a suffix to distinguish between read-only and writable interfaces
I would suggest "Readable" is a much better term than "ReadOnly", and would suggest that the contract for an interface IReadOnlyFoo should specify that code with a reference to an implementing object should be able to pass that reference directly to outside code safely without that outside code being able to modify the underlying object. Although MS failed to make such a distinction, I would posit that ReadOnlyCollection<T> should implement both IReadableList<T> and IReadOnlyList<T>, while List<T> should implement only the former.
May
8
answered What's the idea behind naming classes with “Info” suffix, for example: “SomeClass” and “SomeClassInfo”?
May
8
comment Can I commerically use GPL licensed software on my server if I am only distributing the client software?
Would it be reasonable to base the distinction on the extent to which the interfacing between the programs was public? If e.g. I implement a chess-playing system which uses a GPL user interface program that communicates with a proprietary chess engine, and I document how anyone else wishing to write their own chess engine could make it use that same UI front-end, I would think that should satisfy the spirit (and hopefully the letter) of GPL even though, unless someone happened to write an alternative engine, the UI front end would have no purpose other than to talk to the proprietary program.
May
7
answered Why is .compareTo() in an interface while .equals() is in a class in Java?
May
7
comment Why is .compareTo() in an interface while .equals() is in a class in Java?
@qbd: For any pair of object references X and Y, the question "Do X and Y identify equivalent objects" does not become meaningless if X and Y identify objects of unrelated types. Instead, the answer to the question is simply "no". I do think Java erred in only having one means of asking about one equivalence relation when most applications need two, and in not having a means of telling collections how equivalence of encapsulated items relates to their own equivalence, but equivalence is an important concept that should be fundamental to a framework.
May
6
comment What is the etymology of the phrase “Source Code”?
Was there any term used to distinguish human-readable representations of machine instructions from their machine-processed representations prior to the advent of "automatic programming" [compilation]?
May
6
revised Why were Java collections implemented with “optional methods” in the interface?
added 22 characters in body
May
5
comment When it makes sense to implement C# explicit operator?
IMHO, the explicit conversion operator is appropriate in the particular situation where the operation will either throw an exception or yield something that can be cast back to the original type to yield the original value. Given double d;, the expression (Int32)x should IMHO have been defined to convert d to an integer when it's a finite value with a fractional part of zero, and throw an exception otherwise; other kinds of integer conversion should have used methods RoundToInt32, FloorToInt32, or TruncToInt32, [and likewise for Int64].
May
5
answered Is my usage of explicit casting operator reasonable or a bad hack?
May
4
answered Are header files actually good?
May
4
answered Why Java does not allow function definitions to be present outside of the class?
May
4
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@DavidHammen: I've read the standard; by my reading, when USHORT_MAX < INT_MAX, x*=x; is required to be interpreted as x=(unsigned short)((int)x*(int)x);, the latter subexpression ((int)x*(int)x); will trigger Undefined Behavior if the product won't fit in int, and such Undefined Behavior completely exempts the compiler from meeting any other requirements. Can you point me to anything in the standard that would forbid a 100%-compliant compiler from regarding the expression as invoking Undefined Behavior and using that to justify whatever it wants?
May
4
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@DavidHammen: The problem is that if unsigned short gets promoted to int and the result is cast back to unsigned short, the standard presently only mandates modular arithmetic if no computed value exceeds the range of int. On a system with 32-bit int and 16-bit unsigned short, the above calculation would multiply 65533 (0xFFFD) by 65533; because the arithmetic product 4294574089 (or 0xFFFA0009) is not representable as an int, the standard presently allows compilers to evaluate it however they want.
May
4
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
...it should not be difficult for the optimizer to exempt such instructions from inferences; although compilers prone to making such inferences often have an option to make all integer calculations wrap, that would be akin to hitting a fly with a sledge-hammer. Making all integers wrap would prevent the compiler from making useful inferences like x+1>x for any int x. By contrast, the only "inferences" blocked by extending defined behavior to coerced small unsigned types would be ones that would have little practical use anyway.
May
4
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
...where exempting values of x in the 46341..65535 range would make things any cheaper. All that would be required to extend the range would be for a compiler to (1a) not bother performing needless computations on upper bits which are going to get lopped off, or (1b) silently perform such calculations in a way consistent with two's-complement math; and (2) not use such expressions as a basis for inferences about the value of x. Since the analysis necessary to recognize expressions of the indicated form is a tiny subset of that required for fancy inferences...
May
4
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@DavidHammen: The C Standards Committee has generally been philosophically opposed to mandating any behavior which would be contrary to any behavior defined by an existing compiler. In all cases where the behavior is defined by the standard, expressions of the indicated form would behave as though they were performed using modular arithmetic in the destination base; further, while I'm certainly aware of cases where it would be cheaper to only require x*=x to be evaluated mod 65536 when x is in the 0..255 range, I know of no practical cases...
May
4
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@DavidHammen: The main question is whether compilers have ever defined a particular behavior other than modular arithmetic. If a particular compiler's documentation specified that such an expression would yield 42, then code written for that compiler would be entitled to expect it to yield 42, and any C language specification which would require that compiler to yield 9 instead would break what had been a well-defined (though not strictly-conforming) program. Are you aware of any compilers that defined such behavior?
May
1
comment Has any language become greatly popular for something other than its intended purpose?
@JonPurdy: I think "cross-platform" has changed meaning; the idea wasn't so much that one could write programs that would run usably on different platforms, but rather to allow a means of providing multiple programs with compilable languages.
May
1
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: I suppose code could read files entirely using getc() which returns a byte in each int, and thus avoid ever doing anything with char, but that's hardly a recipe for performance. From what I can tell, a nicer solution that would allow more efficient code and save countless programmers a lot of time would be to change the spec to eliminate Undefined Behavior in this particular situation; I'm not 100% sure that change would be compatible with all existing code, though.
May
1
comment Have any C compilers ever *defined* `unsigned short x=-3; x*=x;` to yield anything other than 9
@RobertHarvey: The C standard has never defined any practical means by which code can use small unsigned types without integer promotion, since even in those cases where integer promotion would be totally useless it was harmless, and there has been no need to prevent it. The only problem is a situation where integer promotion would have no effect on any standard-defined behavior, but causes a behavior that would have been fully defined in the absence of promotion to be exempted from the C specification.