a C# version of c++ can be created?
-
Just think on the following imagine c++ to have the c# syntax but you can create pointers an all the c++ stuff but with the c# syntax i mean without the use of the net framework. I just dont know with MS have not thought in that option, cmon lets face it c++ syntax has around 25 years old, a lot of stuff has happened since then!!!
-
C# is just a language -- if you can write a compiler to compile to a native exe for your choice of operating system, then go ahead. In theory it shouldn't require the .net (or any other) framework, but there are some features (e.g.
foreach,using) that require some underlying structure.It may not require a "framework" as extensive as the .NET framework, but C# (as any high-level language) certainly requires some form of runtime library. Even C needs a runtime library, the trick is to have the ability to statically link against only those portions used by your program. Unfortunately C# programs require bit of code - a good portion of the BCL (strings, arrays, etc.), the garbage collector, etc. Mono comes with an
mkbundletool that can create a native executable from managed code. Unfortunately the static linking option is not available for Windows. -
Just think on the following imagine c++ to have the c# syntax but you can create pointers an all the c++ stuff but with the c# syntax i mean without the use of the net framework. I just dont know with MS have not thought in that option, cmon lets face it c++ syntax has around 25 years old, a lot of stuff has happened since then!!!
Vasily Tserekh wrote:
c# syntax but you can create pointers
You can do that in C#.
Vasily Tserekh wrote:
without the use of the net framework
You don't need to reference any .Net libraries. Though I think it'd still require the CLR. On the other hand, the CLR compiles to native code, so if it drops those files somewhere maybe you could grab them (not sure if they'd run independently, however).
-
Actually, that would suck. There are many nice things about the C# syntax, but then we'd suddenly lose templates (generics do not replace them), classes couldn't go on the stack (that will really hurt), there would be no private or protected inheritance, no friend functions/classes, half of the operators that are useful when working with pointers wouldn't exist, and I could go on for a while but maybe you get the point. On the other hand if you said "just imagine C# compiling to native code directly instead of going through MSIL", then yes, I would love that (just so long as we get to keep the nice compilation model - no linking please!). It would kill some parts of reflection, but I wouldn't mourn the loss.
harold aptroot wrote:
classes couldn't go on the stack
But structs can go on the stack.
harold aptroot wrote:
there would be no private or protected inheritance
Not sure what you mean here. Private members do get inherited, and protected members both get inherited and can be overridden.
harold aptroot wrote:
half of the operators that are useful when working with pointers wouldn't exist
I'm not sure what's missing, but AFAIK, you can use pointers and do various pointerly things to them (e.g., pointer arithmetic).
-
I just said that c++ syntax can be improved and code wont have to be so ugly and still doing the same stuff, take the c# enums for making an example.
Vasily Tserekh wrote:
I just said that c++ syntax can be improved and code wont have to be so ugly and still doing the same stuff, take the c# enums for making an example.
I was replying to Mark. And for the record, there are many people who think the C++ syntax is way better than Java/C# syntax!
Regards, Nish
My technology blog: voidnish.wordpress.com
-
harold aptroot wrote:
classes couldn't go on the stack
But structs can go on the stack.
harold aptroot wrote:
there would be no private or protected inheritance
Not sure what you mean here. Private members do get inherited, and protected members both get inherited and can be overridden.
harold aptroot wrote:
half of the operators that are useful when working with pointers wouldn't exist
I'm not sure what's missing, but AFAIK, you can use pointers and do various pointerly things to them (e.g., pointer arithmetic).
AspDotNetDev wrote:
Not sure what you mean here. Private members do get inherited, and protected members both get inherited and can be overridden.
When you write
class A : private BAspDotNetDev wrote:
I'm not sure what's missing
->* and .* so ok not half of them.. a third.
-
harold aptroot wrote:
classes couldn't go on the stack
But structs can go on the stack.
harold aptroot wrote:
there would be no private or protected inheritance
Not sure what you mean here. Private members do get inherited, and protected members both get inherited and can be overridden.
harold aptroot wrote:
half of the operators that are useful when working with pointers wouldn't exist
I'm not sure what's missing, but AFAIK, you can use pointers and do various pointerly things to them (e.g., pointer arithmetic).
BTW, private members do get inherited, you just cannot access them in the derived class. See Derived Class Access to Base Class Members in http://msdn.microsoft.com/en-us/library/ms173149.aspx[^]
-
BTW, private members do get inherited, you just cannot access them in the derived class. See Derived Class Access to Base Class Members in http://msdn.microsoft.com/en-us/library/ms173149.aspx[^]
Glenn Dawson wrote:
BTW, private members do get inherited, you just cannot access them in the derived class
Sure you can. Just not directly. :rolleyes:
-
Glenn Dawson wrote:
BTW, private members do get inherited, you just cannot access them in the derived class
Sure you can. Just not directly. :rolleyes:
Hehe, I just re-read your post. You said do. It's late. I'm going home now. :)
-
And your point is?
Failure is not an option; it's the default selection.
Mark Nischalke wrote:
And your point_er_ is?
FTFY :)
-
That's still managed code. He wants to use C# syntax and generate native code.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
It may not require a "framework" as extensive as the .NET framework, but C# (as any high-level language) certainly requires some form of runtime library. Even C needs a runtime library, the trick is to have the ability to statically link against only those portions used by your program. Unfortunately C# programs require bit of code - a good portion of the BCL (strings, arrays, etc.), the garbage collector, etc. Mono comes with an
mkbundletool that can create a native executable from managed code. Unfortunately the static linking option is not available for Windows.Daniel Grunwald wrote:
not require a "framework"
It's more that it shouldn't require a virtual machine, but even that may be too generic a term.
Daniel Grunwald wrote:
Even C needs a runtime library
Basically, yes, but is that technically true? Can't you compile and run a program that doesn't link to and use any libraries? Certainly you can write a program that doesn't
# includeanything. As a simple example:int
main
(
int argc
,
char* argv[]
)
{
return ( argv==0?-1:argc ) ;
}This works, but obviously with no IO it can't do much. Does this example use the "standard library"? Is it not possible to use a completely different library instead? D is similar, and includes garbage collection -- I don't know whether or not you can compile without the "standard library".
Daniel Grunwald wrote:
a good portion of the BCL (strings, arrays, etc.), the garbage collector, etc.
Yes, but in theory you should be able to write a C# program without ever saying
System:namespace Test
{
public static class C
{
public static int
Main
(
string[] args
)
{
return ( args==null?-1:args.Length ) ;
}
}
}(Again, there's not much you can do without IO.) Such a program could be compiled against some minimal* implementation of BCL. I don't care whether or not it's statically linked (that's just implementation details :-D ), as long as it works. What I'm more concerned about is that the underlying structure (framework, virtual machine, whatever) needs to have a concept of System.IDisposable and System.IEnumerable in order to compile the language. * Just enough to support the language -- object, int, string, etc.
-
Daniel Grunwald wrote:
not require a "framework"
It's more that it shouldn't require a virtual machine, but even that may be too generic a term.
Daniel Grunwald wrote:
Even C needs a runtime library
Basically, yes, but is that technically true? Can't you compile and run a program that doesn't link to and use any libraries? Certainly you can write a program that doesn't
# includeanything. As a simple example:int
main
(
int argc
,
char* argv[]
)
{
return ( argv==0?-1:argc ) ;
}This works, but obviously with no IO it can't do much. Does this example use the "standard library"? Is it not possible to use a completely different library instead? D is similar, and includes garbage collection -- I don't know whether or not you can compile without the "standard library".
Daniel Grunwald wrote:
a good portion of the BCL (strings, arrays, etc.), the garbage collector, etc.
Yes, but in theory you should be able to write a C# program without ever saying
System:namespace Test
{
public static class C
{
public static int
Main
(
string[] args
)
{
return ( args==null?-1:args.Length ) ;
}
}
}(Again, there's not much you can do without IO.) Such a program could be compiled against some minimal* implementation of BCL. I don't care whether or not it's statically linked (that's just implementation details :-D ), as long as it works. What I'm more concerned about is that the underlying structure (framework, virtual machine, whatever) needs to have a concept of System.IDisposable and System.IEnumerable in order to compile the language. * Just enough to support the language -- object, int, string, etc.
PIEBALDconsult wrote:
Basically, yes, but is that technically true? Can't you compile and run a program that doesn't link to and use any libraries? Certainly you can write a program that doesn't
# includeanything.That depends. Built-in C language features may very well map to library functions - think embedded CPUs with a software floating point library. As soon as the language has more features, inevitably some of them will need a runtime library. For example the
newoperator in C++ will need amallocimplementation or similar. And then there's exceptions, dynamic_cast, ...PIEBALDconsult wrote:
What I'm more concerned about is that the underlying structure (framework, virtual machine, whatever) needs to have a concept of System.IDisposable and System.IEnumerable in order to compile the language.
Why is that a concern, but
stringisn't? IDisposable and IEnumerable are trivial interfaces, strings and arrays are much more complex. There are actually quite a few types in .NET that are well-known to the compiler, many more than you think.decimalis just a struct, nothing special on MSIL level. And then there are at least these types that any C# compiler will need: *Type- fortypeof()*Array- base class for arrays *Attribute- base class for attribute, required for the disambiguation rule in ยง17.2 *ValueType- base class for structs *Enum- base class for enums *Delegate- base class for delegates *Exception- base class for exceptions *IEnumerableandIEnumerator- forforeach*IEnumerable<T>andIEnumerator<T>- foryield return*IList<T>- interface implemented by arrays *IReadOnlyList<T>- interface implemented by arrays in .NET 4.5 *TaskandTask<T>- forasync/await*Nullable<T>- nullable operator lifting etc. *IDisposable- using statement Of course there are many more, e.g. attributes that have special effects (ParamsAttribute etc.), but those can be said to be specific to the .NET implementation of C#, they aren't necessary in general. Still, the abov -
Actually, that would suck. There are many nice things about the C# syntax, but then we'd suddenly lose templates (generics do not replace them), classes couldn't go on the stack (that will really hurt), there would be no private or protected inheritance, no friend functions/classes, half of the operators that are useful when working with pointers wouldn't exist, and I could go on for a while but maybe you get the point. On the other hand if you said "just imagine C# compiling to native code directly instead of going through MSIL", then yes, I would love that (just so long as we get to keep the nice compilation model - no linking please!). It would kill some parts of reflection, but I wouldn't mourn the loss.
harold aptroot wrote:
classes couldn't go on the stack (that will really hurt),
How so? Surely you don't pass most class instances via the stack?
harold aptroot wrote:
half of the operators that are useful when working with pointers wouldn't exist,
The OP specifically said that pointers exist so why would the operators associated with them not exist?
-
Daniel Grunwald wrote:
not require a "framework"
It's more that it shouldn't require a virtual machine, but even that may be too generic a term.
Daniel Grunwald wrote:
Even C needs a runtime library
Basically, yes, but is that technically true? Can't you compile and run a program that doesn't link to and use any libraries? Certainly you can write a program that doesn't
# includeanything. As a simple example:int
main
(
int argc
,
char* argv[]
)
{
return ( argv==0?-1:argc ) ;
}This works, but obviously with no IO it can't do much. Does this example use the "standard library"? Is it not possible to use a completely different library instead? D is similar, and includes garbage collection -- I don't know whether or not you can compile without the "standard library".
Daniel Grunwald wrote:
a good portion of the BCL (strings, arrays, etc.), the garbage collector, etc.
Yes, but in theory you should be able to write a C# program without ever saying
System:namespace Test
{
public static class C
{
public static int
Main
(
string[] args
)
{
return ( args==null?-1:args.Length ) ;
}
}
}(Again, there's not much you can do without IO.) Such a program could be compiled against some minimal* implementation of BCL. I don't care whether or not it's statically linked (that's just implementation details :-D ), as long as it works. What I'm more concerned about is that the underlying structure (framework, virtual machine, whatever) needs to have a concept of System.IDisposable and System.IEnumerable in order to compile the language. * Just enough to support the language -- object, int, string, etc.
PIEBALDconsult wrote:
Basically, yes, but is that technically true? Can't you compile and run a program that doesn't link to and use any libraries?
In terms of practicality it is true. If one wants to write real applications with a language in a realistic amount of time then it will need supporting 'libraries'. The term 'library' can have a nebulous meaning since, for example, perl (the language) can write to the files and the console without a 'library' but C/C++ cannot. However the same functionality that exists in C/C++ for that must then be embedded in the language itself. And for modern enterprise applications attempting to embed every needed feature in the language itself isn't going to be feasible.
-
harold aptroot wrote:
classes couldn't go on the stack (that will really hurt),
How so? Surely you don't pass most class instances via the stack?
harold aptroot wrote:
half of the operators that are useful when working with pointers wouldn't exist,
The OP specifically said that pointers exist so why would the operators associated with them not exist?
jschell wrote:
How so? Surely you don't pass most class instances via the stack?
Pass? No. But local variables that don't escape would have to use dynamic allocation, and that wouldn't be good. Or they would have to be structs, which isn't always desirable or even possible.
jschell wrote:
The OP specifically said that pointers exist so why would the operators associated with them not exist?
Pointers exist in C# anyway, but not all operators associated with them do. (see my other post)
-
jschell wrote:
How so? Surely you don't pass most class instances via the stack?
Pass? No. But local variables that don't escape would have to use dynamic allocation, and that wouldn't be good. Or they would have to be structs, which isn't always desirable or even possible.
jschell wrote:
The OP specifically said that pointers exist so why would the operators associated with them not exist?
Pointers exist in C# anyway, but not all operators associated with them do. (see my other post)
-
harold aptroot wrote:
Pointers exist in C# anyway, but not all operators associated with them do. (see my other post)
As phrased by the OP my take was that they were suggesting that pointers would reflect the semantics of C++, not C#.
That makes no sense to me. The pointers in C# are not that different from the pointers in C++. You need an extra unsafe or fixed here and there, but that's about as far as the differences go. But there are two (not very common) operators that just aren't in C#, and OP said nothing about creating them.
-
That makes no sense to me. The pointers in C# are not that different from the pointers in C++. You need an extra unsafe or fixed here and there, but that's about as far as the differences go. But there are two (not very common) operators that just aren't in C#, and OP said nothing about creating them.
harold aptroot wrote:
That makes no sense to me.
The OP referred to pointers, my presumption was that they wanted more than what currently exists.
harold aptroot wrote:
But there are two (not very common) operators that just aren't in C#, and OP said nothing about creating them.
You referred to operators and it could be that that is what the OP is referring to.
-
harold aptroot wrote:
That makes no sense to me.
The OP referred to pointers, my presumption was that they wanted more than what currently exists.
harold aptroot wrote:
But there are two (not very common) operators that just aren't in C#, and OP said nothing about creating them.
You referred to operators and it could be that that is what the OP is referring to.