|
leppie wrote:
What does it do exactly then?
It does what I said it does. You can argue semantics on my original post, but it does NOT get compiled into anything your computer can use, it gets compiled into IL, an intermediate step before final compilation into actual, runnable code happens at run time.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
There are a number of reasons why C# compiles faster than C++. Here are the ones I thought of - there are likely more.
1) No preprocessor. In C++, you either need a separate preprocessor step or a fairly complex on-the-fly preprocessor (I don't remember offhand what VC++ does). In C#, you can easily do everything on the fly.
2) "All at once" compile model. In C#, all the compilands are compiled at once, and in C++, one file at a time, plus link time at the end.
3) Much easier metadata model. The #include model of C++ doesn't scale particularly well, and it requires reading the include files in textual format (including the preprocessor step) for every compilation. Compilers can get around this with "precompiled headers", which helps get rid of some of the overhead, but at the expense of more complexity when the set of includes changes. It also only applies to system headers, not ones from the current project. C# gets the ability to read in metadata in a binary format and more importantly, on a per-assembly basis. This is roughly the difference between looking for data in a database and looking through a text file to find the data.
4) Smaller set of libraries to consider. The Win32 Platform SDK is a huge beast, and typically has gotten bigger with each release. On the C++ team, it was not uncommon for us to work hard to get 10-20% increase in compile speed, only to see all of that eaten up by the increase in size of the windows headers.
4) Very limited compiler optimization. The C++ optimizer on release builds will normally take more time on a per-file basis than the parsing phase, though I will point out that even if you build a debug, non-optized build, C# is still quite a bit faster.
Eric Gunnerson
Current C# Compiler Program Manager
Past Visual C# Compiler QA Lead
Past Visual C++ Compiler QA Lead
|
|
|
|
|
Am I the only person who's noticed that enumerated values in C# suck? They hold integer values yet they can't be used as integers without casting. 
Like in C++, I'd like to use an enumerated value to retrieve an array element by index, or as a bitmask value which may be ORed or ANDed. But no, I have to add the yucky (int) cast every time. What a load of crap! 
Anyone else think they should have made the compiler work more like in C++ with regards to enumerated values? Why didn't they? Is this "feature" also prevalent in VB.NET?
Thanks,
Alvaro
Can I ask you a question?
|
|
|
|
|
First, you *can* do bitwise ops on Enum values without casting, but you might want to mark the enum with the FlagsAttribute if you do so (which VS.NET, at least, uses in some cases).
Since enums can be defined as various at various int sizes and signed or unsigned, that implicit cast would have to follow the enum's int type or risk a lossy cast (can't cast to Int32 from Int64 without a loss of data similar with unit to int). I prefer the type safety and un-ambiguity, and if you need it, the int value is there.
R.
|
|
|
|
|
Richard Lowe wrote:
First, you *can* do bitwise ops on Enum values without casting, but you might want to mark the enum with the FlagsAttribute if you do so (which VS.NET, at least, uses in some cases).
Um, no. It doesn't work. Tell me if this compiles for you:
[Flags]
enum e { e0, e1, e2 };
void foo()
{
int i = e.e1 | e.e2;
bool b = (i & e.e1) != 0;
}
Richard Lowe wrote:
Since enums can be defined as various at various int sizes and signed or unsigned, that implicit cast would have to follow the enum's int type or risk a lossy cast (can't cast to Int32 from Int64 without a loss of data similar with unit to int). I prefer the type safety and un-ambiguity, and if you need it, the int value is there.
Hmmm, it may be that I've gotten used to employing enums for more than what they're really designed for. I guess I'll have to revert back to the Java way: use const ints. 
Regards,
Alvaro
Can I ask you a question?
|
|
|
|
|
Alvaro Mendez wrote:
[Flags]enum e { e0, e1, e2 }; void foo(){ int i = e.e1 | e.e2; bool b = (i & e.e1) != 0;}
No, but this does:
e = e.e1 | e.e2;
bool b = (e & e.e1) != 0;
I do it all the time.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Yeah, that's nice.
Unfortunately, this forces you to predefine all your bit values in the same enum. If you then create a derived class with an extended set of bits, inside its own enum, you can't AND or OR those to the base class's. You follow me? In other words, for class hierarchies this doesn't work. If enum types could be derived, it'd be another story, but...
Regards,
Alvaro
Can I ask you a question?
|
|
|
|
|
C# enums are not primarily used for giving integer constants names. For that purpose you use integer constants. Enums are a type of their own. Thats why they have to be casted if you want to use them as integers. That, together with not treating 0/1 as boolean values, are just ways to improve the language and enforce type safety, that makes us programmers write safer code.
Your examples of bitwise operations dont work because you try to implicitly convert to Int32.
|
|
|
|
|
A bitwise operation on one Enum to another Enum yields *an Enum* - not an int. They keep their type safety. So assign the result to an Enum and it works.
|
|
|
|
|
I am handling the MouseHover event for my toolbar. I would like to find out which button in the toolbar the mouse cursor is hovering over. How do I determine this?
Gary Kirkham
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
|
|
|
|
|
With the BCL ToolBar class, you have to get the mouse coordinates (this is easy), convert to client coordinates in relation to the toolbar (call PoingToClient on the toolbar instance) and enumerate your toolbar buttons to find out over which the point lies.
For most applications, I recommend you go with a decent 3rd-party toolbar. They have a lot more functionality.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
The Scenario
I've created a custom control that has a public property that is of an enumerated value type. I have created an accessor method to get/set that property and have it 'binded'. Finally, in the constructor for the control, I set that property to a default value, referencing the full namespace of the enum value type to ensure no conflicts with other controls would exist (see sample code below):
<br />
namespace MyControls {<br />
<br />
public class MyCustomControl : System.Windows.Forms.Label <br />
{<br />
public enum MyLabelType { High, Low, Special, Hidden };<br />
<br />
private MyLabelType myLabelType;<br />
<br />
public MyCustomControl <br />
{<br />
myLabelType = MyControls.MyCustomControl.MyLabelType.Special;<br />
}<br />
<br />
...<br />
<br />
[Bindable(true), Category("Custom Properties"),<br />
Description("My Custom Control ...")]<br />
public MyControls.MyCustomControl.MyLabelType LabelType<br />
{<br />
get ... <br />
set ...<br />
} <br />
<br />
...<br />
<br />
}<br />
}<br />
The Problem
I drop the custom control onto a form and set my properties without a hitch. I add a using clause to my code for that namespace and do a build. I get no errors, I can run the application without issues ... Etc. However, if I close the solution/project, and open it back up, then open that form back up in design mode, I get errors on that enumerated property that indicates "The variable 'MyLabelType' is either undeclared or was never assigned".
When I attempt to set a variable to this value type my code, the intellisense doesn't "find" the enum value type. (Example):
MyControls.MyCustomControl.MyLabelType is not found ...
Yet if I open custom control solution in studio, rebuild it, and then go BACK to my solution that uses the custom control, studio can now "see" the enumerated data type ...
I have tried to set the "DefaultValue" on the property accessor for this type, but to no avail. It does not seem to affect the outcome.
Any suggestions or answers as to what I am doing wrong, or to why this is happening? I'm guessing the solution is something simple that I am just overlooking.
TIA
D.
|
|
|
|
|
I'm trying to pass a reference of Form1 to Form2 so I can change things on Form1 from Form2.
Here is my logic:
Form1
private void btnShow_Click(object sender, System.EventArgs e)
{
FormTwo = new Form2(ref this);
FormTwo.Show();
}
Form2:
public Form2(ref Form1 PassingForm)
{
InitializeComponent();
FormOne = PassingForm;
}
error CS1605: Cannot pass '<this>' as a ref or out argument because it is read-only
i can read the error, .. but what would the proper logic be here?
|
|
|
|
|
You don't need 'ref', because a Form1 is already a reference type. The error occurs because you're trying to pass a reference to 'this', which cannot be changed.
Personally I find reference languages confusing, because of the nature of aliasing and that there are no clues in the syntax indicating whether you're dealing with a value (which uses a shallow copy) or a reference (which merely copies the reference).
|
|
|
|
|
Hey,
I have a listview bounded to a dataset.
I have also 2 textboxes. These textboxes are in the same listview.bindingcontext.
listview.BindingContext = new BindingContext();
txt1.BindingContext = listview.BindingContext;
txt2.BindingContext = listview.BindingContext;
The listview has an event : selectedIndexChanged
I can also sort the listview.
How can I set the bindingmanager.position in the selectindexchanged event too the right record-index in my dataset?
After sorting, the index in the listview is not the index of the record in the dataset.
With custom collections, when I add an object I give it an internal id. So, I will always find the right object.
With a dataset I can not give him an internal id, because dataset is filled up with the sqldataadapter.
Thanks
|
|
|
|
|
I have a windows form with two tabpages. On the form load I want to move the second tabpage to the front(or have it display). Any ideas on how to do this? I have tried using tabPage2.focus. Didn't work.
thanks
Jubal
|
|
|
|
|
Have you tried:
<br />
MyTabControl.SelectedTab = tabPage2;<br />
I think that works....
|
|
|
|
|
How to Active C# form in MFC project?
|
|
|
|
|
Hi,
Is that possible to version a solution ?? If yes please help me out.
We have 2 phases in our web application project. Now the 1st phase is over. 2nd phase is coming now. Now, the question is how I maintain 1st phase changes in the solution. Can I version the phase 1 solution ?
Client is using phase 1 solution now. So any changes if they say we shd be in posn to incorporate not any phase 2 requirement.
Please let me know how I go about this. I have an idea of maintaining two different solution in the VSS. But is that possible to have strong name and version it ?
There are ASPX file also can I version it that also ??
Regards
Srinath
|
|
|
|
|
I'm not certain I'll have the exact answer you're looking for, but I'll mention a few things here (also not entirely certain I know what it is you are looking to achieve) ...
If you're using VSS, lock your code down and branch the solution/project. You'll then have a version 1.x.x.x branch and a version 2.x.x.x branch; course, you have to name them yourself.
In the application AssemblyInfo.cs file, you can specify the AssemblyVersion there. By default, it's specified as version ("1.0.*"), and the compiler automatically increments the minor build numbers. Once you've branched your code out, change that to ("2.0.*"); and so on ...
Also, you can create an AssemblyKey file that's different for each release. This is also contained in the AssemblyInfo.cs file that's part of your main solution.
Perhaps if you explained what it is you want to have happen, or not have happen, I could better point in the correct direction(?) ... maybe.
Hope some of that information helped ... 
D.
|
|
|
|
|
Why should he use a different key pair for each release? This, in effect, identifies you as the company. Maintaining version bindings between releases is done using the <runtime> section of the .config file, or using a publisher policy assembly installed in the GAC.
I mean, I agree with the rest of the stuff, I just don't get the latest direction.
It's sort of like Authenticode; you buy an X.509 certification with the right extensions and sign your code with it. It identifies your company - much like assembly key pairs, except X.509 can be traced by easily to the source.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Heath,
Yes, this was my mistake and failure to properly explain Strong Name Key signing, thank you for pointing out this error. In hind sight, I'm not certain what I was trying to communicate regarding signing of his assembly ... it appears he's provided more information, so I'll have to review that before more information can be provided.
Thanks again for pointing this out,
D.
|
|
|
|
|
Douglas,
Thanks for the solution.
Let me explain you my requirement more elaborately.
I have a solution which contains 4 projects. Now we need to freeze the current version(say i freeze to ver 1.0.0.1). There might be some requirement changes with respect to ver 1.0.0.1.
Now there are set of new requirements coming up for the same solution. I dont want to touch prev version, I want to create a new version. Which can hold the new changes.
So changes /bug fixes with respect to ver 1.0.0.1 should not tamper ver 1.0.0.2 (my second ver 2)
Client shd be able to see changes w.r.t ver 1.0.0.1 after all they are god to us. 
hope you got my problem
So please help me
Regards
Srinath
|
|
|
|
|
Hi Douglas,
Even if I version it, suppose I make changes in version 1, Can I replicate the same in version 2 during the release. Since version 1 goes for some changes I need to have those changes in version 2 only during the final release.
hope you got it. hope I am not bugging you
Regards
Sri
|
|
|
|
|
Sri,
If I'm understanding you correctly, your concern is with having to maintain two different releases. Meaning, your client will have version 1.0.0 at their site while you're working on the next release 2.x.x ... during this time, the client could encounter bugs/design flaws, which you'll have to fix in their build and make a point release (1.0.1) and you want a way to replicate that 'fix' into your 2.x.x code ...
There is a way to do this using VSS, however, it is often times more complex than just cutting and pasting your fixed code between the two releases. VSS provides a means to "share" branched code between releases. If the code segment is not different between your branches, then your "replicate my fix between versions 1.0.1 and 2.x.x" would work. HOWEVER, if you've modified that code segment already for your 2.x.x release, then that segment is no longer 'shared' and you would have to manually copy your fix between releases. You can find more information on this concept in the VSS help system (look at Shared code and Branching); you may have to read the help installed on the VSS server, since I believe branching is an VSS Admin function ... (you'll have to figure this out yourself).
It is my personal opinion, however, that it is far easier, and a better practice, to make your fix in your version 1.0.x code base and then manually copy that fix over to your 2.x.x build. When you turn your code over to your QA group, they should regression test all those 1.0.x point release fixes you made, in the newer 2.x.x build, to ensure they are indeed fixed. Doing this, also helps ensure that (1) the bug was actually fixed as thought and (2) that newer code introduced in your new build has not directly affected your previous fix (not that this would ever happen ...) 
That's my two cents,
D.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
