|
Hi everybody.. I'm thinking to buy Visual C.Net, but it seems to me (I'm quite new to Codeproject  ) that it has some serious problem, especially in its IDE; now I'm interested in learning "standard" C++, so I'm wondering: better stay with "old" Visual (6.0, I think?) (some shops still have it, same price) or it is too old?
Thanks
Erminio
____________________________________________________
It's what you do right now that makes the difference
|
|
|
|
|
Right tools for the right job, Erminio. Depends what you want to do.
If you're tlaking generally though, I think on one hand the complaints about VS.NET are greatly exaggerated. For something so new, it really is impressive... hell, even if it wasn't new, it has only as many problems as other IDEs.
However, the higher level the language, the less power you have (as a trade-off for ease of use). Having worked at a low level as you seem to have done, you might find VC++ an easier transition.
Tough call... wha'dya wanna do with it?
Paul
|
|
|
|
|
Hello!
I have VS .NET and VC++ 6.0 and I like the new IDE - apart from some obvious problems. And if you buy VC .NET you can do the unmanaged and the managed stuff and the new compiler is more standard compliant and there are some additions to MFC and ATL, too. So I would go with VC .NET, but I'm only a spare time programmer so I don't know if you can be more productive with the old IDE as some people complain... 
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Erminio,
I have both (just recently got VS.NET) The .net IDE is okay if just a bit fiddly. I am sure I will get used to it.
It's also seems to be slower and takes up much (3.5 GB) more space on your hard drive. If you have got anything less than a 1 gig PC with 512 MB of ram then you might get frustrated. I have vis studio v6 on a 366 Mhz laptop with 64 meg and its okay.
If you are new to it the .NET might be better if you are starting from scratch. I am sure everyone else will be migrating over at some point.
If you are buying it yourself though.... you can get hold of copies of VS6 for a lot less money than VS.NET.
cheers
Adam.
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
|
adamUK wrote:
If you have got anything less than a 1 gig PC with 512 MB of ram then you might get frustrated.
Don't believe him!  I've got PIII 550 Mhz and 128 MB of RAM! VS.NET works on my PC really OK!
Or maybe I got frustrated and didn't notice that? 
Ñ There is only one MP Ð
|
|
|
|
|
adamUK wrote:
and takes up much (3.5 GB) more space on your hard drive.
Most of that space is used up by MSDN which, unlike VS6, is installed at the same time as the rest of the VS.
Looking at my full install, without the MSDN directory, it takes up 678MB.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
You simply forgot to mention all the "affiliate" folders such like :
- c:\program files\MS .Net
- c:\winnt\.Net
- c:\MSDE
- IIS (just to be able to run the quickstart tutorial)
- c:\winnt\system32\ all run-times
- + samples directory if you intend to learn something!
And I swallow a small raisin.
|
|
|
|
|
EBonizzoni wrote:
I'm interested in learning "standard" C++
Buy Visual C++ 6.0. I think it's really easy for beginners! I was learning C++ on Visual C++ 6.0.
Ñ There is only one MP Ð
|
|
|
|
|
If you are interested in "standard" C++ as you just said, then stay away from .Net : it is of full of proprietary attributes that turn programming into a knightmare. Many times you just lose the knowledge of what you are talking about. I have already been caught about 10 times with attributes that bind behaviors without being seen, and have seen myself as if I was a lousy VB programmer who doesn't know a sh*t about programming.
Since the MSDN doc is a reference, with no real tutorials about attributes and stuff like that, you'll end up being forced to buy a dozen books before you do anything reliable.
In some way, that's the next level after ATL, these f***ing undebuggable macros.
PS : on a 128MB RAM system, you'll be swapping all the time.
And I swallow a small raisin.
|
|
|
|
|
That's the future of programming! 
StephaneRodriguez wrote:
on a 128MB RAM system, you'll be swapping all the time.
As I said before, VS.NET works on 128 MB OK for me, but when my friend wanted to debug his app on my PC (to check his program on an old computer) it crashed. Why? He was clicking too fast! Maybe I'm just a slow programmer? 
Ñ There is only one MP Ð
|
|
|
|
|
No.
VS C++ 7 is next step for C++ compilers. That's more or less ok, even though I want to see perfs, benchmarks and reliable migration articles (ie non-marketing) about going from #6 to #7 : AFAIK, I already happen to live a knightmare between old and new ATL.
VS.Net including C#, aspx, ..., is VB programming-style, ie total lost of control. In addition, the API is too limited, many people are forced to use Interop (native win32, which is a slash over C#) for practically anything relevant.
Attribute programming (seen in almost all samples in the VSNet cd) completely sucks : it is full of proprietary MS things. Where is ANSI and so called standards ? Besides that, attributes makes debugging virtually impossible.
The future of programming ? Everything of this unreliable computing stuff we have seen for the last decade should be kicked to the trashcan, and we had better actually see us building a new, reliable, operating system based on transactions : an OS on which when you start a workflow that is expected to do something precise within 15 minutes, you come back 15 minutes later then either it's done, either you have all tools to rollback, resume, ... Complete user control. In other words, computers as simple tools, not as ends in themselves.
VS.Net is the total opposite : Complete MS control (many many many undocumented features and bindings), MS relying on developers for evangelization : that's the first time they go that far.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
VS.Net including C#, aspx, ..., is VB programming-style, ie total lost of control. In addition, the API is too limited, many people are forced to use Interop (native win32, which is a slash over C#) for practically anything relevant.
I've been able to achieve a great deal without touching the Win32 API through interop, and when I do have to, I can pack it off into a legacy dll which can be replaced as the aging Win32 API falls off the face of the earth (cant wait...)
The .NET API is well designed and a GREAT first version. Win32 was a mishmash as a first version, and has only become moreso with time.
I agree that close to the metal is a good way to go for some things, and I do delve into the low-level programming when working on pocket pc apps, but I also want a rich, clean API with strong debugging and acceptable performance. C++/MFC/ATL/Win32 no longer takes that crown in my opinion.
As for complete MS control, C# is an ECMA standard, and if MS pulls the rug out from under the ECMA standard, its fairly easy to port C# code to Java (as long as you put your core logic in classes, a large project can be ported in a few days by search-replacing), so i dont think they would do such a thing. Their best interest is served by making C# more open than java.
perhaps you should investigate the .NET api, it sounds to me like you dont realize how coherent and open it really is... No offence ment, but it almost sounds like you got your opinion of it from a 'C# for C Zelots' article on slashdot.
|
|
|
|
|
Christopher Lord wrote:
I also want a rich, clean API with strong debugging and acceptable performance. C++/MFC/ATL/Win32 no longer takes that crown in my opinion.
With C# you no longer have a callstack beyond your own files. If you are a C++/MFC/ATL coder that's quite a shift, isn't it ?
If you accept this lost of control, that's fine. I don't.
Christopher Lord wrote:
As for complete MS control, C# is an ECMA standard,
A C# app is a WIN32 app with 100% proprietary stuff. I am not talking about it cross-platform, I am talking about it being documented. Only the surroundings are documented. The combination of interop/attributes/Net framework falls short of documentation, whereas that's exactly what we do in real apps.
Christopher Lord wrote:
Their best interest is served by making C# more open than java.
C# is nothing new, that's the rebranded MS JDK 3.0 (1997)
Get it!
Their interest is to take control of your apps by being the providers of an always changing run-time.
By 2004, a basic .Net framework run-time will be part of the OS, and your apps will force customers to buy new computers and hardware just to run it. That's the next level after MS forced us to buy new hardware just to run VS.Net. We developers have never been that much in the "buy-new-hardware" thing. That's what I see.
From my previous post, I have just realized you have skipped the "transaction" part. That's too bad, as it is my main feeling about .Net : great apps will say light of day, but the Object class implementation remains transaction-less, in other words the apps remain unreliable, just like win32 apps.
And I swallow a small raisin.
|
|
|
|
|
Using C++ with VS C++.net standard edition.
I can use the .net framework with my C++ application ?
is it what Managed C++ used for ?
I want to use the XmlWriter namespace ( if that's what's it's called ), is it possible ?
Sorry, if it's a really stupid question, but now, I'm really clueless ... I'm taking a couple of hours this afternoon to go buy a book about this ... any good suggestion ? mostly C++, Managed C++ .NET framework ...
Max
|
|
|
|
|
No! .NET Framework is not something like MFC.
You cannot use .NET framework in your C++ app.
Managed C++ is not the old C++, there are a lot of differences. .Net Apps work in other than normal Windows app.
Buy a book about .Net framework, what it is and how it works?
Ñ There is only one MP Ð
|
|
|
|
|
Maciej Pirog wrote:
You cannot use .NET framework in your C++ app.
Managed C++ is not the old C++
You *can* use the .NET framework in your C++ app; and Managed C++ is old C++ with some extensions to it.
Now there are some gotchas to be aware of; one is that an unmanaged class can't directly hold a reference to a managed pointer; the solution is to use the gcroot template class.
That said I recommend, Microsoft Visual C++ .NET Step by Step by Templeman and Olsen.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
James T. Johnson wrote:
Managed C++ is old C++ with some extensions to it.
And there are some C++ features that you cannot use in Managed C++. The main difference is not in language, but in the way it works! The C++ is compiled to the normal x86 code (in MS Windows), and Managed C++ is compiled to MSIL.
James T. Johnson wrote:
You *can* use the .NET framework in your C++ app;
Ok! Will you compile it with an ordinary C++ compiler or a Managed C++ compiler?
.Net Framework apps can use API or MFC functions and classes, but you cannot add things from .Net Framework to a normal app as other libraries.
Ñ There is only one MP Ð
|
|
|
|
|
I recommend, Microsoft Visual C++ .NET Step by Step by Templeman and Olsen.
James
"And we are all men; apart from the females." - Colin Davies
|
|
|
|
|
Does anyone know if there is an add-in somewhere that will do syntax highlighting for .IL files, or better yet, an add-in that extends VS to allow the creation of IL-based projects? Or if not, how I could write an add-in to do this?
Thanks
|
|
|
|
|
i am tring to develop an application which can install any type of software on any platform with out user interaction in dot net.
First of all my application will learn all events and messages at least one time then it will perform the task on the network on any computer.
is it possible?
if yes how?
can some one provide the helping metrial and links about that?
r00d0034@yahoo.com
|
|
|
|
|
when i use that function (AfxGetInstanceHandle())in managed class i got an exception i do not know how to handle it.
how to sue it in managed vc++ code ?
how to sue it in c# code ?
plz help me.
r00d0034@yahoo.com
|
|
|
|
|
- 21 MB for the default .Net framework (you have a link in CP homepage)
- 6MB for .Net SP2
- 6MB for MDAC2.7 if the application uses data access
- and depending on the application the user may be required to install IE6.0 (integration with windows forms, etc.).
And I swallow a small raisin.
|
|
|
|
|
Thanks.
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
I have a server that accepts a socket connections and accepts authentication requests in a specific protocol. I want to use this for an ASP.NET authentication. How can I make my ASP.NET app maintain a single connection to this auth server and send authentication requests to it?
I mean a COM object does not seem to be the right way anymore. What is the preferred .NET way of implementing this?
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
I guess the "proper" .NET way of doing this is to write a class that takes the credentials and performs the authentication against the server. You create this object then once and store it in the Application context. But beware you better build this object with sound multithreading capabilities, otherwise this might become a severe performance bottleneck.
--Chris
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
