why Pascal calling in .net as compared to cdecl calling in c

Question

why only Pascale calling method in .net language? as in c language we can use both Pascal calling and cdecl calling
In Pascal calling we pass values from left to right
and in cdecl calling we pass values from right to left

Vulpes · Answer

I can't give you a definitive answer on Java which runs on a lot more platforms than Microsoft C# though I don't know of any 16-bit JVMs. However, on Win32 or Win64 JVMs, I'd be very surprised if the default calling convention is anything other than StdCall or CDecl and so the parameters will be passed from right to left as they are in C#. One thing I do know is that parameters to Java methods are evaluated from left to right and so I'd expect these to be fully evaluated before being passed to the method as they are in C# which would explain why the output is the same and different to that produced by the C compilers we have tried.

shrikant mule · Answer

but in java also it gives same o/p like in c#. Is there also pre increment and post increment not working as they are in C

Vulpes · Answer

Whilst I can understand why that example might lead you to believe that C# is passing the parameters from left to right, in fact it demonstrates the opposite. In C#, the expressions ++a and a++ are evaluated before the results are passed as arguments to the abc method. Moreover, they're evaluated in the order that they're written and pushed on the stack in that order. You can see that this is so by disassembling the following C# program (very similar to your example): using System; class Test { public void abc(int x,int y) { Console.WriteLine(x + " " + y); } static void Main() { Test obj = new Test(); int a = 5; obj.abc(++a,a++); Console.WriteLine(a); } } /* output: 6 6 7 */ // disassembly of Main() method using Redgate Reflector .method private hidebysig static void Main() cil managed { .entrypoint .maxstack 5 .locals init ( [0] class Test test, [1] int32 num) L_0000: nop L_0001: newobj instance void Test::.ctor() L_0006: stloc.0 L_0007: ldc.i4.5 L_0008: stloc.1 L_0009: ldloc.0 L_000a: ldloc.1 L_000b: ldc.i4.1 L_000c: add L_000d: dup L_000e: stloc.1 L_000f: ldloc.1 L_0010: dup L_0011: ldc.i4.1 L_0012: add L_0013: stloc.1 L_0014: callvirt instance void Test::abc(int32, int32) L_0019: nop L_001a: ldloc.1 L_001b: call void [mscorlib]System.Console::WriteLine(int32) L_0020: nop L_0021: ret } If you follow the IL instructions through you'll see that the stack (from bottom to top) contains the folowing values just before the abc method is called: address of 'Test' object 6 6 and the local variable 'a' contains 7 which explains the output we're getting. When the method is called, the arguments will be popped from the stack and will therefore be passed to the method from right to left. The last one popped will, of course, be the hidden first argument which is the instance pointer, as we're using an instance method. The equivalent C program: #include void abc(int x,int y) { printf("%d %d", x, y); } int main () { int a = 5; abc(++a, a++); printf("
%d
", a); return 0; } works differently to this even though the arguments are still passed from right to left. Worse still, the results appear to be compiler dependent because in Visual C (I don't have Turbo C) it produces the output: 6 5 7 and not: 7 5 7 Evidently the arguments are evaluated in the order they are passed rather than the order they're written, So, in Turbo C, the second argument (a++) is passed as 5 (the current value of 'a'), immediately incremented to 6 and then to 7 (++a) which is passed as the first argument. In Visual C, it appears that the first increment (a++) is postponed until after the second argument has been evaluated and passed. In fact, it is definitely the case that the postfix and prefix increment (and decrement) operators are not implemented in exactly the same way in C# as they are in C. See, for example, this thread and the post by compiler expert, Eric Lippert, who was until recently a member of the C# team: http://stackoverflow.com/questions/3346450/what-is-the-difference-between-i-and-i

shrikant mule · Answer

No man c# is basically made on Pascal calling if you don't believe try this on C# .net public void abc(int x,int y) { Console.WriteLine(x+" "+y); } static void Main() {int a=5; obj.abc(++a,a++); } you will get output x=6 y=6 but in cdecl calling in c language on turbo you will get x=7 y=5

Vulpes · Answer

The default calling convention for Windows .NET (and the Win32 API) is in fact stdcall rather than pascal. pascal is not supported at all as it is typically used in 16-bit environments whereas .NET only works on 32 or 64 bit platforms. With stdcall, whilst the callee is responsible for cleaning up the stack (as in pascal), the parameters are pushed on the stack from right to left (as in cdecl). However, when calling unmanaged functions using 'platform invoke' you can specify that cdecl be used instead. Confusingly, the default calling convention for Windows CE.NET is cdecl rather than stdcall!