in terms of quantity of coding, your program can be done easily with Gdi+ which resides on System.Drawing and System.Drawing2D namespaces in the .NET framework.
About the speed, I don't know if GDI+ is faster than the old GDI.
Printable View
in terms of quantity of coding, your program can be done easily with Gdi+ which resides on System.Drawing and System.Drawing2D namespaces in the .NET framework.
About the speed, I don't know if GDI+ is faster than the old GDI.
How would you use Managed C++ with a Win32API project (using only Managed code (or is it not possible to build Win32API app using only Managed code?))?
i.e.
How would you define the WindowProc?
Would it be the same, except in the message handlers you would convert LPARAM/WPARAM to Managed objects?
Anyone have skeleton code for a basic Win32API application using only Managed code for example?
hi all,
I have read this discussion after about six pages where filled,
oh my eyes went bad.....................
But what made me mad is that you all talking about API's in longhorn and now one have talked or came near the WinFX which is the new API for longhorn.(by the way, it's not all of it .NET).
http://www.c-sharpcorner.com/Longhor...onghornFAQ.asp
please see this link and read what is in it??
by the way, I don't like .NET either. I think it doesn't do anything better than slowing the performance of the computer programs.
There is someone who said that Assembly is history, I don't think so. and I don't do so either. Actually I'm an assembly programmer.
Assembly makes me feel better. It makes me have the control on everything (sorry out of the topic).
Regards,
Amrsfmt
I read parts of the article quickly but it needs more attention..
did you note that when it talks about backward compatibility, it means backward compatibility with .net programs not the win32 APIs !!!
Quote:
However, Longhorn supports backward compatibility, which means you can still use .NET Framework class library to write an application and run it on Longhorn.
Thanks for the link. Interesting stuff. One thing though, the description seems to be more for C# programmers which allready uses .NET technonlogy, so the changes may not be that big for C# programmers as it might be for VC++ programmers. I would like to see a description intended for VC++ programmers.
I'm glad I'm not the only one who's noticed. After all, it seems that with every new line of processors that become available, we end up slowing them right down with a "new and improved" OS. The more this trend continues, the less attention programmers give to optimization. It's like "who cares since everybody has a fast machine". It just leads to ever more sloppy code.Quote:
Originally Posted by amrsfmt
While nothing lasts forever, it would be nice to actually get a new product out of the box before it becomes unusable.
For me, Linux is looking better all the time, though it would be nice to see some lesser known operating systems get the attention they deserve. We can't (and shouldn't try) to unify the entire world on one platform or standard. Diversity is essential for the long run. It's how we find better solutions, but man has always been short sighted in many respects. Innovation doesn't come from those who blindly follow someone else. No single programming language is "the way to go".
It really is amazing how with all this, we're still stuck with a crippled hardware standard (16 hardware IRQ's for example). Just how do we always end up using the worst hardware and software combination, and then keep piling on new layers of patches and workarounds?
OK...I better stop this rant or I'll...
Not true. Eiffel has garbage collection but compiles down to C. Therefore performance is comparable. In fact there is a case study where a bunch of C developers said the same as you but went ahead and rewrote their existing C application in Eiffel and found that it was 10 times faster.Quote:
Originally Posted by Latem
It is possible that garbage collection does not slow down the execution (or just a little), with good garbage collection algorithms, but it is not possible to multiply by a factor 10 the speed. I think these C developers are really very bad programmers :p who uses many many memory copy operations, instead of using pointers.Quote:
Originally Posted by Kevin McFarlane
Of, course there is many case where a reference counter is really needed, and it is easy to implement in C++. And reference counting is as fast as garbage collection, and generally even faster.
A real problem with garbage collection, is the long interruptions it produces.
For example imagine a video game with 90fps, but which as interruptions of 0.1 second every second.
The same video game with only 80fps is really better, but no interruptions.
But, i think that longhorn kernel is not managed, and there will be at least good old memory allocations functions like VirtualAlloc.
Or, longhorn will sign the death of microsoft.
The garbage collection is not that matters. But the Intermediate code.Quote:
Originally Posted by Kevin McFarlane
By examining the steps for executing the intermediate code itself we can find it requires more time. I think this is a contradiction to time and space complexity.
There may be cases which some portion of the intermediate code may be faster than the C code but not the entire application.
To allocate using new without deallocating with delete looks like bad coding to me. I dont care if your using garbage collection, my spider senses are tingling when I do it.
What about malloc and free? Same deal?
ahoodin
Must be.
I still dont like it.
This is a quote from an Eiffel case study:Quote:
Originally Posted by SuperKoko
"AXA Rosenberg started to move from its legacy software to Eiffel by building its new software applications in Eiffel, a purely object-oriented programming language. As a proof of concept, AXA Rosenberg’s first Eiffel application permitted the company to access fundamental data much more quickly than with its legacy software. Initially, AXA Rosenberg software developers questioned Eiffel’s ability to perform as fast as C, because of the tradeoff between garbage-collection and speed. Eiffel proved to be not only 10 times faster than C, but also prevented memory leaks – a classic problem in C and C++ programming."
http://www.eiffel.com/executives/cas...xa/study1.html
Probably the speed gain came about by the more efficient OO redesign with genericity and multiple inheritance. I've come across cases where the same applies to C#, i.e., re-implement in C# and get better performance.
I think exactly what you think!Quote:
Originally Posted by ahoodin
It hurts the heart!
But, i can add something.
Garbage collection can automate memory managment.
But memory is only a particular resource.
Files, mutexes, and all kernel resources, and shared 'user32.dll' resources, need to be manually created/deleted, or can be automatically by a garbage collector that has been specifically programmed for these resources.
So with garbage collecting, you are not FREE (like java programmers), you depend on what has been implemented by the garbage collector conceptors.
Okay, i lied, this problem can be solved by adding the possibility to write destructors for a class.
But, i maintain that files must be explicitly closed.
Imagine you open a file, write in it, and that the file is closed ten seconds after, because there was no garbage collection between.
Moreover, if you open a file for write, without write sharing, and that you close it, and reopen it just after, it will make an error, because the first handle has not already been released.
This problem can be solved by garbage collecting file handles and retrying, if a file open function fails, but it is ugly, and it does not let the programmer FREE.
So, garbage collecting can only solve the problem of memory management, only memory.
I would echo the sentiment about freedom.
Furthermore, this "garbage collection" sounds like a license for programmers to be even more sloppy, and turn out even more poorly written code. After all, it would be all the less likely for you to notice your own mistakes. It is a known fact that the quality of software in general has declined significantly over the years. This whole .net thing will not help that, only encourage it, and cover it up.
If I write bad code, I want to know about it. I want to see an error or a crash when I make a booboo. I want to see resource depletion if I forgot to clear something. If the program keeps going as if there isn't anything I should or should not have done, I'll be less inclined to make improvements or find ways to optimize the performance. I cannot tell you how many times I think I have something working perfectly well, only to find out that certain operating systems or configurations exhibit a problem. We all know how it goes: "This can't be happening. My code is fine...". Then after much frustration, we find that little thing which fixes the problem. We find a better way to do whatever it was we were doing.
What we don't need is yet another layer between the program and the system. Performance has decreased with each new version of windows. New versions of programs often do the same - hogging more memory, slowing things down, etc.. This drives the consumer to want faster CPU speeds, more memory, and so forth. Then programmers take even more liberties, thinking "Heck, everyone has resources to spare...". It's a vicious, never ending cycle.
Sure, we all want better performance from our systems. However, these days the slowdowns are not so much due to a lack in the hardware, but the software. This "managed code" stuff will only exacerbate the problem.
I believe programmers need to take more responsibility for their code, not less. I get the impression that m$ is doing with programmers what they have done with the consumers: Make them stupid. Keep them stupid. Control everything. Hide things from them. Just look at how a simple thing like hiding file extensions has worsened the problem of viruses. The consumer is not encouraged to know what the extensions are, or what they mean. "Don't think. Just click here". It puts computers into the hands of even more inept consumers, and causing nightmares for system admins and maintenance/repair personnel. It seems .net will do this with programmers to some extent. It's a defense mechanism which gives rise to even more of the problem it aims to solve - Bad Coding Practices.
Quote:
Originally Posted by WizBang
bad programmers will be bad programmers.
not beacuse you use a managed language means you wont know what you are doing. You can go and learn how to use it, and improve it. If you dont have the curiosity to learn more, it will be the same if you use c#, c/c++ , java, pascal...etc. You may do the things, but you wont know what is really happenning.
I like more "normal" c/c++, but i accept that .NET is the future......at least, if what it seems to be..
learning c# and .net wont hurt you.......
True to an extent, but .net will make more of them, thus more bad programs.Quote:
Originally Posted by BlackWindzx
It's not what it seems on the surface. You have to dig past the hype to see what awaits. There is a lot planned at m$ for the windows PC user, and not in the favor of the consumers or programmers. That's probably too far off topic to go into here.Quote:
Originally Posted by BlackWindzx
As for learning .net, I do think it would hurt in my case, as it simply cannot be used for commercially distributed software. That again is part of the m$ plan.
Oh, what surprizes are in store...