I am not a java programmer. By that, I do not mean I am against Java. As a programmer by profession and passion, I try to learn things along the way. That includes a little of bit of Java. I should say that my proper encounter, so to say, with Java is a simple application that I am trying out with Android. There might be some hard core differences and/or limitations in the Android version of Java. But I am almost certain that I am using only primary level features of Java. More ...
The question is, in C++, how do detect if an object is allocated on the stack or heap.
On Windows, the stack address is in the range of 0x80000000
. If the address of the variable is in this range, then you could say that the object is allocated on the stack; else it is allocated on the heap. This technique of detecting is not preferable since it may not work on other operating systems (such as linux), and deals with the platform specific information making it a non-portable solution.
You may not know the guy in black. You should definitely be knowing the guy in green. Don’t you?
I am not a patron of his philosophies against planned design. But he sure is a great guy with lots of good ideas. It was nice having an hour long chat with him.
Alright, it is a long wait. And I am going to keep it short.
Recap of the problem: Why did the ref
variable in SomeMethod not get the expected result (DayOfWeek
.Friday
) when called from a different thread?
Boxing. Yes, that is the culprit. Sometimes, it is subtle to note. DayOfWeek
is an enum
β a value type. When the method is called from a different thread, we put the argument (arg3
) in an object array, and thatβs where the value gets boxed. So we happen to assign the resultant value to the boxed value.
Straight to code…..
int SomeMethod(string arg1, string arg2, ref DayOfWeek arg3) { // Wildest implementation! }
The above method had to be executed on its dispatcher thread. So let unravel a bit of the wildest implementation above.
int SomeMethod(string arg1, string arg2, ref DayOfWeek arg3) { if (Disptacher.CheckAccess()) { var funcDelegate = (Func<string, string, DayOfWeek, int>)SomeMthod;return Dispatcher.Invoke(funcDelegate, arg1, arg2, ref arg3); } // Wilder implementation!!
}
Before you say anything, yes, the compiler spat the following errors:-
More ...
Currying is a mathematical concept based on lambda calculus. It is a technique of operating on a function (taking multiple arguments) by splitting and capable of chaining into a series of single argument functions. It is very similar to what a human would attempt to do on paper. For example, if you have to add numbers 1
through 10
, what would you do? Class II mathematics -0
in hand, 1
in the mind, add 0
and 1
, so 1
in the mind, then 2
in the hand, … up to 10
. So we compute the addition with one argument at a time.
More ...
template<typename A, typename B>
class TClass
{
public: TClass()
{
}
// Overload #1
public: std::string SomeMethod(A a, B b)
{
std::ostringstream ostr;
ostr << a << "-" << b;
return ostr.str();
}
// Overload #2
public: std::string SomeMethod(B b, A a)
{
std::ostringstream ostr;
ostr << b << "-" << a;
return ostr.str();
}
};
So that is a template class with SomeMethod overloads. Why would somebody write such a class? Imagine it is an adder class, and the method overloads could used to add with parameters specified in either order. Following is the way one could use the above (based on the adder example):-
More ...
We all know C# does not offer multiple inheritance but offers arguments that programmers can live without it. It is true in almost all cases, especially all cat and animal or employee and manager projects. I have seen a few cases where if C# offered multiple inheritance, the solution would have been natural, elegant and succinct.
Imagine that I have a component (UI, non-UI, doesnβt matter). You can make calls into the component, which does some interesting work for you. Imagine that the component takes an interface IComponentCallback
to notify its parent. So I would do is have my parent class derive from IComponentCallback
interface and pass this to the component. The code would look something like this:-
There are two facilities in C# to determine the size of a type β sizeof
operator andMarshal.SizeOf
method. Let us discuss what they offer and how they differ.
Before we settle the difference between sizeof
and Marshal.SizeOf
, let us discuss why would we want to compute the size of a variable or type. Other than academic, one typical reason to know the size of a type (in a production code) would be allocate memory for an array of items; typically done while using malloc
. Unlike in C++ (or unmanaged world), computing the size of a type definitely has no such use in C# (managed world). Within the managed application, size does not matter; since there are types provided by the CLR for creating \ managing fixed size and variable size (typed) arrays. And as per MSDN, the size cannot be computed accurately. Does that mean we donβt need to compute the size of a type at all when working in the CLR world? Obviously no, else I would not be writing this post.
Senthil has left us thrilled in his new post, and also inspired me to write about the topic. Although, anonymous delegates have become a mundane stuff amongst programmers, there is still these subtle stuff left unexplored. Alright, let us try to answer Senthilβs question before he unravels the mystery in his next post.
A delegate is identified by its target. The target is the method to be executed on a delegate invocation and its associated instance or type. If the target is an instance method, the delegate preserves the target method pointer and the object instance. If the target is a static method, the delegate preserves the target method pointer and the type to which it belongs. So when a code like the one below to register a method to an event (or multicast delegate) is executed, a delegate object (EventHandler here) with the target information embedded is created and added to the invocation list of the event (or multicast delegate, KeyPressed here).
More ...