Why are some of you sceptic about VC++.NET?

Started by
65 comments, last by benhus 21 years, 10 months ago
quote:Original post by TheMuuj
I know it hasn''t been out long, but has anyone here tried Rotor yet? I''m tempted to download FreeBSD and give it a whirl.

I have built it successfully under both XP and FreeBSD. Not done much with it though, except running "Hello world" and looking at the source. XP is preferrable, since you are able to do some debugging against it using the VS.NET debugger.
quote:
Also, can the Windows XP Rotor run side-by-side with Microsoft''s .NET Framework?

Yes.
quote:
If so, how do you switch between them? I know different versions of the CLR are supposed to be able to run simultanously, but I''m not sure how well this actually works.

To compile, you just give a full path to the Rotor csc.exe(or put it first in %PATH%). Runtime-wise, it has a private GAC that doesnt interfere with the Framework GAC.

You will need to use a program called clix.exe to run programs under Rotor instead of the Framework runtime. Of course, assemblies created with Rotor will also run under the Framework runtime(and vice versa, as long as you dont use classes not included in Rotor).

quote:
And if someone were to port the JIT-compiler of Rotor to PowerPC, would it work on MacOSX with minimal changes?

There have been a couple of threads on this on the Rotor mailinglist[1]. This statement from John Norwood[MS] sums it up:


This isn''t going to be feasible because the current Rotor implementation is
Intel x86-only. The common denominator of FreeBSD isn''t going to help out
much here.

There would be a lot of work in numerous areas of the Rotor CLI and PAL
implementations to get it to build and run on the PowerPC chip. The endian
work alone is substantial and there are also issues of variations in the
developer toolset (gcc, etc.) between implementations of FreeBSD.


quote:speed_bump
Mono and Rotor are unrelated. In fact, the Mono folks advise anyone who wants to contribute to Mono to not look at the Rotor source.

Didnt I just post that?

[1]news://microsoft.public.shared_source.cli
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
Advertisement
the IDE is just one reason to upgrade.

[img]http://www.planetcpp.com/~adrian/funny/IDE.JPG[/img]
http://www.planetcpp.com/~adrian/funny/IDE.JPG


i love collapsable code(look at line 76), and the line numbering(you can turn off all these options. also, everything is tabbed which is nicer than MDI style windows, and everything hides like the startmenu.

im just a UI freak
Some of us just don''t care than there''s a new version . Honestly, there''s little reason to upgrade unless you''re going to be doing .NET development. Do you want a more standards compliant compiler? There are free ones available. Do you want a more optimizing compiler? The Intel C/C++ compiler, while not free, can do some incredible things. Do you want a better IDE? Well, it seems than only about half of the people that see it actually think the IDE''s better. Then there''s money, I like money . But, again, if you''re doing .NET-anything, there''s suddenly a reason. So, I see it as a pretty clear distinction between the groups who do upgrade and those who don''t. I don''t know why this thread has grown so much, we''re each different, isn''t that enough to explain why we do or don''t upgrade? Of course, more pointless threads have been seen before .
quote:Original post by ELS1
i love collapsable code(look at line 76)

On a small tangent: Anjuta has collapsable code, and it''s free . I don''t really care for it but, then again, I''m one of those people that doesn''t like ''intellisense'' either . Line numbers are nice, but I think almost every IDE and advanced text editor has them.

Well thanks for the correction, I thought Mono was a project based on Rotor, I was obviously wrong.
quote:Original post by Gabriel Fleseriu
In the meanwhile, it is clear that we actually were talking about warnings (not errors), but think about that again, Sabre: supressing ERRORS (assuming that was possible). That IS idiotic.

quote:Original post by SabreMan
Ah yes, I confess I missed that you said "error". I'd agree with you about that, as it would require allowing an ill-formed program to compile. I'm not quite sure what the result of that would be, but I doubt that VS.NET allows it.


I agree with you, forcing compilation and leave out errors is certainly not elegant, but sometimes the errors produced by the compiler might be harmless. Consider the following code:


          struct A{    enum {N=1};    int foo;};struct B{    enum {N=2};};template<class T> void init(T& t){    if (T::N==1)       t.foo = 1;}void main(){    A a;    init(a);     B b;    init(b); // will generate an error}          


Choosing between to initialize the variable or not is a compile time decision, hence, that assignment will never take place if the enum is not set to one. Even if the compiler is unable to optimize out the condition completely it is always a constant evaluation. This doesn't mean the compiler have any reason to guarantee correct behavior though. Instead, the responsibility now lies in the hand of the programmer. Personally, I'd avoid it but I can see where it would be benificial for people who is both compiler and platform dependant and likes to live on the edge.




[edited by - mcfly on June 1, 2002 1:56:22 AM]
mcfly:
suppose you supress over the entire project the error generated for your code. Then, a team collegue of yours, comes and derives
struct c: public b{enum {N=1};};///...laterinit(c); 


And also assume that your project has 100k lines. Have a nice week debugging...


Forever trusting who we are
And nothing else matters
- Metallica
Forever trusting who we areAnd nothing else matters - Metallica
quote:Original post by Gabriel Fleseriu
mcfly:
suppose you supress over the entire project the error generated for your code. Then, a team collegue of yours, comes and derives

Yes, that was easily solved but it was written for clarity. That code snip would probably be better justified with code heavy weighted on templates. In such case you''re sometimes forced to do trivial comparisions like that.
quote:
And also assume that your project has 100k lines. Have a nice week debugging...


Yeah, not a walk in the park exactly.

This topic is closed to new replies.

Advertisement