inline functions

[Will Pittenger]

Does C# inline functions? I do not see a inline keyword. Is there an
implicit inline? Can the compiler select functions for auto-inlining? I am
more used to C++ where all these things are possible.

 

[Grant Richins [MS]]

The C# compiler does not inline functions. However, the .NET runtime/JIT is
allowed to inline functions, and often does.

 

[Eric Gunnerson [MS]]

Just a quick note:

'inline' is ignored by many C and C++ compilers, as the compiler can
generally make a better decision about what to inline and what not to inline
than the programmer.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Chad Myers]

JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

 

[Rob Tillie]

If you haven't prejitted your assembly with ngen.exe your assembly will be
jitted. The same for a web assembly.
Now why is C# castrated? It is the most beautiful OO language I've ever
seen. Using your analogy, you can see C++ as a transvestite .
Ask yourself, do you really want to think about whether a function should be
inlined or not? Well, I don't.

Greetz and good luck with your exploration,
-- Rob.

 

[Will Pittenger]

Great. How should I call functions in a MFC extension library. Such a
library might have functions taking as parameters and/or returning CStrings
and CWnds. (Or for that matter a generic C++ style class.) What would be
the equivalent of pure virtual functions and multiple derivation? I am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate doing any web
stuff for a while. I am looking at doing some things that I think that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
runtime/JIT auto-inlining?

 

[Chad Myers]

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c

How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c

Great. How should I call functions in a MFC extension library.

Such

a
library might have functions taking as parameters and/or returning CStrings
and CWnds. (Or for that matter a generic C++ style class.) What would be
the equivalent of pure virtual functions and multiple derivation? I am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate

doing

any

confers

no

 

[Will Pittenger]

The scenario that I had in mind was you have to use a DLL that is already on
a user's machine. You are required to coexist with a larger and older MFC
based program. Most of what you need is in one of its DLLs. Perhaps that
DLL has tools for accessing a file format that you have no control or
knowledge of. I have had to put up with that many times. Good luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c

How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c

Great. How should I call functions in a MFC extension library.

Such

a
library might have functions taking as parameters and/or returning CStrings
and CWnds. (Or for that matter a generic C++ style class.) What would be
the equivalent of pure virtual functions and multiple derivation? I am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate

doing

any
web
stuff for a while. I am looking at doing some things that I think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
The C# compiler does not inline functions. However, the .NET
runtime/JIT
is
allowed to inline functions, and often does.

confers

no
rights.


Does C# inline functions? I do not see a inline keyword. Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Will Pittenger]

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

The scenario that I had in mind was you have to use a DLL that is already on
a user's machine. You are required to coexist with a larger and older MFC
based program. Most of what you need is in one of its DLLs. Perhaps that
DLL has tools for accessing a file format that you have no control or
knowledge of. I have had to put up with that many times. Good luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c

How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension library. Such
a
library might have functions taking as parameters and/or returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.) What
would be
the equivalent of pure virtual functions and multiple derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate doing
any
web
stuff for a while. I am looking at doing some things that I think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However, the .NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and confers
no
rights.


Does C# inline functions? I do not see a inline keyword. Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Chad Myers]

A small MEC++ assembly could wrap this for you. It might be
possible to consume MFC classes from C#, I'm not sure, I haven't
had much experience in that realm.

-c

The scenario that I had in mind was you have to use a DLL that is already on
a user's machine. You are required to coexist with a larger and older MFC
based program. Most of what you need is in one of its DLLs. Perhaps that
DLL has tools for accessing a file format that you have no control or
knowledge of. I have had to put up with that many times. Good luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c

How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension library. Such
a
library might have functions taking as parameters and/or returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.) What
would be
the equivalent of pure virtual functions and multiple derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, ..NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate doing
any
web
stuff for a while. I am looking at doing some things that I think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However, the ..NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and confers
no
rights.


Does C# inline functions? I do not see a inline

keyword.
Is

there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Chad Myers]

Managed DirectX 9. Anything you could possibly want.

What is CDC? Why would you want to use that over DX anyhow?

Also, there's an OpenGL implementation for .NET (written in
C#, remember, C# is just a language, it doens't really provide
anything, .NET provides all the functionality).

-c

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

The scenario that I had in mind was you have to use a DLL that is

already

on
a user's machine. You are required to coexist with a larger and older MFC
based program. Most of what you need is in one of its DLLs. Perhaps that
DLL has tools for accessing a file format that you have no control or
knowledge of. I have had to put up with that many times. Good luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c


How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension library.
Such
a
library might have functions taking as parameters and/or returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.) What
would be
the equivalent of pure virtual functions and multiple derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, ..NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate
doing
any
web
stuff for a while. I am looking at doing some things that I
think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However, the ..NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


Does C# inline functions? I do not see a inline keyword.
Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Will Pittenger]

Real answers. Finally.

BTW: The scenario that I mentioned was hypothetical. I have been
programming many years to know that I always have to keep my options open.
In general, if that DLL was going to be out there anyway, and reproducing it
in C# would take too long, the DLL would be used. If that made C++ more
convenient, tough luck to those who favor C#. By the time a wrapper DLL
(based on what I think would be involved in wrapping the MFC classes and MFC
style classes in COM interfaces) could be written, some projects that I have
seen could probably be written in from scratch in C++.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Will,
Most of the 3d edges and/or rectangles functions are in the
System.Windows.Forms.ControlPaint class.

I would recommend considering creating a Managed wrapper for your MFC legacy
DLL. Something along the lines of:
http://msdn.microsoft.com/library/d...nstrateswrappingcdllwithmanagedextensions.asp

Hope this helps
Jay

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
already

derivation?

I

am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, ..NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate
doing
any
web
stuff for a while. I am looking at doing some things that I
think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However, the .NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


Does C# inline functions? I do not see a inline keyword.
Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Will Pittenger]

Why get DirectX or OpenGL in involved to just a bunch of button and other
control classes? Besides, DrawFrameControl uses the same Windows code that
Windows itself uses to draw caption bar buttons, radio buttons, scrollbars,
and more. (The control's WM_PAINT handler calls DrawFrameControl.) That
means that if your control uses DrawFrameControl for objects that look like
buttons, they will look like buttons regardless of which Windows version you
are on. You might have written a button class that displays graphics for
Windows 3.1 and it would look like a Windows 3.1 button until you ran the
program under Windows 9x. Then Windows would make your button look like a
Windows 9x button. If you later provided a manifest, you could skin your
button -- with no code. All you would ever paint is the graphic. That is
what you use DrawFrameControl for. Draw3dRect (MFC only) lets you draw the
drop border you need for custom edit box-like areas. DrawEdge (MFC and GDI)
is what you would use if you wanted a group box style etched (or raised)
line, or a diagonal 3d line. I think that Jay Harlow provided what I was
looking for. DirectX and OpenGL sound like the sledge hammer providing a
slight tap.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Managed DirectX 9. Anything you could possibly want.

What is CDC? Why would you want to use that over DX anyhow?

Also, there's an OpenGL implementation for .NET (written in
C#, remember, C# is just a language, it doens't really provide
anything, .NET provides all the functionality).

-c

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

The scenario that I had in mind was you have to use a DLL that is

already

on
a user's machine. You are required to coexist with a larger and older MFC
based program. Most of what you need is in one of its DLLs. Perhaps that
DLL has tools for accessing a file format that you have no control or
knowledge of. I have had to put up with that many times. Good luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c


How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension library.
Such
a
library might have functions taking as parameters and/or returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.) What
would be
the equivalent of pure virtual functions and multiple derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate
doing
any
web
stuff for a while. I am looking at doing some things that I
think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However, the .NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


Does C# inline functions? I do not see a inline keyword.
Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Chad Myers]

Choosing your entire application's framework based on the
usage of one legacy DLL seems rather hasty.

A wrapper DLL in MEC++ wouldn't be that difficult. In fact,
the .NET part is simple, it's the unmanaged side that would
be difficult.

And no, it's not wrapping MFC with COM, it'd be creating
a small .NET class in C++ w/Managed Extensions to allow you
to call into the MFC class. It's like a small bridge class,
nothing fancy.

-c

Real answers. Finally.

BTW: The scenario that I mentioned was hypothetical. I have been
programming many years to know that I always have to keep my options open.
In general, if that DLL was going to be out there anyway, and reproducing it
in C# would take too long, the DLL would be used. If that made C++ more
convenient, tough luck to those who favor C#. By the time a wrapper DLL
(based on what I think would be involved in wrapping the MFC classes and MFC
style classes in COM interfaces) could be written, some projects that I have
seen could probably be written in from scratch in C++.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Will,
Most of the 3d edges and/or rectangles functions are in the
System.Windows.Forms.ControlPaint class.

I would recommend considering creating a Managed wrapper for your

MFC

legacy
DLL. Something along the lines of:

http://msdn.microsoft.com/library/d...nstrateswrappingcdllwithmanagedextensions.asp

Hope this helps
Jay

is
already older
MFC Perhaps
that

class.)

What derivation?

Remember,

.NET

is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate
doing
any
web
stuff for a while. I am looking at doing some things that I
think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However,

the
.NET

runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


"Will Pittenger" <[email protected]> wrote

in
message

Does C# inline functions? I do not see a inline keyword.
Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Chad Myers]

You can call all but a handful of Win32 APIs from .NET.

So if you can do it through GDI, then you can do it in Win32.
A lot of the GDI is implemented in the .NET Framework already.

I'm not familiar with your specific case, but it's probably
doable in .NET, though I'm not sure why'd you'd be doing such
things. It seems C++ developers like to break from the norm
and rewrite the entire UI and you end up with horrible UIs
that are inconsistent with the rest of the OS. The .NET
framework provides dozens of controls that are all XP-themeable.
You'd have a hard time finding a reason where those aren't
good enough (well, fancier DataGrids are pretty handy, but
as far as basic controls like textboxes, etc).

-c

Why get DirectX or OpenGL in involved to just a bunch of button and other
control classes? Besides, DrawFrameControl uses the same Windows code that
Windows itself uses to draw caption bar buttons, radio buttons, scrollbars,
and more. (The control's WM_PAINT handler calls DrawFrameControl.) That
means that if your control uses DrawFrameControl for objects that look like
buttons, they will look like buttons regardless of which Windows version you
are on. You might have written a button class that displays graphics for
Windows 3.1 and it would look like a Windows 3.1 button until you ran the
program under Windows 9x. Then Windows would make your button look like a
Windows 9x button. If you later provided a manifest, you could skin your
button -- with no code. All you would ever paint is the graphic. That is
what you use DrawFrameControl for. Draw3dRect (MFC only) lets you draw the
drop border you need for custom edit box-like areas. DrawEdge (MFC and GDI)
is what you would use if you wanted a group box style etched (or raised)
line, or a diagonal 3d line. I think that Jay Harlow provided what I was
looking for. DirectX and OpenGL sound like the sledge hammer providing a
slight tap.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Managed DirectX 9. Anything you could possibly want.

What is CDC? Why would you want to use that over DX anyhow?

Also, there's an OpenGL implementation for .NET (written in
C#, remember, C# is just a language, it doens't really provide
anything, .NET provides all the functionality).

-c

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
The scenario that I had in mind was you have to use a DLL that

is
already

on
a user's machine. You are required to coexist with a larger and older MFC
based program. Most of what you need is in one of its DLLs. Perhaps that
DLL has tools for accessing a file format that you have no

control
or

knowledge of. I have had to put up with that many times. Good luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c


How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension library.
Such
a
library might have functions taking as parameters and/or returning
CStrings
and CWnds. (Or for that matter a generic C++ style

class.)
What

would be
the equivalent of pure virtual functions and multiple derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#.

Remember,
.NET

is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has

all
the

good stuff and almost none of the bad of C++. To each

his
own,

I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate
doing
any
web
stuff for a while. I am looking at doing some things

that
I

think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
"Grant Richins [MS]" <[email protected]>

wrote
in

message
The C# compiler does not inline functions. However,

the
.NET

runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


"Will Pittenger" <[email protected]> wrote

in
message

Does C# inline functions? I do not see a inline keyword.
Is
there an
implicit inline? Can the compiler select

functions
for

auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Chad Myers]

So if you can do it through GDI, then you can do it in Win32.

I mean "then you can do it in .NET", sorry.

-Chad

You can call all but a handful of Win32 APIs from .NET.

So if you can do it through GDI, then you can do it in Win32.
A lot of the GDI is implemented in the .NET Framework already.

I'm not familiar with your specific case, but it's probably
doable in .NET, though I'm not sure why'd you'd be doing such
things. It seems C++ developers like to break from the norm
and rewrite the entire UI and you end up with horrible UIs
that are inconsistent with the rest of the OS. The .NET
framework provides dozens of controls that are all XP-themeable.
You'd have a hard time finding a reason where those aren't
good enough (well, fancier DataGrids are pretty handy, but
as far as basic controls like textboxes, etc).

-c

Why get DirectX or OpenGL in involved to just a bunch of button and other
control classes? Besides, DrawFrameControl uses the same Windows

code

that
Windows itself uses to draw caption bar buttons, radio buttons, scrollbars,
and more. (The control's WM_PAINT handler calls DrawFrameControl.) That
means that if your control uses DrawFrameControl for objects that

look

like
buttons, they will look like buttons regardless of which Windows version you
are on. You might have written a button class that displays

graphics

for
Windows 3.1 and it would look like a Windows 3.1 button until you

ran

the
program under Windows 9x. Then Windows would make your button look like a
Windows 9x button. If you later provided a manifest, you could skin your
button -- with no code. All you would ever paint is the graphic. That is
what you use DrawFrameControl for. Draw3dRect (MFC only) lets you draw the
drop border you need for custom edit box-like areas. DrawEdge (MFC and GDI)
is what you would use if you wanted a group box style etched (or raised)
line, or a diagonal 3d line. I think that Jay Harlow provided what

I

was
looking for. DirectX and OpenGL sound like the sledge hammer providing a
slight tap.

to

make

a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension
library.
Such
a
library might have functions taking as parameters and/or
returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.)
What
would be
the equivalent of pure virtual functions and multiple
derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember,
.NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all
the
good stuff and almost none of the bad of C++. To each his
own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived
ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++
code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better
determine
at run-time which optimizations will have the most impact.

-c

message
Would JIT apply to a local executable? I do not
anticipate
doing
any
web
stuff for a while. I am looking at doing some

things

that

However,

the

warranties,

and

 

[Will Pittenger]

Here is another hypothetical scenario for you, also based on real world
experience:

You are working on a computer program that will fly airplanes. One program,
running on just one computer (with perhaps backups that do nothing unless
there is a major problem) displays a map of where you are and routes
commands from the controls to the flight system. (The stick and rudder
pedal are just computer controls, like on many modern aircraft.) You have
to update the screen quickly so the pilot knows where he or she is.
However, you do not want to spend any serious amount of time (as measured in
a percentage of CPU cycles used) painting the screen. If you spend too much
time painting, the airplane could be headed towards a big mountain, but
never responds to the pilot's attempt to turn it away from that mountain
because it is too busy updating the screen. If you are a passenger on that
plane, what do you want updating the screen: Windows GDI, MFC, C# and
Graphics, OpenGL, or DirectX? If a fancy look were important, you might
vote for DirectX or OpenGL. But with lives on the line, you very quickly
consider fancy graphics to be extra baggage. At that point, I vote for the
Windows GDI. Now if .NET implements its stuff at a lower level than I have
the impression that it does, perhaps it would work. Not otherwise.

Now in a real airplane, there would be many computers to drive just the
displays. The controls would be on a second set of systems. Still, we ran
into that problem where the software runs boats. We were not talking about
something that sold for hundreds of million of dollars. Customers spent
only a small fraction of their money on the computers and software. A
luxurious interior is typically more important. You get one computer, and
you are lucky if it is a top of the line laptop. Most of the marine worthy
laptops are slow even new even compared to just other laptops.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c

How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c

Great. How should I call functions in a MFC extension library.

Such

a
library might have functions taking as parameters and/or returning CStrings
and CWnds. (Or for that matter a generic C++ style class.) What would be
the equivalent of pure virtual functions and multiple derivation? I am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, .NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate

doing

any
web
stuff for a while. I am looking at doing some things that I think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
The C# compiler does not inline functions. However, the .NET
runtime/JIT
is
allowed to inline functions, and often does.

confers

no
rights.


Does C# inline functions? I do not see a inline keyword. Is
there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Will Pittenger]

If your C# code is called on to draw something by older C-style code, that
C-style code is probably going to pass HBRUSHs and HWNDs rather than the
C#/.NET equivalents. (You might be reimplementing a DLL that an older C
program relied on. You are keeping the older program.)
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

You can call all but a handful of Win32 APIs from .NET.

So if you can do it through GDI, then you can do it in Win32.
A lot of the GDI is implemented in the .NET Framework already.

I'm not familiar with your specific case, but it's probably
doable in .NET, though I'm not sure why'd you'd be doing such
things. It seems C++ developers like to break from the norm
and rewrite the entire UI and you end up with horrible UIs
that are inconsistent with the rest of the OS. The .NET
framework provides dozens of controls that are all XP-themeable.
You'd have a hard time finding a reason where those aren't
good enough (well, fancier DataGrids are pretty handy, but
as far as basic controls like textboxes, etc).

-c

Why get DirectX or OpenGL in involved to just a bunch of button and other
control classes? Besides, DrawFrameControl uses the same Windows code that
Windows itself uses to draw caption bar buttons, radio buttons, scrollbars,
and more. (The control's WM_PAINT handler calls DrawFrameControl.) That
means that if your control uses DrawFrameControl for objects that look like
buttons, they will look like buttons regardless of which Windows version you
are on. You might have written a button class that displays graphics for
Windows 3.1 and it would look like a Windows 3.1 button until you ran the
program under Windows 9x. Then Windows would make your button look like a
Windows 9x button. If you later provided a manifest, you could skin your
button -- with no code. All you would ever paint is the graphic. That is
what you use DrawFrameControl for. Draw3dRect (MFC only) lets you draw the
drop border you need for custom edit box-like areas. DrawEdge (MFC and GDI)
is what you would use if you wanted a group box style etched (or raised)
line, or a diagonal 3d line. I think that Jay Harlow provided what I was
looking for. DirectX and OpenGL sound like the sledge hammer providing a
slight tap.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Managed DirectX 9. Anything you could possibly want.

What is CDC? Why would you want to use that over DX anyhow?

Also, there's an OpenGL implementation for .NET (written in
C#, remember, C# is just a language, it doens't really provide
anything, .NET provides all the functionality).

-c

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
The scenario that I had in mind was you have to use a DLL that is
already
on
a user's machine. You are required to coexist with a larger and
older MFC
based program. Most of what you need is in one of its DLLs.
Perhaps that
DLL has tools for accessing a file format that you have no control
or
knowledge of. I have had to put up with that many times. Good
luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c


How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension
library.
Such
a
library might have functions taking as parameters and/or
returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.)
What
would be
the equivalent of pure virtual functions and multiple
derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember,
.NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all
the
good stuff and almost none of the bad of C++. To each his
own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived
ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++
code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better
determine
at run-time which optimizations will have the most impact.

-c

message
Would JIT apply to a local executable? I do not
anticipate
doing
any
web
stuff for a while. I am looking at doing some things that
I
think
that C++
is better equipped for than C# (which seems to be
castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
in
message
The C# compiler does not inline functions. However, the
.NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


message
Does C# inline functions? I do not see a inline
keyword.
Is
there an
implicit inline? Can the compiler select functions
for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Chad Myers]

..NET has a rich GDI implementation, so use GDI. However, I'd say
that GDI is slow and if you really wanted fast 2D rendering,
then using DirectDraw would be preferable. DirectDraw is very
simple and horribly fast. Even on crappy video cards, DD would
be faster than GDI.

-c

Here is another hypothetical scenario for you, also based on real world
experience:

You are working on a computer program that will fly airplanes. One program,
running on just one computer (with perhaps backups that do nothing unless
there is a major problem) displays a map of where you are and routes
commands from the controls to the flight system. (The stick and rudder
pedal are just computer controls, like on many modern aircraft.) You have
to update the screen quickly so the pilot knows where he or she is.
However, you do not want to spend any serious amount of time (as measured in
a percentage of CPU cycles used) painting the screen. If you spend too much
time painting, the airplane could be headed towards a big mountain, but
never responds to the pilot's attempt to turn it away from that mountain
because it is too busy updating the screen. If you are a passenger on that
plane, what do you want updating the screen: Windows GDI, MFC, C# and
Graphics, OpenGL, or DirectX? If a fancy look were important, you might
vote for DirectX or OpenGL. But with lives on the line, you very quickly
consider fancy graphics to be extra baggage. At that point, I vote for the
Windows GDI. Now if .NET implements its stuff at a lower level than I have
the impression that it does, perhaps it would work. Not otherwise.

Now in a real airplane, there would be many computers to drive just the
displays. The controls would be on a second set of systems. Still, we ran
into that problem where the software runs boats. We were not talking about
something that sold for hundreds of million of dollars. Customers spent
only a small fraction of their money on the computers and software. A
luxurious interior is typically more important. You get one computer, and
you are lucky if it is a top of the line laptop. Most of the marine worthy
laptops are slow even new even compared to just other laptops.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c

How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension library. Such
a
library might have functions taking as parameters and/or returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.) What
would be
the equivalent of pure virtual functions and multiple derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember, ..NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all the
good stuff and almost none of the bad of C++. To each his own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++ code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better determine
at run-time which optimizations will have the most impact.

-c

Would JIT apply to a local executable? I do not anticipate doing
any
web
stuff for a while. I am looking at doing some things that I think
that C++
is better equipped for than C# (which seems to be castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
message
The C# compiler does not inline functions. However, the ..NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and confers
no
rights.


Does C# inline functions? I do not see a inline

keyword.
Is

there an
implicit inline? Can the compiler select functions for
auto-inlining?
I
am
more used to C++ where all these things are possible.

 

[Will Pittenger]

I was told earlier that the Win32 functions for exiting Windows and checking
or changing process rights were not available through .NET. Are you going
to tell me something different?
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

You can call all but a handful of Win32 APIs from .NET.

So if you can do it through GDI, then you can do it in Win32.
A lot of the GDI is implemented in the .NET Framework already.

I'm not familiar with your specific case, but it's probably
doable in .NET, though I'm not sure why'd you'd be doing such
things. It seems C++ developers like to break from the norm
and rewrite the entire UI and you end up with horrible UIs
that are inconsistent with the rest of the OS. The .NET
framework provides dozens of controls that are all XP-themeable.
You'd have a hard time finding a reason where those aren't
good enough (well, fancier DataGrids are pretty handy, but
as far as basic controls like textboxes, etc).

-c

Why get DirectX or OpenGL in involved to just a bunch of button and other
control classes? Besides, DrawFrameControl uses the same Windows code that
Windows itself uses to draw caption bar buttons, radio buttons, scrollbars,
and more. (The control's WM_PAINT handler calls DrawFrameControl.) That
means that if your control uses DrawFrameControl for objects that look like
buttons, they will look like buttons regardless of which Windows version you
are on. You might have written a button class that displays graphics for
Windows 3.1 and it would look like a Windows 3.1 button until you ran the
program under Windows 9x. Then Windows would make your button look like a
Windows 9x button. If you later provided a manifest, you could skin your
button -- with no code. All you would ever paint is the graphic. That is
what you use DrawFrameControl for. Draw3dRect (MFC only) lets you draw the
drop border you need for custom edit box-like areas. DrawEdge (MFC and GDI)
is what you would use if you wanted a group box style etched (or raised)
line, or a diagonal 3d line. I think that Jay Harlow provided what I was
looking for. DirectX and OpenGL sound like the sledge hammer providing a
slight tap.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)

Managed DirectX 9. Anything you could possibly want.

What is CDC? Why would you want to use that over DX anyhow?

Also, there's an OpenGL implementation for .NET (written in
C#, remember, C# is just a language, it doens't really provide
anything, .NET provides all the functionality).

-c

Almost forgot. CDC provides THREE members which draw 3D edges and/or
rectangles. How many does Graphics in C# provide? I see none.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
The scenario that I had in mind was you have to use a DLL that is
already
on
a user's machine. You are required to coexist with a larger and
older MFC
based program. Most of what you need is in one of its DLLs.
Perhaps that
DLL has tools for accessing a file format that you have no control
or
knowledge of. I have had to put up with that many times. Good
luck.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
Oh yeah, one other thing... why on EARTH would you want to use
MFC when you have .NET now? I can't even fathom the concept...!!



-c


How should I call functions in a MFC extension library

That's difficult, but if it's a COM interface, it can be done.
Otherwise, you'll have to use Managed Extensions for C++ to make
a wrapper.

That's not a fair criticism of C#, really, because you can't
use .NET assemblies in C++ either.

What would be the equivalent of pure virtual functions

Abstract classes and methods

and multiple derivation

Multiple inheritence, you mean? There was a concious decision
not to support MI in .NET because ... well, that's a very long
debate, but it's not because they couldn't do it, it's because
they didn't want to do it and felt it was wrong to do it.

Let's turn the tables...

What if I wanted didn't want to do any of my memory management
in C++?

What if I wanted to have a comprehensive framework library with
nearly everything you could want built in and supported by
the runtime and compiler?

What if I wanted to make my code cross-platform without any
fancy magic or special #defines?

What if I wanted a pure OO language without any legacy
baggage?

-c


Great. How should I call functions in a MFC extension
library.
Such
a
library might have functions taking as parameters and/or
returning
CStrings
and CWnds. (Or for that matter a generic C++ style class.)
What
would be
the equivalent of pure virtual functions and multiple
derivation? I
am
sorry, but the jury is still out.
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
JIT applies to all .NET assemblies, not just C#. Remember,
.NET
is a system, C# is merely a language on top of it.

As far as C# being castrated, to me, it seems like has all
the
good stuff and almost none of the bad of C++. To each his
own,
I guess.

They're adding Generics in C# for .NET 2.0 which are similar
to Templates in C++.

As far as finding things C++ does better than .NET, you'll
have a hard time. In all but the most contrived
ultra-performance
scenarios, .NET has many advantages over unmanaged C/C++
code.

Check this out:
http://tinyurl.com/3890 [MSDN article]

In many cases, because IL is JIT'd, it runs faster than
equivalent unmanaged code because the JIT can better
determine
at run-time which optimizations will have the most impact.

-c

message
Would JIT apply to a local executable? I do not
anticipate
doing
any
web
stuff for a while. I am looking at doing some things that
I
think
that C++
is better equipped for than C# (which seems to be
castrated).
----------
Will Pittenger
E-Mail: mailto:[email protected]
All mail filtered by Qurb (www.qurb.com)
in
message
The C# compiler does not inline functions. However, the
.NET
runtime/JIT
is
allowed to inline functions, and often does.

--
--Grant
This posting is provided "AS IS" with no warranties, and
confers
no
rights.


message
Does C# inline functions? I do not see a inline
keyword.
Is
there an
implicit inline? Can the compiler select functions
for
auto-inlining?
I
am
more used to C++ where all these things are possible.