Printable View
I have been going over some C# documentation all day as well as MS code examples and it looks very interesting.
Why do you guys prefer to use C#? What are it's advantages and most importantly, it's disadvantages? It seems like it is worth giving a try.
I prefer sometimes.. as that is the only programming language that MS gave for getting things done well without much effort & also multiplatform (to some extent) like java..
VB was there.. but I dont like it, I am afraid that I will become a scrip coder throughout my life :D
Most important reason.. is my friends only know C# and not C/C++..
they find C/C++ coding as stupidity.. doing a lot of things for one simple code..
C# is good for getting GUI apps up and running fast and yet still use an object oriented language...unlike VB. C++ was not built for Windows GUI and MFC while very handy is also very picky about how you design your apps. It takes quite a bit of MFC 'under-the-hood' knowledge to really get creative and break out of the mold. C# does not require this and thus development time is significantly shortened.
However I don't like C# because interop is a pain (with unmanaged code) and the fact that there are no pointers essentially makes everything a pointer underneath it all. .NET is sorta crazy with all the System.Windows.Forms.yada.yada.yada stuff but it gets the job done.
I do like the ArrayLists and other containers that can contain any object. This is a great idea but can also be done in C++ - with a bit more code.
Main reason for using C# - development time.
That is interop?Quote:
Originally Posted by Bubba
So is C# as powerful as C or C++? I've read that you CAN use pointers with C#.
Quote:
Originally Posted by gibsosmat
What do you mean a scrip coder for life?
Also, how portable is a C# program?
You can use pointers, but they're "unsafe" and has restrictions in the langauge last I remember.
Good luck getting anything built on .NET to run on anything but Windows. At least so far.
The core of the C# language is standardized, and there are two alternative implementations available. (By the Mono project and by Gnu). However, only a tiny part of the .Net framework has the same honour, so these two projects spend a lot of time trying to get a compatible implementation from just reading documentation and making test cases. The result is that the .Net framework is only partially implemented, making most C# programs unportable.
Practically, the design of System.Windows.Forms is so tightly coupled to the Win32 windowing model that Mono has given up on trying to implement it on top of typical Unix toolkits, and now base it on Wine.
Is C# as powerful as C or C++? That depends on how you define power. In computer theory, all three languages are Turing-complete, and thus can solve any known numeric problem, if given infinite resources. In reality, there are some things you can do in C - like writing device drivers - that the implementation model of C# makes impossible (no .Net runtime in the kernel) and that of C++ makes hard (no exception handling and dynamic initialization in the kernel). On the other hand, C# generally allows you to do more with fewer lines. That is a sort of power, too.
that was a typo.. :D it should be script coderQuote:
Originally Posted by Welder
If one gets used to scripting language they get those language habits..
both in coding style & realization methodology..
with windows having .NET they will work fine.. since it has runtime it will depend on the runtime.. I dont know how portable is .NET runtime, on different systems. I never tried.Quote:
Originally Posted by Welder
computer science power is different, it has a proper definition..Quote:
Originally Posted by Welder
putting it simple
'if one thing can be done in a language and the same could be done in another language they are said to be equally powerful'
development time & running time are not a constraint here.. but if it can be done at all or not is the only thing considered..
yes, you can use pointers.. but the compiler keeps yelling,
as that will force runtime not to assume things for granted for optimization and garbage collection
I feel like its the only reason to choose C#.. rest all are available in C++ .NETQuote:
Originally Posted by Bubba
so what now? will MS help project wine? :confused:Quote:
Originally Posted by CornedBee
Unlikely. As far as I know, MS only supports the Moonlight effort, and Forms is not part of Silverlight.
I didnt understand..Quote:
Originally Posted by CornedBee
You can use pointers in C# but they are used in 'unsafe' sections of C# code. Also I'm not sure you can use an unmanaged type inside of a managed block of code. As well there is the issue that C# objects move around in memory at run-time so to use unsafe objects you pretty much have to use gcroot<> which tells the C# memory manager to lock the location and don't move it AFAIK. If C# went ahead and moved your unsafe pointer or object the next time you try to use it or access it you would have a very bad experience.
Interop is using modules/objects from dissimilar languages and/or .NET or non .NET modules/classes.Quote:
That is interop?
For instance you cannot just export a C++ class into a DLL and then import that DLL into C#. There isn't a :: scope resolution operator in C# so if you have 2 or more classes with the same function names but inside of different objects there is no way for the compiler to do function resolution. Also C++ class functions are called with this call and C# does not understand this call. I did see a blurb on the internet about specifying this call instead of std_call when you import the DLL but I never tried it so I don't know if it works.
The biggest issue comes when you attempt to interop unmanaged code with managed code and since C# is managed, mixing it with non .NET C++ can be quite troublesome. I would venture to say that C# is most likely not very portable at this time but may be so in the future.
As with all languages other companies have gotten into the mix and now offer C# compilers. I'm not sure about the legality of all of that but it's good for cross-platform folks.
I just started learning C# last week so I'm fairly new to the scene but since my first project at work is C#...I pretty much have to crash course learn it.
Development time, but also clarity of code. C# code tends to be more compact than its equivalent C++ code, and one feature of this clarity is that maintenance of the code becomes easier. A program spends the vast majority of its life in the maintenance phase, not the development phase, so gains here matter most.Quote:
Originally Posted by gibsosmat
Oh, and on the original topic, what I dislike most about C# -- lack of const member functions and const-correct coding. Granted I think about 1% of all the C++ code I've ever seen actually uses const correctness, but it's a powerful tool and one I feel C# lacks.
More compact? More bloated if you count the .NET runtime.
Cannot agree on maintence - that's something that depends on how well written the code is an the experience of the developer. It really has no effect on what language you use.
The code is more compact. Not the compiled executable, just the code.
It's way easier to maintain for inexperienced programmers.
It's easier to learn.
It has garbage collection.
GUI creation C# vs C++ isn't even comparable. I love C++, but anything that will go to a customer for daily use is better built in C#. Because there is no way to tell a customer that his wishes, how crazy they may be, cannot be fulfilled. C# is "can do", C++ is "can do for an enormous amount of money to finance our enormous amount of development time" when it comes to GUI creation. And by GUI creation I don't mean two buttons and a textbox.
I miss const-correctness though.
Uhuh, but so what does this do, exactly? A little less code, yet bigger executables?Quote:
Originally Posted by nvoigt
Yes! For inexperienced devs, but not for experienced ones!Quote:
It's way easier to maintain for inexperienced programmers.
It's easier to learn.
It has garbage collection.
I can maintain a C++ program just as well as a C#. We can divide them into categories - for inexperienced and experienced.
It certainly is harder to do GUI in C++, but with all those libraries out there, it's DO-able. One just needs to know how.Quote:
GUI creation C# vs C++ isn't even comparable. I love C++, but anything that will go to a customer for daily use is better built in C#. Because there is no way to tell a customer that his wishes, how crazy they may be, cannot be fulfilled. C# is "can do", C++ is "can do for an enormous amount of money to finance our enormous amount of development time" when it comes to GUI creation. And by GUI creation I don't mean two buttons and a textbox.
I miss const-correctness though.
C# is easier to use, but I cannot agree that it's easier to maintain. Plus it creates bigger executables and it's easier to reverse engineer.
But there's also the speed question. If something takes 5s to do, just like clicking a button, then I'd find that program very bloated and unfun to use. And this might just be the example of C# and .NET. It takes such a big performance hit to use it. Heck, I believe even VB apps start and execute faster (well, they are native, after all).
It would be nice for a mix of C++ and C#, with C++'s power and C#'s easy GUI, but I guess we can't have all...
Exactly. Less code means easier maintenance.Quote:
Originally Posted by Elysia
Exactly. And if I need an experienced coder for C++ and a slightly less experienced for C#, it means that C# is cheaper to use.Quote:
Yes! For inexperienced devs, but not for experienced ones!
Same thing here. Yes, it's doable. With a considerably amount of experience, time and a third party library that probably comes with costs of it's own, licensing, knowledge needed or whatever else. If you have a customer demand the the first row of the list be a special kind of green if it's wednesday, then that's a no-brainer in C#. You will need a third party library or a ton of custom code in C++.Quote:
It certainly is harder to do GUI in C++, but with all those libraries out there, it's DO-able. One just needs to know how.
Both is totally irrelevant to my field of work. I'm neither short on disc space nor will anyone outside of the company get access to my executable. May differ for you. Obviously different environments need different tools.Quote:
Plus it creates bigger executables and it's easier to reverse engineer.
So do I. But that's a crappy program and I can guarantee that the same program will take maybe 4.8s in pure Assembly. Bad programming is bad programming. .NET programs, like Java programs, only take longer to load because they are compiled at runtime. Startup time to me (and my customers) is irrelevant, remember I'm not talking two buttons and a textbox here, the programs are started once and then used for the remainder of the day. Even client validation against the database and database login will take longer than startup. If the application does a lot of stuff, time for startup becomes irrelevant. Again, this may differ for you. Different environments, different tools, yada yada yada.Quote:
But there's also the speed question. If something takes 5s to do, just like clicking a button, then I'd find that program very bloated and unfun to use.
While running, no GUI in any language will take any amount of time that is noticable to the user. If it does, it's either real processing that has nothing to do with the GUI, or it's simply ........ty programming.
I love C++ and it's power just like I love a car that has some more raw power than I'd ever need. But if it comes to getting a job done fast and efficient, I'd rather take the tool that fits best. Which right now for me is C#.
So were we discussing C# vs C++ or C# maintence easier than C++ (in general)? ;)
Also, for the less codebase... C or C++ has probably THE largest anount of code out there for you to grab, tested and optimized, making less work for you. Yes, you may have to search, but it makes less code to maintain, just like the .NET Framework.
Ah, another C++ Vs. C#.
Well this link should solve this!
C++ Vs. C# Article! In the end does it really even matter?
That's what I've been trying to tell... does it matter what language you use? In the end, the result is the same.
(Except I won't lay my hands on C#. I hate C# and the .NET framework with a passion, but that's just me.)
Thats just plain stupid, I dont know at which stage you are in life. But with a mindset like this you will bump into alot of walls!Quote:
Originally Posted by Elysia
Stupid it may be, but it's my choice. I dislike C# and everything .NET.
Also, I don't like Microsoft, but that's not why I dislike C#. I don't like the syntax (^ for pointers?! Are you kidding me?!), but I don't like the overall language as well. It goes against the principles of C++ - less control and safer. I like to be in control of what I can do and mess around at a level that just can't be done in C#.
In C++, I can mess around with memory, swap, manipulate and so on, but I can't in C#. And that's why I dislike C# and .NET.
And yes, I have used both. C# was a good mixture when it was 1.0, when you could easily mix C++/.NET, but since 2.0 it's just gotten crappier and crappier.
To keep a job, a programmer has to mostly do what he/she is told to do. That doesn't mean we have to like it, and it doesn't mean we should shut up about the potential drawbacks. In some cases, using the wrong tool borders on unethical -- would civil engineers build a bridge out of plastic just because some suit told them to do it that way?Quote:
Originally Posted by GanglyLamb
The problem with C# is that it is a proprietary framework, and the further it penetrates into everything the more reliant the entire world becomes on Microsoft. This is not an anti-Microsoft position, it is a realistic engineering position. You simply don't build important things out of components that you have zero control over and which can be changed by a third party at any time.
if we see an ISO standard emerge for C#/.NET and companies actually begin to pick it up and implement it, then the whole situation has changed. Until that time, using C# is just worshipping at the altar of Microsoft while digging a very deep hole for yourself.
Are you sure you are not mixing the two up here? Visual C++/CLI .NET uses ^ for pointers. There are no 'real' pointers in C#. C# is like Visual Basic with C. It really feels about the same too.Quote:
Also, I don't like Microsoft, but that's not why I dislike C#. I don't like the syntax (^ for pointers?! Are you kidding me?!),
Personally I can vouch for C# being extremely simple since I learned it in a matter of days for a project I was working on. On the third day I was already interoping unmanaged C++ and C#. The GUIs in C# are so simple but some of the more advanced topics can get hairy later down the line so it's not a complete noob language.
Development time is cut down from coding a GUI in a few months with C++ to a few weeks in C# with the same or better functionality. I like the concept of .NET although I still feel some of the controls are lacking in areas and the interop is still not as smooth as it could be. But generics in .NET 2.0 solve the nasty type issues with ArrayList and overall the programmer is presented with a fairly impressive toolbox to work with. Now for me personally I can create an MFC (non doc-view) dialog app in about the same time as a C# .NET dialog project but not everyone is at that point with MFC. The classes are not daunting to me anymore but if you remember my tons of posts about MFC in prior times you will realize it was quite a pain in the arse learning it from scratch. Learning curve in C# is next to nil but that is not to say it does not take skill to use. C# is a godsend to programmers who have to do GUIs but either cannot do pure Win32 or don't want to and also do not know MFC. So instead of using VB you can use C# and still retain some C++ flavor without all the complexity of MFC.
I would not use C# for everything but for GUIs it just cannot be beat. So to meet my project deadlines and to make those far above me happy I use C#. This is not saying I'm not a good C++ programmer it's saying I'm a smart programmer in that I use the best tool for the job at hand. Now if we were coding some uber super 3D stuff then no I would not use C#. But using C# instead of C++ for GUIs and to save development time does not make you any less of a programmer. Rather I think it means you can utilize your time and resources effectively to get the project done on time.
Since about a good 80% of your clients will have a PC with some version of Windows XP or Vista on it your statement actually works in your favor. You are guaranteed that your code will run on their machine just as it does on yours. And at work I'd say about 75% of the stuff I build with I either did not code, came from a thirdy party and/or I do not have control over. This to me is not a valid argument.Quote:
This is not an anti-Microsoft position, it is a realistic engineering position. You simply don't build important things out of components that you have zero control over and which can be changed by a third party at any time.
And just a news flash for the mainstream PC market out there....it is a Microsoft world whether we like it or not.
I love Linux as much as the next guy and all the other platforms but MS is still the dominant force. I'm not saying it's right, fair, or that we have to like it but IMO it is fact.
Simply, I don't believe you. Anyone that's used C++/CLI knows that 2.0 brought significant clarity to the language, which previously felt uncomfortably like a bunch of ill-considered language extensions. 2.0 also brought generics to both C# and C++/CLI, a needed expansion for C# and an interesting tool when combined with templates in C++/CLI. I don't know of anyone else who has worked in both and seriously thinks that 1.0 was superior in any way. I do not doubt your seriousness.Quote:
Originally Posted by Elysia
Wow, using that logic, there should be no third-party Windows applications, since no one other than Microsoft has any control over the Windows API. Programmers use components that they have zero control over all the time. Those that don't spend their time re-inventing the wheel.Quote:
Originally Posted by brewbuck
Is that all you need?Quote:
Originally Posted by brewbuck
ISO/IEC 23270:2006 - Information technology -- Programming languages -- C#
ISO/IEC 23271:2006 - Information technology -- Common Language Infrastructure (CLI) Partitions I to VI
ISO/IEC TR 23272:2006 - Information technology -- Common Language Infrastructure (CLI)
-- Technical Report on Information Derived from Partition IV XML File
ISO/IEC TR 25438:2006 - Information technology -- Common Language Infrastructure (CLI)
-- Technical Report: Common Generics
It's cute when people voice interesting and inflammatory opinions without really knowing what they're talking about. The .Net framework is simply an implementation of CLI. As you can see, ISO's for both C# and CLI already exists. Further, Microsoft is not your only option for a CLR. Novell produces the Mono framework, which implements much of Microsoft's implementation and provides additional libraries. The Mono framework has the added bonus of working under both Linux and Windows. It's not complete (if you take the position that missing anything from .Net is lacking), but if you spend your time coding to Mono instead of to .Net, then it doesn't matter.
2.0 also deprecated pointers and introduced crap syntax to C++/CLI.Quote:
Originally Posted by pianorain
In most cases, a slight difference in executable size is completely irrelevant; large applications tend to be large because of data files, not because of executables.Quote:
Originally Posted by Elysia
And less code to write is less code to maintain.
I have 16 years of C++ experience and I still think C# is easier to maintain. I can do either, but all in all I'd rather be doing C#. Obviously it's doable to maintain C++, but that doesn't make it as easy as C#, even for a professional.Quote:
Yes! For inexperienced devs, but not for experienced ones!
I can maintain a C++ program just as well as a C#. We can divide them into categories - for inexperienced and experienced.
Again, obviously it's doable. The question is whether it's worth doing; are there benefits that exceed the drawbacks? It's doable to hammer a nail with a screwdriver, but that certainly doesn't make it the best tool for the job.Quote:
It certainly is harder to do GUI in C++, but with all those libraries out there, it's DO-able. One just needs to know how.
Honestly, unless you're programming cutting-edge games, there's little you'll ever notice in speed difference. If you're actually lagging your UI, that's poor program design, not poor language choice.Quote:
But there's also the speed question. If something takes 5s to do, just like clicking a button, then I'd find that program very bloated and unfun to use. And this might just be the example of C# and .NET.
Our whole line of work is built on using stuff we have no control over. Even Open Source in the end is an illusion. You are afraid MS will pull the plug ? What happens if Linus pulls the plug ? Don't tell me you personally will code patches and future Linux versions to support your line of products. You have the source. But you still need the manpower to put it to use. And you don't have it, or you wouldn't be using somebody else's OS, but your own. With open source, you can at least hope someone else does the job, but don't tell me that is "independent". It's the same dependency on external events you have no control over.Quote:
The problem with C# is that it is a proprietary framework, and the further it penetrates into everything the more reliant the entire world becomes on Microsoft. This is not an anti-Microsoft position, it is a realistic engineering position. You simply don't build important things out of components that you have zero control over and which can be changed by a third party at any time.
As a last thought: if an application is windows-only, why would I bother with a cross platform framework? Why not use C#? Do you think the same application would be less Microsoft-centric, if I build it using MFC?
Show me a single GUI Framework for C++ that cannot be changed by a third party at any time.
The nice thing about C# is that it actually HAD a standard since day 1. C++ wasn't standardized for nineteen years, and its second major revision will be at least a decade after its first. Further, even the existing standards aren't fully implemented on modern compilers -- most compilers (even GCC) don't support the export keyword, and that's been part of the official standard for almost ten years. At least with C#, you have the standard, and you know there's at least one compiler that conforms to it exactly.Quote:
Originally Posted by brewbuck
I, too, can write some crap down, blow my nose on it and call it a "standard." The only reason Microsoft is able to get things into ISO/ECMA is through threats and blackmail.Quote:
Originally Posted by Cat
But it's not 19 years ago right now.Quote:
C++ wasn't standardized for nineteen years, and its second major revision will be at least a decade after its first.
If you can give another example that doesn't involve an obscure keyword that nobody uses then I'll concede that point.Quote:
Further, even the existing standards aren't fully implemented on modern compilers -- most compilers (even GCC) don't support the export keyword, and that's been part of the official standard for almost ten years.
One compiler on one piddly little platform. What are you going to do when a customer offers you $100k to port your application to AIX? Hell, even Java would be a better choice.Quote:
At least with C#, you have the standard, and you know there's at least one compiler that conforms to it exactly.
I suppose all the time I've spent writing code for AIX, SCO UNIX, HP-UX, Solaris, Linux, VMS, and a couple of embedded platforms has blinded me to the truth: the entire world is in fact only Microsoft.
Why would I have to patch anything? The thing works just fine.Quote:
Originally Posted by nvoigt
That's the great thing about business. You can hire people.Quote:
You have the source. But you still need the manpower to put it to use.
That's a bunch of crap and you know it. Just because you have the capability to do something doesn't make it a good idea. Do you begin each new project by writing a compiler from scratch?Quote:
And you don't have it, or you wouldn't be using somebody else's OS, but your own.
Like so many others you have taken my irritation with Microsoft and flipped it around to assume that I must be some kind of Open Source fanatic. False dichotomy.Quote:
With open source, you can at least hope someone else does the job, but don't tell me that is "independent". It's the same dependency on external events you have no control over.
The first time a customer offers you a crapload of money for a port, you will be kicking yourself.Quote:
As a last thought: if an application is windows-only, why would I bother with a cross platform framework?
What would be less Microsoft-centric would be coding to an actual standard which is accepted somewhere other than on Windows platforms.Quote:
Why not use C#? Do you think the same application would be less Microsoft-centric, if I build it using MFC?
And they force you to upgrade how?Quote:
Show me a single GUI Framework for C++ that cannot be changed by a third party at any time.
How long did it take compilers to correctly implement partial template specialization, which although a bit obscure is also a very powerful and often-necessary tool? GCC had buggy implementations (often resulting in crashes) until 3.3.1, which was five years after the standard. Much of Boost didn't even work on GCC until 3.3.x, and as far as key third-party libraries, Boost is at the top of the pack.Quote:
Originally Posted by brewbuck
There are actually several C# compilers, some which are open source and cross-platform. Not all of them implement all the proprietary portions of the .NET framework (portions of the framework are not standard C#) but some do. And that "one platform" also happens to be the platform with 90% market share in the personal computer market, so if you're targeting an application for that market, being Windows-only is no big deal at all.Quote:
One compiler on one piddly little platform. What are you going to do when a customer offers you $100k to port your application to AIX? Hell, even Java would be a better choice.
Obviously C# isn't the best tool for every job, but that doesn't mean it's never the best tool for any job. A hammer is a perfectly useful tool even if it can't drive screws; in fact you'd be foolish to spend your time driving nails with a screwdriver. Different situations are best handled in different programming languages, and C# happens to have a very nice and rather large niche for designing Windows GUI applications. Choose the tool based on the job, not based on your feelings about the tool.
I just have to add this, but though it may be foolish to only use a screwdriver instead of using a hammer when the need arises, only using a screwdriver prevents you from smacking your thumb and smashing it with the hammer :DQuote:
Originally Posted by Cat
Translation: Even I used the right tool for the job (C#), I can still get burned [Don't like how the C# is? Too bad, 'cause the hammer is the right tool for the job!] (smashing my thumb), but if I use a screwdriver (C++), I'm perfectly safe (or safer).
I don't see how this is an argument. Yeah, compiler support was iffy in the past. Choosing C++ at that time may have been unwise. Times change though.Quote:
Originally Posted by Cat
It's not my feelings about the tool. Ironically, the few times I've used C# I've felt comfortable with it. If it only had true templates, I'd probably be using it in preference to C++. It's my feelings about MICROSOFT and their DEMONSTRATED propensity for repeated, deliberate breakage of standards and deliberate incompatibility with other products which adhere to standards. This isn't blind hate -- MS has been declared, legally, in a court of law, to be in violation of various monopoly and anti-trust statutes. They show a pattern of antisocial behavior which is not going to change any time soon.Quote:
Different situations are best handled in different programming languages, and C# happens to have a very nice and rather large niche for designing Windows GUI applications. Choose the tool based on the job, not based on your feelings about the tool.
Use the right tool for the job at hand. If you want to code a GUI in C++ and that is the right tool for you then so be it. But insisting that doing it any other way than your way makes you a tool.
I choose whatever will get the project done reliably and in due course. If the team does not know MFC it's probably not a good idea to force them to use it. If the team knows MFC better than Microsoft but does not know a lick of C# then prob would go with MFC even though it would take mere days to learn C#.
C# is a godsend and now with .NET 2.0 it's even better. Generics simply put are the best thing since sliced bread and beat the crapola out of those nasty untyped everything fits inside ArrayLists. There isn't one person I know who is familiar with .NET who prefers 1.1 so saying it's crappier in 2.0 is, to me, an uneducated statement since 2.0
is better in just about every aspect.
As I see it this debate has two sides. Those who are talking about C# vs C++ and those who are talking about Microsoft vs the world. This is not a debate about languages but more a debate about Microsoft. So I say get over it, stop bashing them because nothing is perfect, and use what works. I agree that Microsoft's practices are questionable at times but I have seen a move away from some of them. Namely these are some of the good things I see
- The free release of a very good development environment. It does not do MFC but that's not because Microsoft is stingy, it's because they are trying to tell people don't use MFC and use .NET. This dev environment is not a joke and is far better than anything we actually paid for years ago. Two thumbs way up to Microsoft for releasing this express version.
- Excellent documentation and help system with all of their products and their website has tons of free information, examples, and so forth.
- Ongoing support for deprecated OS's. Even though Microsoft has released Vista they are well aware that most of the world for now is going to stick with XP. They realized this as well when they released XP and supported 98SE for quite some time thereafter. This ongoing support approach allows me the user to choose when I want to upgrade. I think they are trying to step away from the upgrade or else approach and they are doing well.
- Continual fixes for Microsoft products. Fixes come out faster than bugs are found and while they never address them all (who can?) they do end up with a very good product in the end. XP sucked at first but then we had SP1 and now with SP2 it's probably the best OS out there. Vista will be the same eventually. This pattern has been evident ever since Windows 95. Product release sucks and then they fix it. With each Service Pack their products do get better unlike some patches for other things.
- Continual support for DirectX and Direct3D. Microsoft said that one day you could run any Direct3D game on any video card so long as the drivers worked and for the most part they have been dead on. Let's face it, this works like a charm today.
- Microsoft's refusal to sit on their laurels and continual development of new innovative products. It seems like they are always doing something.
And, no, I don't work for Microsoft. But without their products I would consume much more Advil at work. :D :D
Who's insisting anything? I have an opinion, I expressed it.Quote:
Originally Posted by Bubba
It's an implicit insistance. And where in my post did it say brewbuck? It would be nice if all us stopped arguing over such trivial matters.
What is it about C# generics that you dislike?Quote:
Originally Posted by brewbuck
The only truly annoying thing I find about them is that you can't constrain on the presence of an operator, and the workarounds are less elegant (e.g. IComparable compared to operator<). It's something I'd hope for them to do in the future.
They aren't truly static (you could actually view that as a benefit OR a drawback depending how you look at it), and you can't write metaprograms with them.Quote:
Originally Posted by Cat
It should be simple for them to implement a principle similar to C++ SFINAE. If one generic can't be instantiated (due to a missing operator or some other type conflict), just go to the next one until you find one that works. Only if there are NO generics which match, should it be considered an error.Quote:
The only truly annoying thing I find about them is that you can't constrain on the presence of an operator, and the workarounds are less elegant (e.g. IComparable compared to operator<). It's something I'd hope for them to do in the future.
That's not my business, but I would expect our marketing guy to ask him if that's monthly payments and if he already has aquired the (third party) database licences costing a multitude of what he offers himself or if we should simply add that to the bill. As I said, I'm not talking about two buttons and a textbox.Quote:
What are you going to do when a customer offers you $100k to port your application to AIX?
For our product (that is not supposed to go to the customer, but used internally) vendor independence is totally mood because for example there is only one, maybe two database vendors that can support our infrastructure commercially. And yes, we do use their drivers for that 5% extra performance. Does that make us dependent on a third party ? Totally. If Larry grabs a gun and shoots every single one of his 50.000 employees, economically, the company I work for would be toast, too. If Billy Boy revokes our Licences, we would be smashed. But then, we rely on Germany not changing it's privacy laws, we rely on our house to not be torn down by tornadoes or floods, we rely on many things we have no control over.
As I said, for every job, there is a tool that works best and as C# drawbacks don't concern us, right now C# and vendor dependent C++ (MFC) work best. Somethings else would cost more money and business is about money, not about "the right thing". What I code in private is a totally different story.Quote:
What would be less Microsoft-centric would be coding to an actual standard which is accepted somewhere other than on Windows platforms.