As long as you're starting out, you might as well get your information
straight from the horse's mouth, so to speak. There's a lot of information
scattered around on MSDN and various Microsoft blogs; one place to start
might be Herb Sutter's blog and his "A Design Rationale for C++/CLI" at
http://pluralsight.com/blogs/hsutter/archive/2006/02/27/19271.aspx
One of the goals for C++/CLI is to make it a first-class .NET language; the
Managed Extensions for C++ never felt right when compared to C#. With
C++/CLI, one primary motivation for using C# over C++ is that you get a
simpler and "cleaner" language: both C++ and VB.NET have some legacy
constructs.
Dan
"Paul Richardson" wrote in message
news:5149794@discussion.autodesk.com...
Dan,
Would you happen to have a sample class using C++/CLI? Been using
C# but like C++ better; glutton for punishment I guess, or I want to
justify the 70 bucks I spent on "Pro Visual C++/CLI" ...:)
Thank you,
Paul
--
gl - Paul
"J. Daniel Smith" wrote in message
news:5149527@discussion.autodesk.com...
In general, there is not a huge difference between ObjectARX and the .NET
wrapper classes; the most obvious exception is that custom objects must be
created with native C++.
Note that with C++/CLI in Visual Studio 2005, you can easily do .NET stuff
from C++; there is no "C++ vs. .NET".
Dan
"James Maeding" wrote in message
news:5149382@discussion.autodesk.com...
Hey wait, Chad wrote ODCL in C++ (I am guessing), so it sounds like you
could make it work.
Any comments on how he made the dialogs run lisp functions, then get focus
back?
In other words, is there a huge difference in c++ verses .net abilities?
Do you think the .ent will ever be able to do something like ODCL?
Tony Tanzillo
|>No, No, and No.
|>
|>To use .NET you need to use a .NET language, not LISP.
|>
|>The managed wrappers for .NET provide the same level of
|>extensibility and interoperability that native C++ based
|>ObjectARX offers to LISP, namely the ability to call .NET
|>code from LISP (externally defined functions), and for
|>those functions to return results from .NET to calling LISP
|>code. IOW, nothing related to user interface development.
|>
|>Many aspects of .NET user interface code are encapsulated
|>as .NET objects, which LISP has no concept of, so there is
|>no easy way to weave them together.
|>
|>While its possible to use .NET to develop 'front ends' for
|>LISP based applications, there would need to be a clean
|>separation between the two, with the LISP side having no
|>role or interaction with the .NET user interface side.
|>
|>So, you would need to develop the user interface in .NET,
|>using a .NET langauge; call that from LISP; and it can
|>return data to the calling LISP, which it would use to do
|>the work.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com