|
The links yields this:
Location Cannot Be Found
We apologize for the inconvenience, but the location you are seeking cannot be found. If you are looking for a particular document, please try one of the following areas:
Vaclav
|
|
|
|
|
|
Thanks
|
|
|
|
|
|
This is a good introduction but rather incomplete. I would like to see in the article more details on about mixing GDI and GDI+ calls in the same drawing routine like getting a Graphics object from a CDC* and things like that!
|
|
|
|
|
Why are 99.9% of GDI+ samples in .NET language?
Cause that's what MS wants you to use - Doh!
C++ is for old people, with rickety minds, C# is for young, voluptuous, nubile thinkers...
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
|
|
|
|
|
.NET is a simple language, but for larger projects it is really a pain in the a**, you need to lots of DLLs and sub-projects for each control in order to be able to handle it.
I tried a few times to make my projects using C#, but every time I messed up in the generated code.
|
|
|
|
|
Mario M. wrote:
.NET is a simple language
.NET is not a language.
And C# version 2.0 will be much richer than C++.
Mario M. wrote:
but for larger projects it is really a pain in the a**, you need to lots of DLLs and sub-projects for each control in order to be able to handle it.
For each control? Could you give an example? I rarely have to deal with references, unless they're to assemblies in my own project. I've never had a problem with this.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
I meant for each custom control, anyway C# is full of bugs, and it is much slower than C++, even on Pocket PC, a C++ application requires 20KB of memory and a C# when it loads the .NET Framework runtime uses 3MB of memory !!
C++ is the father of C#, so C# will never be better.
|
|
|
|
|
Mario M. wrote:
I meant for each custom control
OK.
Mario M. wrote:
anyway C# is full of bugs
Umm, are you refering to the specification, Microsoft's implementation, or .NET?
Mario M. wrote:
and it is much slower than C++,
Yes, the JIT compiler causes an app to run slower initially and the larger footprint takes longer to load.
Mario M. wrote:
even on Pocket PC
Good heavens! I don't think I would code in C# on a Pocket PC. I would agree--it's not a language to use when performance and memory utilization are a priority.
Mario M. wrote:
C++ is the father of C#, so C# will never be better.
Ummm, do you use the same rationale with children? Are all other airplanes inferior to the Wright brothers', because it's the father of all airplanes? Is the Pentium inferior to Intel's 4004 microprocessor because the 4004 is the father of all microprocessors? Is aerobic life inferior to anaerobic life?
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
the .NET framework is full of bugs (not the C# compiler), especially the .NET Compact Framework.
besides you always need to carry the latest .NET Framework redistributable with your application which is more than twenty megabytes
So do you agree with me that in almost any case C# has downs compared to C++, then I don't understand why you still calim that C# it's better than C++.
If you wrote small applications, in which speed and size are not relevant, C# is good, but for larger applications where performance, portability and memory usage is important, you end up with C++.
|
|
|
|
|
Mario M. wrote:
So do you agree with me that in almost any case C# has downs compared to C++, then I don't understand why you still calim that C# it's better than C++.
I think both have their applications. The concept of the CLR is beautiful and the reflection capability of C# is fantastic. Personally, after coding in C++ 15 years, I find C#, as a language, to be better. Although it really needs the features coming out in version 2, like templates.
I never claimed C# was better than C++ (or at least, I don't think I did). I disagree with most of the posts made in this article--I think people are being naive and close minded, much to their own loss. Reminds me of how I was with my negative attitude toward Java years ago, and I regret it now, as I struggle to learn JavaScript in an ASP.NET development effort.
Mario M. wrote:
If you wrote small applications, in which speed and size are not relevant, C# is good, but for larger applications where performance, portability and memory usage is important, you end up with C++.
I'm not sure I would agree with that. I'm in the process of writing some very large applications in C# and have no problems, both ASP.NET and client based. Webservices, XML parsing, database support, reflection, delegates, events, etc., make my job as a programmer much easier. On the user's side (again, barring CF development), I haven't noticed any performance differences except for load times and JIT compiler hits. My clients don't seem to mind. What they do see is some nifty functionality that they really like. And what they also like is that I can implement these features at a lower cost to them. The tradeoffs are more complex than "does the program run faster".
I'm writing several applications for my clients, and they use a mix of C++ and C#. They involve network traffic monitoring, facilities management, satellite design engineering and analysis tools, and mundane things like inventory management. I use the appropriate tool for the job.
TO say something is bad just because its new and has problems and is slower or less efficient is rather limiting, in my mind. The Wright brother's airplane flew only a few feet the first time. Does that mean that the concept of air travel was bad? The same thing goes for C#. From what I've seen, it's a really good attempt at fixing problems with C++. I'm not one of those "pointers are bad" people--that's silly. There are other problems with C++ that C# handles much more gracefully--simply that all types are derived from "object" is a major improvement.
The .NET framework is, in many ways, an abortion, just like MFC is/was. There's inconsistent naming conventions, some really useful classes are sealed, there's bugs (even in the non-CF version), there's big gaps of missing functionality and kludgy stupid ways of doing things. For all that, there's also some really great things about it. That's life, and it's not something that Microsoft has a monopoly on (for once).
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Hi Mario, here's a link worth reading C++ Gem. Strongly suggest don't continue with someone like Marc Clifton, these are Microsoft diehard who "program" with eyes closed, not interested in solving program but using .nut framework.
Happy reading!
|
|
|
|
|
Writting applications in C# is making me depend even more on Microsoft, and using C# will make microsoft bigger and our small software companies even smaller.
When C# was out, I was happy that I will write apps more faster, so I started writting a new database application in C#, after struggling 2 months to make it look different than MS wants to look an application, I used threads to access / process database through an SQL server, and finished with an application which is damn slow and full of bugs. This does not happen in C++, where I'm in full control of everything. C#/.NET Framework is like an automatic pilot for cars.
I think that you work for microsoft, or else I don't see why you offer so much support to C#
I am waiting for .NET v2.0, but I think this also is just a big advertising of MS, like for the first version, and the end result will be another buggy incomplete/library
|
|
|
|
|
|
It's the difference between real programming (C++) and configuring Microsofts programs for your own purposes (c#). It's really bad, if the young people are too lacy to learn programming, and let do all really work a few people at MS.
|
|
|
|
|
Dieter Hammer wrote:
It's the difference between real programming (C++) and configuring Microsofts programs for your own purposes (c#).
That's real interesting opinion. How do you justify it? C# is, after all, an independent language supported on multiple platforms. C# is standardized by ECMA International (ECMA-334) and by ISO/IEC (ISO/IEC 23270).
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Oh reallhy? Tell us which platform beside Microsoft dump $ has the support of C#?? What have ECMA done so far?? Why not people use JAVA since it is already there and yet support on more platforms like AIX? Do you know C/C++ is already portable?
As usual, you talk with eyes closed. You can go on doing C#, no one stop you, you should live up to your big mouth, don't use C/C++, don't use design pattern.
|
|
|
|
|
|
Just remember to live up to you mouth not use C/C++ and design pattern in your MICROSOFT project. Otherwise, you are...
|
|
|
|
|
TW wrote:
Just remember to live up to you mouth not use C/C++ and design pattern
Design patterns are language independent. You can use design patterns in GW-BASIC if you tried hard enough.
Look, you're new around here. You posted an OK article, ignoring the formatting guidelines, didn't spell check or grammar check your article, and you've posted some rather rude messages. Learn the ropes and show some respect.
If you want to keep butting heads with me, be my guest. I enjoy the entertainment.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Who just said "obsolute"?? Read your own posting to see your own bull5h*t. Remember to live up to your big mouth not to use C/C++ and design pattern, else you are just another...
|
|
|
|
|
TW wrote:
not to use C/C++ and design pattern,
In your vast knowledge, how is C/C++ coupled with design patterns? What do you think design patterns are?
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Read the link instead of saying "Oh, obsolute material.". So stupid! I don't have time response you, take it or leave. F**k off and continue your C#.
Here's the link for anyone who is interested in true C/C++, please don't waste time reading Marc Clifton's message nor reply him. There are many resources on sourceforge.net too. Happy reading!
|
|
|
|
|
You didn't answer my question. I want to know why YOU think C/C++ is coupled with design patterns. I want to know what YOU think design patterns are.
The article is 6 years old. In this rapidly moving industry, that makes it obsolete.
Modularity -- Frameworks enhance modularity by encapsulating volatile implementation details behind stable interfaces. Framework modularity helps improve software quality by localizing the impact of design and implementation changes. This localization reduces the effort required to understand and maintain existing software.
Really. Show me one that actually does this. MFC and .NET certainly don't. I know of only one framework that meets these goals.
Reusability -- The stable interfaces provided by frameworks enhance reusability by defining generic components that can be reapplied to create new applications. Framework reusability leverages the domain knowledge and prior effort of experienced developers in order to avoid re-creating and re-validating common solutions to recurring application requirements and software design challenges. Reuse of framework components can yield substantial improvements in programmer productivity, as well as enhance the quality, performance, reliability and interoperability of software.
That is so naive it is laughable. A framework does not make a component generic. A component is generic because it is well designed, regardless of the framework. Most developers, after reviewing their prior effort, realize that things could have been done a lot better, and throw out all but very basic functions. So much for your idea of a reusable framework.
In your article, you say that you're primarily an SDK programmer. Is there some particular reason you don't want to leverage the MFC framework to gain substantial improvements in programmer productivity, as well as enhance the quality, performance, reliability and interoperability of software??? ROTFLMAO!
Extensibility -- A framework enhances extensibility by providing explicit hook methods [Pree:94] that allow applications to extend its stable interfaces. Hook methods systematically decouple the stable interfaces and behaviors of an application domain from the variations required by instantiations of an application in a particular context. Framework extensibility is essential to ensure timely customization of new application services and features.
Really? I've seen a lot of frameworks that don't do this. I love the last sentence. You know what you end up with? A framework that is completely defeated with customized hooks.
Inversion of control -- The run-time architecture of a framework is characterized by an ``inversion of control.'' This architecture enables canonical application processing steps to be customized by event handler objects that are invoked via the framework's reactive dispatching mechanism. When events occur, the framework's dispatcher reacts by invoking hook methods on pre-registered handler objects, which perform application-specific processing on the events. Inversion of control allows the framework (rather than each application) to determine which set of application-specific methods to invoke in response to external events (such as window messages arriving from end-users or packets arriving on communication ports).
Oh, thrilling. So what this means is that your workflow (canonical application processing steps) are scattered throughout your application-specific processing in the form of custom messaging and event handlers. MMmm. That sounds real easy to maintain.
It's a good article. I'm sure it fools many people. It's obsolete. Yet another article produced by academia that 1) has no bearing on reality, 2) speaks of lofty goals without providing any clues as to how to go about achieving them. Design patterns? That's only the tip of the iceberg.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|