|
I said definitely not, but I meant I may well one way, but not by choice. I am always wary of change for it's own sake, change to something that sounds dodgy to me, change to something that is unproven. If we are to assume that everything Microsoft touches turns to gold, could I have a show of hands for all those people using BOB ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
or MSN (as it originally was supposed to be)...
I agree with you that one can't just look at MS as a god handing out gifts, but what I do ask is that you look at how much plaque has built up on programming Windows with C++.
It hurts. It hurts bad. I love Windows programming with C++, I love COM but it is just too top heavy (check out Comet for a good implementation of COM in C++). Dot net seems to be addressing these issues these difficult issues.
To me what is on the plate is a lot of value add.
Have fun,
Paul Westcott.
|
|
|
|
|
OK, this is obviously your POV. In what way do you propose that .Net is improving Windows programming ? Speed, or ease of use ? Because I work on a 3D visualisation tool, and a 2D paint program. How will .Net help me to do these things better and faster ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Obvious ease of use.
3D visualization? A 3D library should get stuff done in hardware, so you shouldn't be accessing it directly. 2D paint program? I would say math library routines should be quicker than any code that you could write, because (such as the intel one) are written to be processor specific. These libraries will be accessable from dot net as they are in c++.
Most stuff has been done before, it hurts, I know, I like getting my fingers dirty, but ease of programming, and speed of development, are market factors. I believe (yes, only believe, I could never say "know") that dot net is giving you these. It looks like it cleans up a lot of the grunt work, which in turn allows you to express more complex ideas - there is no sacrific, there is just a paradigm shift that must go on in ones head as to what is "fun".
When I first did a project with Java Swing classes, it was a dream compared to MFC. Even though I was new to it, I preformed at least to the performance level of a GUI product with MFC, and I believe that this would have improved with more familiarity with the product. As dot net has ripped off the Java stuff, I assume that this stuff will be there. Just an example of what can be done to speed the software development process - scrape that plaque away!
Have fun,
Paul Westcott.
|
|
|
|
|
Yes, but keeping track of items being drawn, what to render, changes to items, etc. is going to be done on the fly by our code. Is this going to happen faster through the CLR ?
Processor specific math routines ? So it morphs to benefit Intel or AMD ?
I am glad we agree .Net is ripping off Java.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Obviously you wouldn't want Intel's library to be processing for AMD chips! I was just bring it up as an example, as I know intel had a maths library with fourier transforms and sorts of shite that upon loading would choose which dll to use and then use those entry points (no magic morphing!) [such as COM using different objects which have the same interfaces, although the Intel library didn't use COM. I don't know if it still exists, etc. I'm just using it as an example!!]
Keeping track of items to render? Probably not, but is it the bottleneck in your code ? (maybe it is, I don't know)
Have fun,
Paul Westcott.
|
|
|
|
|
A 3D library should get stuff done in hardware, so you shouldn't be accessing it directly.
A 3D visualization library must do a lot of processor-intensive stuff before the data is in a form to send to accelerated (e.g., OpenGL) hardware. Look at The Visualization Toolkit. This is a library for 3D visualization that takes good advantage of accelerated hardware, but still runs about 25 MB of executables (almost 900,000 lines of C++) all to prepare the data for the hardware.
VTK is a cross-platform library developed by General Electric and used extensively for medical imaging as well as data visualization in computational fluid dynamics, earth science, etc. The importance of cross-platform work (there's a lot of work going into parallelizing vtk to run on Beowulf clusters) means that .NET would not be interesting to its developers until there is a .NET for UNIX, but an interesting kind of question that someone like me (I'm not on the vtk team, but handle similar kinds of problems) would ask is "How do I factor a new project of this sort into parts that are well-suited for .NET and which require C++? How hard is it to write a .NET wrapper to interface with my hard-core C and C++ code? How do I make a .NET application friendly for UNIX clients?
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
|
|
|
|
|
fairy snuff.
And the answer probably is that dot net is not for this kind of thing. But doing this type of stuff is a small part of the whole market I would think, not the large part (now 51.39%) who sail "definety not".
Really hard core stuff maybe shouldn't even be using c++ though should they?
Have fun,
Paul Westcott.
|
|
|
|
|
Really hard core stuff maybe shouldn't even be using c++ though should they?
Good C++ is as efficient at runtime as anything other than hand-tuned assembler, and it's much easier to design and maintain. 3D data visualization is a great place for C++ and OO design, since you can think of a visualization process as a pipeline with polymorphous fittings. C++ allows you to easily mix and match pipes and adapters at runtime without any great performance hit.
The interesting question becomes how you take this hard-core stuff, which is definitely not appropriate for .NET, and then interface it efficiently to .NET front-ends. After all, even if .NET were an appropriate technology with respect to performance questions, no sane person would port almost a million lines of C++ to C#. Is there any source of informantion and advice on refactoring existing applications to integrate them with .NET?
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
|
|
|
|
|
I have yet to interface to prior code, but there are two mechanisms that I know of.
The first is P/Invoke (of which Don Box wrote "P/Invoke works similarly to J/Direct from the old MSJVM. Very simple to use, yet fairly flexible and extensible.") which is for invoking exisitng Win32 functions, but I assume that it is for accessing any dll functions (but I could be wrong).
The second is COM Interoperability which treats COM objects as if the were dot net objects.
I agree that you probably don't want to port a million lines of code, and that is why these backward compatibility mechanisms do exists. If I find some information on the web of the methods listed I will post the address.
Have fun,
Paul Westcott.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
