a C# version of c++ can be created?
-
Just seemed like a rant to me. It is the end of the day, or is it the beginning? I'm so confused. :)
Failure is not an option; it's the default selection.
Mark Nischalke wrote:
Just seemed like a rant to me. It is the end of the day, or is it the beginning? I'm so confused. :)
:-) It's always the end of the day in some part of our planet.
Regards, Nish
My technology blog: voidnish.wordpress.com
-
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!!!
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.
-
And your point is?
Failure is not an option; it's the default selection.
Dangling from the sounds of it.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
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!!!
Take a look at the "D Language[^]". It might do what you're wanting.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
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. -
Mark Nischalke wrote:
And your point is?
Not at your brightest today, are you? :-)
Regards, Nish
My technology blog: voidnish.wordpress.com
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.
-
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?