|
Reelix wrote: "Which Compiler are you using... ?"
He replies...
"SharpDevelop"
SharpDevelop is an IDE (Integrated Development Environment), as is Visual Studio. Nothing more nothing less. The compiler is a totally different thing.
|
|
|
|
|
Of course, but I think the main issue here was the way the code was formatted by the IDE. Personally I don't care with what the code was written, as long as it is readable. Even with the best IDE some people manage to produce unreadable code and others do a great job just with the Notepad. 'Beautiful' code may seem like a luxury to some, but it is not if you have to inspect other people's work and find out what it does.
|
|
|
|
|
So have VS reformat it when you open it.
|
|
|
|
|
Hey now, i Love SharpDevelop and i've never had a problem with it.
Although, if you are using SharpDevelop (any kind of recent version) for a form you should get:
Program.cs
MainForm.cs
MainForm.Designer.cs
and finally
AssemblyInfo.cs
Generated code goes in file.Designer.cs and events and whatever, go in file.cs. I still think partial classes are a bit wierd though. Maybe we should just go back to header files 
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
SharpDevelop usually creates a MainForm.cs (since version 1.0 [and even in the betas before], and since version 2.0 it also uses MainForm.Designer.cs).
If he has a form in Program.cs, that means he put it there manually.
|
|
|
|
|
Reelix wrote: He replies...
"SharpDevelop"
I cry....
SharpDevelop is a good tool. And, I actually recommend even Notepad for beginners so that they can get used to the SDK tools. The IDE hides so many things and makes one lazy.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
SharpDevelop is still good, and its free.
in ur case you friend didi not uploaded the project file(Csproj) which sharpdevelop creates!.
|
|
|
|
|
I freely admit it: I have done this frequently in the past and I will do it again. And it holds countless horrors for those who are not used to it anymore:
void SomeClass::SomeMethod()
{
asm
{
....
}
}
Seriously, I once began on a small self-built machine and typed in machine codes with its hex keypad. Compared to that some C++ inline assembly code is already high level. But I often wonder how people fare, who started out with something like .Net and Java.
Edit: How do I indent the code lines correctly with this editor? Tabs and spaces will not work.
modified on Monday, May 5, 2008 9:25 AM
|
|
|
|
|
CDP1802 wrote: How do I indent the code lines correctly with this editor? Tabs and spaces will not work.
Use a <pre> block, not a <code> block.
|
|
|
|
|
|
CDP1802 wrote: But I often wonder how people fare, who started out with something like .Net and Java.
I find it extremely hard  I wish I knew a lot more.
|
|
|
|
|
I never had to write inline ASM, but whats the big deal ? And isn't it __asm ??
|
|
|
|
|
In Visual C++ I always used plain 'asm', but I don't doubt that also '_asm' exists. I will look it up when I start working.
|
|
|
|
|
Sorry - but I have to say this isn't a horror. Sometimes it's just plain necessary.
|
|
|
|
|
I also see it that way. At college a professor tried to tell me that I can't possibly write better code than a compiler. I proved him wrong, but it's not really hard do better than a compiler in most cases.
But I had the impression that many people feel uneasy about going down to assembly level. They are used to all kinds of high level comfort and it seems to be a horror for them to give it up.
|
|
|
|
|
CDP1802 wrote: But I had the impression that many people feel uneasy about going down to assembly level.
Horses for courses. If I'm writing a data entry app, then I would be extremely uneasy, but if I'm writing an app that needs to interact with the registers then I would use this.
|
|
|
|
|
Certainly. A user interface which sits there most of the time, waiting for some event to happen, would not profit much from assembly code. Also, I would not want to lose all benefits from object oriented programming.
But then comes something, that needs a little optimisation. Sometimes you can't just write beautiful high level code and tell the customer to buy a faster computer.
But it seems, this is a lost art. Many 'modern' developers tell me that the compilers are good enough (I usually tell them that this means they are not), the next generation of processors will bring more than any optimization, and of course, that optimization costs too much development time.
|
|
|
|
|
CDP1802 wrote: But it seems, this is a lost art. Many 'modern' developers tell me that the compilers are good enough (I usually tell them that this means they are not), the next generation of processors will bring more than any optimization, and of course, that optimization costs too much development time.
Sadly, but true.
Another reason to know assembler is, when you have written 'correct' code, and somehow there is a bug in the application. In those rare cases its good to be certain that the compiler has created correct code. This way we have found 3 bugs in the compiler and one bug due to including a header which changed a struct a little in one specific part of the application.
Learn from the mistakes of others, you may not live long enough to make them all yourself.
|
|
|
|
|
CDP1802 wrote: Sometimes you can't just write beautiful high level code and tell the customer to buy a faster computer.
Oh I don't know, Microsoft does it all the time! 
|
|
|
|
|
watching our professor give his assember 'examples' IS a horror!
|
|
|
|
|
//At college a professor tried to tell me that I can't possibly write better code than a compiler. I proved him wrong, but it's not really hard do better than a compiler in most cases.//
I have found that, in general, the smaller a routine, the more likely it can receive a big speedup from hand assembly (at least if it doesn't match a particular 'pattern' the compiler can recognize and optimize). Some years back I wrote a game for an XT which had about 20 lines of assembly code in a 1400-line game. The assembly code ran about ten times as fast as what the compiler could generate, and yet still represented about 80% of the main loop's worst-case execution time.
Nowadays a lot of my hobby programming is in assembly language, though. On a game machine with 128 bytes of RAM (code runs from ROM) when there are 76 clock cycles per scan line to handle display drawing, assembly code is pretty much a must. A BASIC compiler exists using some pre-defined display kernels, and people have done some cool things with it, but for real power programming hand-written assembly is the only way to go.
|
|
|
|
|
True. I use the CPUID instruction as part of a diagnostic reporting operation. The information reported isn't available from a Windows API (AFAIK).
|
|
|
|
|
I've obviously got too much shooting on the brain because I thought, wow someone else going to The Classic[^] 
|
|
|
|
|
Now that would be no programming horror 
As for shooting... I used to be good with machine pistols, rifles and machine guns, but probably could need a little practice now.
|
|
|
|
|
CDP1802 wrote: But I often wonder how people fare, who started out with something like .Net and Java.
Taught myself assembler on an old 386 in a very boring support job. Lowest I get to these days is MSIL ... sadly most .Net developers aren't even aware of that. In a previous gig I had code that added dynamic methods to reset resources. Not only did the other developers not know about dynamic methods, they didn't even know what IL was .. sad.
I'm largely language agnostic
After a while they all bug me 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
