|
This is the implementation of File.CreateText(string):
public static StreamWriter CreateText(string path) {
if (path == null) {
throw new ArgumentNullException("path");
}
return new StreamWriter(path, false);
}
and this is the implementation of StreamWriter(string, bool) that is uses:
public StreamWriter(string path, bool append) : this(path, append, StreamWriter.UTF8NoBOM, 0x400) { }
and this is the implementation of StreamWriter(string):
public StreamWriter(string path) : this(path, false, StreamWriter.UTF8NoBOM, 0x400) { }
So, they are two different paths to the exact same place.
---
single minded; short sighted; long gone;
|
|
|
|
|
I'm trying to send numbers over the serial port as bytes, not strings.
What I mean is if I want to send a 255, that should be 1 byte, not a 2
followed by a 5 and a 5. I'm trying to convert a borland c++ app.
This is what the c++ app does
int8B = 255;
WriteFile(serialPort,&int8B,1,&bytesWritten,NULL);
int8 = gainSlider->Position;
WriteFile(serialPort,&int8,1,&bytesWritten,NULL);
int8 = offsetSlider->Position;
WriteFile(serialPort,&int8,1,&bytesWritten,NULL);
int8 = exposureSlider->Position;
WriteFile(serialPort,&int8,1,&bytesWritten,NULL);
Here is what I'm doing that does not work
int x = 255;
sp.WriteLine(String.Format("{0}", x));
sp.WriteLine(String.Format("{0}", trackBar_Gain.Value));
sp.WriteLine(String.Format("{0}", trackBar_Offset.Value));
sp.WriteLine(String.Format("{0}", trackBar_Exposure.Value));
How do I send the 255? I can't do sp.WriteLine(255) since it wants a
string.
any help will be greatly appreciated.
Ringo
|
|
|
|
|
You could try to build a string that holds the right bytes (using Encodings and stuff),
but then why bother; under NET 2.0 SerialPort class has the method
public void Write (byte[] buffer, int offset, int count);
that AFAIK will do what you need.
Luc Pattyn
|
|
|
|
|
1. casting:
Foo foo=(SomeType)myFooishObject;
vs.
Foo foo=myFooishObject as Foo;
2: type comparing:
if (foo.GetType()=="Foo")
vs.
if (foo is Foo)
Under which situations would you use one or the other options for #1 and #2, and why?
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
Hello Marc,
Marc Clifton wrote: Foo foo=myFooishObject as Foo;
This is my solution for #1 and #2. (for #2 followed by "if (foo!=null)"
Marc Clifton wrote: and why?
"as" never throught an exception and prevents me of making double Type compares.
All the best,
Martin
|
|
|
|
|
I'd go with option B for each. In case 1 it avoids a possible exception for invalid cast. In case 2 it avoids the string comparison and the fat finger syndrome.
only two letters away from being an asset
|
|
|
|
|
B for the first if I think about it, A if my C++ autopilot is running unchecked.
B for the second, I never even thought of doing the former.
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Hi Marc,
For value types:
- I typically do not use is nor as.
- I use casting to document widening, or to steer narrowing the (int) size, or to switch
between signed and unsigned.
- and of course I try not to need casting at all (by selecting the right type to begin with).
For reference types:
- I avoid GetType(), it is too expensive and somewhat clumsy
- I avoid using casting, with two typical exceptions: when getting an "object" either
by cloning something with Clone(), or when retrieving from a non-generic collection.
(I still try to write code that also could run on 1.1)
- If a ref type must be turned into a more specialized one I tend to use "as" and a null test
(unless "is" is all I need); a null test often already is present anyhow.
BTW: I like your FooishObjects !
Regards,
Luc Pattyn
|
|
|
|
|
Marc Clifton wrote: Foo foo=(SomeType)myFooishObject;
This is a regular cast, normally used to tell the compiler as what type it should treat the object, or for converting between simple data types (for example converting a byte to an int). If the object is not possible to cast to the specified type, you get an exception.
Foo foo=myFooishObject as Foo;
This is used if you are not certain what the actual data type is. If the cast is possible, you get a reference of the given type, otherwise null. To check if the cast was successful, you just check for null.
if (foo.GetType()=="Foo")
I suppose that you mean: if (foo.GetType().Name=="Foo")
This creates a Type object, gets the type name as a string and compares to the literal string. This might be useful if you use a variable instead of a literal string, as that is the situation where you can't use is to check the type.
if (foo is Foo)
This is a more straight forward way of checking the type. It's more efficient than comparing strings.
---
single minded; short sighted; long gone;
|
|
|
|
|
Marc Clifton wrote: Foo foo=(SomeType)myFooishObject;
When I *know* that myFooishObject is convertible to SomeType.
Marc Clifton wrote: Foo foo=myFooishObject as Foo;
When I am *trying* to use myFooishObject as it was Foo, but I am not sure.
Marc Clifton wrote: if (foo.GetType()=="Foo")
When type of foo is not known, or doesn't exist at all at compile time.
Marc Clifton wrote: if (foo is Foo)
When I want to know if foo is of type Foo, but I don't need to work with it as type of Foo later.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
#1: It depends whether you want an exception or a null.
#2: Unless you're doing something *very* specific (e.g., reflection), both are equally bad. Whatever you put inside the "if" should go into a foo's virtual method or interface method. And the first method is actually wrong, may bite you as soon as you have the same type name (e.g., "Customer") on two different dlls (happens very often, specially when one uses namespaces and/or abstraction layers).
|
|
|
|
|
Daniel Turini wrote: And the first method is actually wrong, may bite you as soon as you have the same type name (e.g., "Customer") on two different dlls (happens very often, specially when one uses namespaces and/or abstraction layers).
A most excellent point.
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
Hello everyone,
I really hope someone can help me out as this is a major break point in my development process. I've been googling for info to no avail, and sadly my knowledge reaches a certain extent, being self-taught.
I've been working with IL lately, and I came to the point where optimization was needed (since I'm working in a real-time 3d environment).
The code - which was working (thanks to S. Senthil Kumar) - contained ldarg_0 instructions. Too many in my opinion, since the argument was already loaded onto the stack, as far as I know.
I was passing to the dynamic method an object array (defined as params object[] in the delegate).
Argument: object[] objectParams
<code>ldarg_0
ldc.I4 0
ldelem_ref
call (calling some method included in the objectParams[0] object)
ldarg_0
ldc.I4 1
ldelem_ref
call (calling some method included in the objectParams[1] object)
...</code>
This code worked. As I stated above, I needed to optimize this, since I found pretty useless to reload the argument every time I switched to the subsequent array item.
I decided to have a static field in my static class which contained that object array, instead of passing it to the dynamic method.
m_MyField is a FieldInfo reference to this object array. I can safely obtain it, it's not null.
Code:
<code>ldsfld m_MyField
ldc.I4 0
ldelem_ref</code>
So, I should have three values in my stack, in this sequence: m_MyField (object[]), 0, m_MyField[0]
If I were to pop twice, the current value in the stack should be m_MyField, right?
So that this could would be right:
Code:
<code>ldsfld m_MyField
ldc.I4 0
ldelem_ref
call (some method contained in the referenced object)
pop
pop
ldc.I4 1
ldelem_ref
call (some method contained in the referenced object)
pop
pop</code>
As you can see, there's only one ldsfld instruction, and then two pops, in order to get back to the object array. Sadly, this is not working. I am assuming that ldarg_0 works just like ldsfld in order to get that specific object array.
Here's a ILStream excerpt:
<code>IL_0000: ldsfld System.Object[] m_MSILMethodTemporaryParamField/Dreams.PlugInManager
IL_0005: ldc.i4 0
IL_000a: ldelem.ref
IL_000b: call Void PreRender()/Dreams.UserInterface.UserInterface
IL_0010: pop
IL_0011: pop
IL_0012: ldc.i4 1
IL_0017: ldelem.ref
IL_0018: call Void PreRender()/Dreams.UserInterface.UserInterfaceEditor
IL_001d: pop
IL_001e: pop
IL_001f: ret </code>
Any help is much, much appreciated.
Thanks for your time.
|
|
|
|
|
Hi,
isnt the method you call popping all its args ??
If so, you could contemplate a "duplicate" before the call.
if not, are you sure it is not modifying the stacked values ?
At a more macroscopic level: are you sure a few loads will be noticed amongst those
calls ? I expect call to be more expensive than load, and unless your called method is
extremely short, the loads wouldnt matter much...
Hope this helps.
Luc Pattyn
|
|
|
|
|
Hello Luc,
thanks for your reply.
I will consider what you wrote about the loads.
Can you please extend what you mean with a "duplicate"?
I don't know if other variables will remain into the stack after the calls,
I'll check further into this.
Thanks again!
|
|
|
|
|
Hi Roberto,
I dont know MSIL in detail, but some stack oriented machines have a "duplicate" or "dup"
instruction that just duplicates "top of stack" (I know PostScript has it).
If there is, it may be cheaper than a second load.
BTW I forgot the most obvious tip of all: if the method you call is short, you should
inline it (and if its long, then thats where you should optimize).
Regards,
Luc Pattyn
|
|
|
|
|
hi,
Is there a way to notify the windows application if an insert or update occurs in the database.I don't want to use polling.
people laugh at me because they say im different and I laugh at them because they are all the same.
|
|
|
|
|
|
Thanks for the reply this is what i was looking for
But is it possible to receive notification message when database is in unix environment and your .Net application is in windows environment?
people laugh at me because they say im different and I laugh at them because they are all the same.
|
|
|
|
|
If you are running SQL Server in a UNIX environment it is.
only two letters away from being an asset
|
|
|
|
|
I thought of a nice way to clear all textboxes in an application: run a loop from 0 to Controls.Length (because Controls is the array that contains all the controls in the form) and check that if the control is a textbox then clear it...the problem is how do i check it?
I tried stuff like if (Controls[i] == TextBox) and similar stuff but nothing worked. how can i do it then?
|
|
|
|
|
hi
try this:
<br />
foreach (Control c in Controls)<br />
{<br />
TextBox t;<br />
if ((t = c as TextBox) != null)<br />
{<br />
t.Text = "";<br />
}<br />
}<br />
Greets
M@u
|
|
|
|
|
foreach (Control c in Controls)
{
if (c is TextBox)
{
(c as TextBox).Text = "";
}
}
life is study!!!
|
|
|
|
|
thx for the help you all :P
btw, better way 
for (int x = 0; x < Controls.Count; x++)
if (Controls[x] is TextBox)
Controls[x].Text = "";
|
|
|
|
|
Hello,
sharpiesharpie wrote: btw, better way
I don't agree with you at all.
It only works because Text is a member of Control, if you later need a member of Textbox you would have to change your code again.
I would take the first solution "m@u" posted, (with the "as" conversion and "!=null" check)
sharpiesharpie wrote: if (Controls[x] is TextBox)
Controls[x].Text = "";
Two access over an indexer is also not a "better way".
All the best,
Martin
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
