|
Maybe I've been sleeping too much
But can anyone help me to a address or a book where I can get a kickstart to VC++ .net programming? And the .net platform in general?
I have a feeling I'm missing out on it.
Thanks,
Erik
|
|
|
|
|
I have heard that "anonymous" functions (is that what they're called?) will be available in C#. They will allow something like this:
this.Button1.Click += delegate(object
dlgSender, EventArgs dlgE) {
Label1.Text = "Yeah, you clicked the button!";
};
Will this be available in the next version of MC++ as well? Will it be in future? And one last question: will XML comments be available, so that the compiler can create a documentation?
Thanks for this great interview! Regards,
Felix Arends
|
|
|
|
|
It's too late for this reply, but no, anonymous delegates won't be with us in C++/CLI.
|
|
|
|
|
Or event platform SDK!? Don't expect MS to tell the truth.
We don't want any dependency to our C/C++ projects other than APIs. Because not every project needs XML/Web Service/Winform etc etc all these fancy stuffs, a system needs to be tailor to business objective, not software technology objective! Even if we need to, we can do it with native code that is PORTABLE across major platforms. C/C++ is so far the best language to map analysis result to software architect, and finally code structure like design pattern.
Until MFC/ATL/WTL is capable like Stingray Studio or even Borland Delphi Visual Class Library, MS should not only focus on pushing .net extension to C/C++, putting something that is incompatible together. IMPROVE MFC/ATL/WTL/STL !!
We pay equal amount of $ to buy V.Studio, we expect MFC/ATL/WTL to improve. Otherwise, go LINUX!
|
|
|
|
|
Uhm. That's not actually what I would expect from a hard-core programmer. We are open minded people, we live with novalties, new technologies and platforms. It's not the end of ATL. May be it's end for MFC, it was not, in my personal opinion, a successful library. As you might have noticed, MFC shifted towards templates and ATL. If you ask me, I don't use any libraries, neither ATL nor WTL (I used to use, though). Platform SDK will be available for sometime, it's not going away anytime soon. However, it will be deprecated as of Longhorn, because .NET will be OS API, it will be the Platform SDK.
Those web services, XML and other stuff doesn't necessarily be used in all projects, of course. You can still roll your very own CreateWindow and use your very own WndProc, they are not dieing.
Microsoft have a vision on .NET - it's becoming a major part of the OS. If you keep using C++/CLI, you can still have access to native Win32 API as well, without compromise - It Just Works!
You can still use Linux. I am contributing various open source projects. I, however, use FreeBSD, because I find it more solid than Linux. The major problem with those operating systems and their mentality is that they don't do things properly. If you do something, you have to do it properly. Backwards compatibility is a major issue. I remember I have had a bad experience with auto* tools. It's changed a revision - not even version - but my existing code didn't compile with it! Mysql++ library has changed and didn't compile with my existing code. These are not good examples, I have lost my trust in open source world a lot. Is there any IDE like Visual Studio in open source world? No! Even though they have better support for, say, regular expressions, there is not an IDE that has something as good as IntelliSense. Is there any equivalent of IntelliSense in any open source IDE? Eclipse got closer to it, but it has other problems. There is not an all-in-one solution, unfortunately.
|
|
|
|
|
It seems that Microsoft is repeating the mistake that Sun made with Java: Insist that code for their new platform (.NET) must be written in a different language than regular code. In this case, Microsoft provides a choice of several languages, VB.NET (different from VB), C# (new language) and "Managed C++" (different from regular C++), and several others.
While adding useful features to C++ is in itself nice (hey, // comments are still formally non-standard C, void* and prototypes used to be nonstandard before ANSI C, __int64 / long long is still nonstandard), this should not be so tied in to a programming interface like the CLR or the synchro needs of that old OS for which Modula-2 was created.
What I hoped for when Microsoft presented the "It Just Works" strategy for C++ on .NET was more like the following:
1. Treat MSIL as just another CPU, on par with x86, arm, itanium and amd64 (plus the old ones).
2. So implement a version of the C++ compiler back end which generates MSIL code from the C++ meta-operations and types. The MSIL should be fully verifiable etc. So if a C++ program tries to scribble to invalid pointers or assign out of range values to an enum, then the generated MSIL would produce the equivalent of a native access violation exception, catchable using the usual C/C++ mechanisms also used for native code. The difference would be that the MSIL code will detect almost any such assignment creating a super version of /GS which is as safe as any other .NET code.
3. Choose the mapping between C/C++ types/idioms and MSIL types such that the obvious equivalencies just work: a char* is a System.String or an iterator into one, a void* is a reference to a generic, a VARIANT (from the modified windows.h) is a generic too etc. Weird (but common) casting tricks invoke implicit conversion routines buried in the C++ runtime for .NET (which also contains .NET implementations of those C/C++ runtime functions not included in the CLR, like printf()). For some types and functions it would be necessary to generate sets of overloaded MSIL functions, e.g. one that accepts a System.String, one that accepts an iterator into a System.String, and one that accepts a generic reference.
4. Implement the entire classic C and C++ runtimes (not just the STL, but anything included in previous releases of unmanaged C/C++, like printf(), memcpy(), iostream, CreateWindowEx, malloc(), CString, ATL, MFC...) in a version that runs on top of .NET with the same semantics as the implementation on native systems. For some functions this is simple inlining, like strcpy(String, String) mapping to .NET assignment, For some it is deep and big magic (like a huge family of memcpy implementations, each knowing how to compute the value in one particular .NET type which would have resulted from doing a native memcpy to a native equivalent of that type, based on the bit pattern coming from a specific other .NET type in the inverse manner). With the basics in place, many higher level runtime functions (like printf and MFC) may end up as just a recompile of the same source used for the native libs.
5. Make .NET things available as (real or simulated) C++ headers. That is if the current managed C++ would say
using SomeAssembly.SomeSubAssembly
then a truly IJW C++ for MSIL would simply accept
#include <.net/SomeAssembly/SomeSubAssembly.h>
and do its mapping behind the scenes.
All in all, imagine the following being completely valid managed C++, needing only the CLR and the
C++ runtime for CLR assemblies, and compiling to fully verifiable MSIL. The compiled code does not rely on the existence of the Windows API MessageBox or use native plumbing. It invokes the equivalent functionality in Windows Forms through a wrapper function in the managed <windows.h>
#include <stdio.h>
#include <string.h>
#include <windows.h>
int main(int argc, char **argv)
{
char *buf = malloc(100u); // returns a managed object saying "100 bytes equivalent requested"
// or the managed equivalent of NULL
// assignment to char * converts to a System.String^ with a limit of
// 100 chars, or to a similarly NULL reference if NULL
// malloc() memory IS garbage collected in .NET
buf[0] = 0; // changes first char of string, sets length to 0, remembers any
// bytes after that in case the 0 is later removed.
// throws exception if buf was NULL.
while (--argc)
{
if (**++argv == '/') // advances iterator in ordered collection of strings, then examines
// first char of the string at the iterator.
printf("Option is %s, %u to go\n", 1u + *argv, argc-1); // managed varargs is mapped
// to an ordered collection
// of generics.
// the printf in the C runtime
// does type checking as it
// works, throwing exceptions
// as necessary.
else
MessageBox(0, argv, "Hello, There", MB_ICONINFORMATION); // implemented on top of Forms
memcpy(buf + strlen(buf), argv[-1], strlen(argv[-1]) + 1u); // argv[-1] copies, decrements
// and dereferences the
// iterator.
// strlen is directly inlined
// to a CLR string length
// buf + integer produces an
// iterator in the string
// memcpy(string iterator,
// string, some count)
// performs managed string
// operations, throwing
// exception if write past
// string limit.
// Insecure, security hole if native C++,
// Secure but potential exception in managed C++
}
printf(buf); // Insecure printf format vulnerability if native C++
// secure, but potential exception in managed C++
return 5;
}
|
|
|
|
|
At first Microsoft try to make C/C++ source structure like Java, now they introduce and even structure the new keyword much like Object Pascal.
Ultimately, all Microsoft wants to do is destroy integrity of C/C++ as a language, force people into .nut. That's about it. Funny while many of their flagship products (including BCL of .net!!) will still based on native C/C++ instead. We become the piggy pig who buy this and that to help them build a system that bound us to MS solution only, instead of continueing add class and functionality to ISO C/C++.
Yet so many people don't see the consequences and blindly support the "copy java, make it Microsoft" idea. Guess is true there are probably 90% programmers but only 10% true software engineer.
|
|
|
|
|
TW wrote:
Ultimately, all Microsoft wants to do is destroy integrity of C/C++ as a language, force people into .nut. That's about it. Funny while many of their flagship products (including BCL of .net!!) will still based on native C/C++ instead. We become the piggy pig who buy this and that to help them build a system that bound us to MS solution only, instead of continueing add class and functionality to ISO C/C++.
Yet so many people don't see the consequences and blindly support the "copy java, make it Microsoft" idea. Guess is true there are probably 90% programmers but only 10% true software engineer.
Hmm. I think you are taking this a little too seriously. It's a tool to do a job. If you don't like it don't use it. There are plenty of other C++ compilers out there.
As for consequences, anything that improves Windows development has to be a good thing.
Michael
Blue canary in the outlet by the light switch
Who watches over you
Make a little birdhouse in your soul - They Might Be Giants
|
|
|
|
|
No one in their right mind would use nonstandard C++ features in anything that wasn't already tied to a Windows platform. I don't think many "piggy pigs" will blindly back themselves into a Micrsoft corner by just blindly using managed extensions.
Think about it. Even with these language changes, using managed extensions is *hard*. You have to think about it. "Now, what kind of object do I have here? Which kind of pointer do I use? Which syntax is that?" That's a cognitive burden that no one would willingly take on unless they were getting a real benefit. If, as you say, only 10% of programmers are real software engineers, then I see it breaking down like this: those 10% make an informed decision about whether they will see some benefit from using the features (they are writing a .NET component in C++, say), and the other 90% don't touch the stuff because it makes it harder to program than C++ already was.
Even if you're only writing for the Windows platform, there is of course the issue of vendor lock in. If you write for MSVC, you can't necessarily just pick up and move to Borland. I think history has shown, however, that other compiler vendors for the Windows platform tend to pick up Microsoft's extensions to the language if they become popular. The market ends up demanding it, because if there is anything that consumers (oh how I hate that term) want, it's both features *and* choice. An example: __declspec(dllexport), which is, while an ugly beast, in my mind preferable to separate .def files, and is recognized by any C++ compiler for Windows that I am aware of. For example, the following is ripped directly from the cygwin gcc 'info' page.
On cygwin, mingw and arm-pe targets, `__declspec(dllimport)' is
recognized as a synonym for `__attribute__ ((dllimport))' for
compatibility with other Windows compilers.
Even Stroustroup has mentioned before that he'd like to see some more "high level" features added to C++ in some future round of standardization, such as standardized ways to interface with other languages through technologies like COM and CORBA. (Sorry I can't link to that b/c I don't remember where I read it - but it was before .NET came out and I think his sentiment would apply to .NET as well as to COM). There's a long tradition of compiler vendors taking a shot at implementing features many years before they even come up for standardization - how else would a standards body know what works and what doesn't?
The lack of a "property get" and "property set" syntax in C++ is not because it's uniformly believed to be a bad idea, I think. It probably just hasn't been done yet. Someone who lurks in comp.lang.c++ more than I (which is essentially never) may be able to correct me on this point. But with function inlining becoming the rule, I imagine that such a syntax is coming to standard C++ one of these days. Microsoft's implementation is a fair attempt at creating such a syntax - something that standards bodies can use for reference if they decide to make that mod some day.
Not everything from Microsoft is necessarily evil. I don't hear much screaming when QT developers use slots as if they were real C++ language features...
|
|
|
|
|
Unfortunately you are correct, but it's the future there's no hiding from it but in a few years to come MFC will be gone .net will be the dominate player and lets face it the biggest market is for Microsoft tools and that's where the pay cheques come from. The biggest salary are C++ & C# expertise commanding big bucks in the UK.
I am that is
|
|
|
|
|
What is gonna happen to VC++?? will it be .NET only? one of the things that most people forget is that with .NET, you lost touch with low level functions and there are a lot of programmers who really depend on them to make interface with hardware components, via RS-232 or PCI cards. For example, if you want to control a RF chip through USB or RS-232, you cant programm it in C# or VB.NET! They simply dont have the low-level functions access neither they behave well in time-critical operations.
For example, we now are developing a system that aquires signals from a RF system we made and then inserts the samples in a DB. It generates about 10.000.000 records per day, which is about 100 queries per second. We are using MySQL, btw. I dont think it would be possible to make it based in .NET!!!!
SO: will VC++ as we know it disapear? I dont think so, i dont imagine industrial machinery running windows CE.
One other aspect: my partner thinks we could lose market as our vc++ based apps lose potential. It could result in inverse! If everybody starts programming more high level languages, the old guys who still know how to do low level stuff will be very well paid. If so, GO .NET!!!!
|
|
|
|
|
|
If you did Delphi, you will see similarity. Keyword is one thing, the way it changed C/C++ coding structure is another - which directly contribute to how a good C++ system is designed.
Personally, the new extension sucks. What we need is new class build with native (ISO C++ standard), not a "bridge" to an unknown framework.
|
|
|
|
|
Any .NET class derives from System.Object, so why not just make use of the obvious and stop introducing new keywords?
Since, non-C++/CLR class will not derive from C++/CLR class, it should simply mean any class derived from a C++/CLR class is a C++/CLR, no need for new keywords.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
|
Couldn't believe % ^ is used in such way . If you did Delphi as well, you will find many similarity.
To be brute, Microsoft never learnt, copy copy copy, that's about it.
|
|
|
|
|
Some people are going to rewrite their applications Thank God, my boss asked me to drop the MC++ project, even though it was almost completed.
Anyway, at least the MC++ name is gone - have been be fighting for its dead. How do you create a reference to C++ object and claim it is gabbage collected and therefore managed, and all others are unmanaged? Using reference is nothing new in C++, still do not see why it should be T^ instead of T&
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
You can only bind a T& in the declaration, whereas you will be able to assign a new object to a T^ .
|
|
|
|
|
It seems to me like VC++ is going the way Office went:
Instead of fixing the bugs they throw out a new version with new, very 'useful' features. May be nice for a .NET developer, but heck, I got tons of C++ / MFC code to maintain, and VC.NET isn't much of a help with that.
BTW, where did they listen to developers? I don't know of a address to report bugs or to make suggestions within MS
dirk
|
|
|
|
|
DiWa wrote:
May be nice for a .NET developer, but heck, I got tons of C++ / MFC code to maintain, and VC.NET isn't much of a help with that.
Really. I was a little sceptical myself to start with, but now I have 90% of my code-base running with VS.NET 2003. All converted from VS6. Whilst I still miss my CTRL-W class-wizard, I've found that VS.NET's quirks have made me less dependant on wizard generated code - which can only be a good thing.
I still think the ATL attributed code is a pain in the ass, but I just use VS6 to generate the boilerplate and then load the project into VS.NET
Michael
Blue canary in the outlet by the light switch
Who watches over you
Make a little birdhouse in your soul - They Might Be Giants
|
|
|
|
|
Michael P Butler wrote:
I've found that VS.NET's quirks have made me less dependant on wizard generated code
You are certainly right with this. What gives my bloodpresure a push is the way they deal with resources. I got projects with ~200 dialogs, and it takes twice the time to get my dialogtemplates connected to code.
|
|
|
|
|
Michael P Butler wrote:
I still think the ATL attributed code is a pain in the ass, but I just use VS6 to generate the boilerplate and then load the project into VS.NET
Why not just use VS.NET to generate non-attributed ATL, thats what I do. There is a small checkbox letting you do that.
- Anders
Money talks, but all mine ever says is "Goodbye!"
My Photos[^]
nsms@spyf.dk <- Spam Collecting
|
|
|
|
|
Yes, the .NET interface sucks for developing regular MFC applications. Classwizard was a great tool. The worst part with the new interface is that when you are creating a variable for a dialog resource, the window closes automatically after one is created. Imagine if you have 10-15 controls on a dialog.
|
|
|
|
|
|
Is it not possible to write an add-in that reproduces ClassWizard? Is anyone attempting it? Or perhaps MS will restore it in v2?
Kevin
|
|
|
|
|