563 reputation
313
bio website tchatzigiannakis.github.io
location Athens, Greece
age 24
visits member for 2 years
seen yesterday

Who I am

  • Undergraduate in Electrical and Computer Engineering.
  • Member of the IEEE and the IEEE Computer Society (formerly member of the IEEE Communications Society).
  • Hobbyist programmer since the age of 10.

What I use

  • I currently prefer to develop in C# and Java.
  • I use C, x86 ASM and JavaScript situationally.
  • I've also used C++, VB.NET, Ruby, Python, PHP, Prolog, UnrealScript and Vala at one point or another.

Jan
9
comment Explain MVC to non-programmers
If I had to describe it in simplified terms, I would describe it as an architecture pattern that focuses on separation of concerns - this, in turn, allows frontend developers to focus on the frontend, backend developers to focus on the backend and database developers to focus on the database, without bothering each other as much as they would in a differently structured system.
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
@delnan It's true I'm mostly interested in languages that abstract away the storage details, but please feel free to include anything you think is relevant, even if it's not applicable in those languages.
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
Boxing is a mechanism to make structs look like they inherit from object, but it's not a perfect abstraction (it leaks into the language) as structs are missing at least one property of their root type. Otherwise, I agree with you - I'd hate to see a type inherit from something like int.
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
Structs (which are value types) can be assigned to object (which is a reference type) in C#, but only because boxing happens implicitly (a new, boxed instance is generated and a reference to it is taken). The memory layout of an object can be quite different from that of an unboxed struct. This makes the boxed struct a possible Liskov subtype of object, but not the unboxed struct. A direct consequence of this is that variance explicitly doesn't work with structs (you get a compiler error), only reference types.
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
When talking about escape analysis, I also meant allocating to automatic storage (it doesn't solve everything, but as you say, it solves some things). I also admit I had underestimated the extent to which fields and aliasing could make escape analysis fail more often. Cache misses are the thing I was most concerned about when talking about spatial efficiency, so thanks for addressing that.
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
@Telastyn I can see your point, then (although I've found some uses occasionally). By the way, I was also implementing a toy language when I came up with this question. Your answer is useful to me already, but can you include some further practical caveats that you met, if any? Also, can you clarify the paragraph about dispatching to/from a CPU instruction?
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
@Telastyn I see your point about the overhead of an additional method call. But I don't think that inlining a call to a function of the base class library is unheard of, or unfeasible (considering that when an instance is created at a local scope or is provided through a variable of a final/sealed type, we can ignore polymorphism and statically link the called functions, even if they are virtual). Also, IMHO variance is useful, even between two types (is the relationship between object and string useless?), plus I'm not necessarily saying that int will inherit dierctly from object
Jan
1
comment What are the caveats of implementing fundamental types (like int) as classes?
int + int can be a regular language-level operator that invokes an intrinsic instruction that's guaranteed to compile to (or behave as) the native CPU integer addition op. The benefit of int inheriting from object isn't only the possibility of inheriting another type from int, but also the possibility of an int behaving as an object without boxing. Consider C# generics: you can have covariance and contravariance, but they are only applicable to class types - struct types are automatically excluded, because they can only become object through (implicit, compiler-generated) boxing.
Dec
24
comment How did OOP evolve to include the notion of Properties
Good answer, it explains the exact practical reasons that led to the introduction of properties as a language-level construct.
Dec
19
comment Is it good practice to inherit from generic types?
I probably misunderstood, then.
Dec
17
comment Is it good practice to inherit from generic types?
Extension methods apply anyway.
Dec
17
comment Is it good practice to inherit from generic types?
@Mawg They can be available only for instantiation.
Dec
17
comment Is it good practice to inherit from generic types?
+1. As has been pointed out, this is not quite the same as typedef, but it still is very useful in some scenarios, because it helps the reader distinguish between pieces of data that are of the same type but shouldn't be mixed and pieces of data that are of the same type and should be mixed.
Dec
11
comment Is there ever a reason to use an array when lists are available?
I'll take your word for it, although I don't understand exactly how simple explicit boundary checks can add up quite as much. At least it's good to know that there is an observable difference, it makes it easier to choose one or the other (in scenarios where they would otherwise seem interchangeable). Cheers!
Dec
10
comment Is there ever a reason to use an array when lists are available?
What you're saying is correct, but it assumes that either we don't know the element count beforehand (in which case, arrays aren't useful anyway) or that we do know the element count beforehand but we deliberately don't use it in the case of the list. If we do use the element count to initialize the list with the desired capacity, we get only one array allocation (until you reach that capacity), thus we pay the same performance costs. All other common operations are equal (search, retrieval by index, assignment by index), except for further adds (which arrays don't have at all).
Dec
10
comment Is there ever a reason to use an array when lists are available?
How is an array "faster" than a list, considering that List<T> is implemented using an array? If you know the element count beforehand (which you have to know, when using an array), you can use that knowledge when initializing the list as well.
Dec
3
comment Which are the cases when 'uint' and 'short' datatypes are a better fit than the standard int(32)?
The short answer, I think, is that programmers have gotten used to the signed semantics and are inclined to assume those, even when dealing with unsigned types (and thus unsigned semantics). Most people assume it's a matter of the programmer being lazy or uneducated, but the programmer in question may in fact be very educated and very careful and wants to avoid subtle pitfalls. If you like, take a look at soundsoftware.ac.uk/c-pitfall-unsigned and anteru.net/2010/05/17/736.
Oct
16
comment In a generic method, what exception should I throw when a type parameter is unacceptable?
@RobertHarvey Yes, this is exactly what I was looking for, thank you! Care to make it a (summarized) answer?
Oct
16
comment In a generic method, what exception should I throw when a type parameter is unacceptable?
@RobertHarvey Yes, I understand that. In my method, any object is acceptable as an argument (so no problem there), but only specific types are acceptable for the type parameter T (specifically, public interfaces - neither of which can be expressed in the constraint). So I'd like to know if there is perhaps another kind of exception that I should be throwing in this case. (Resharper's complaint isn't my main concern - maybe I should remove that note.)
Oct
16
comment In a generic method, what exception should I throw when a type parameter is unacceptable?
@RobertHarvey "Cannot resolve symbol T", where T is the type parameter.