Discussions

Bass said:

in C# I do

 

 

if (blah)

{

}

else

{
}

 

Which I guess is the "Java" syntax which seems to be commonly used in C#.

 

Basically curly bracket on each line:

 

in C I do

 

if (blah) {

} else {

}

 

Which is the Linux/K&R syntax used in most POSIX software.

 

Basically I just follow the convention I see in most C# code, and most C code. Although, Mono C# code has it's own distinct style which is based on K&R syntax. To some C# developers reading Mono code looks almost like an alien language.

Originally, Sun's Code Conventions (1997) mandated 1TBS for Java... so it's not likely that the commonly used C# formatting was influenced by that.

TommyCarlier said:

Ion Todirel said:

*snip*

No, he's right: it's a clever syntax hack. However, quality code should not be clever, it should not be a hack. It should be clean and easy to understand/maintain.

We should all put more effort in trying to make our code more readable and maintainable... out of respect for those who will have to maintain it a few years later. Working on someone else's code is not a very exciting experience to begin with, at least we should try hard to prevent it from being miserable.

Hacks are fascinating (and so is obfuscated code if you are so inclined), but they are dangerous. In the case at hand, it might not be immediately evident the difference between:

while (x-->0) and while (0<--x)

Use both in the same stretch of code and you can be sure to get enough curses to last you for the next decade.

ScottWelker said:

Sabot said:

*snip*

I'm with you Sabot - column - but I gave up my strong opinion long ago. I go with whatever my client prefers.

1TBS here, for no particular reason except that I'm too lazy to change. But I can still adapt, when there is a requirement to do so... too bad that the C++ editor in VS doesn't have all the options of the C# one.

stun said:

fpsdean said:

*snip*

Don't know how this old thread from November 2008 came to the top of the thread list.

But I hope the Original Poster is happy with the Windows 7.

 

I know I'm very happy with Windows 7. Loving it

Spam happens.

spivonious said:

Blue Ink said:

*snip*

Does SQL Server cache queries without looking at parameter values? That surprises me, since parameter values will likely change and would even lead to bad results and/or inefficient execution plans.

The problem is that it does look at the parameters that are passed at the time the query is cached. There are heuristics that can trigger a recompilation of a cached query, but like all heuristics they are not foolproof.

Some nitty-gritty details are in the technet article I linked earlier (the full title is Batch Compilation, Recompilation and Plan Caching Issues in SQL Server 2005).

harlock123 said:

spivonious said:

*snip*

The thing is that simply adding AND 1=1 to the where clause makes the problem disappear.

The sql code works perfectly in Query manager also.

 

MemberID is in the TBLMEMBERSPECIALPOPULATION

 

Damn strange for sure.....

 

 

As far as I know, the .NET engine does nothing special to your command... it should only format the request and pass it on to the server for processing.

What I believe might be the problem here, is the one that goes under the name of "parameter sniffing". Most of the documentation you can find on the subject is about stored procedures (that's how I found about it), but it applies also to any query that could be effectively cached.

In a nutshell, what happens is this: whenever you send a query to SQL, the query gets compiled. Since that takes time, SQL server tries to cache the queries it compiles so it doesn't have to do it every time. So far so good.

The rub is that the execution plan of the query gets optimized using the parameters that are passed the first time around. These values may lead SQL Server to create an execution plan that is highly optimized for a trivial case, but that is simply awful with different values. This also explains why the query gets apparenty "fixed" by inserting a silly condition like "AND 1 = 1": since the query changed, the cached query can no longer be used and a new plan is created and that could be much better than the cached one.

EDIT: this might also explain why the query behaves differently interactively: even if the query is the same, you probably passed in the values directly instead of going through parameters. That should be enough for SQL Server to see it as a totally different query.

You may want to add some query hinting (I'm thinking of OPTIMIZE FOR UNKNOWN, but I don't know if that applies to your case).

spivonious said:

Thanks Exo, I'll take a look at that.

 

My interface now starts to update, but I eventually get an "Object of type 'System.Object[]' cannot be converted to type 'System.String'" out of mscorlib. Since the only place I'm using an Object[] is in my Dispatcher.Invoke calls, it has to be something there. Why on earth would it be trying to convert it to a string?

Sorry if I'm missing something obvious... but why don't you use lambdas instead of passing arguments to Invoke?

Dispatcher.Invoke((Action) (() => MyMethod(argument1, argument2, argument3)), DispatcherPriority.Whatever);

Never checked how it fares in terms of performance, but it feels much easier to me.

It may seem a not very ambitious request, but what I would like to see in C# is the ability to declare variables in the guard expression of some statements. Some usage examples:

while ((int bytesRead = stream.Read (buffer, 0, buffer.Length)) > 0) {

   outStream.Write (buffer, 0, bytesRead);

}

if ((IDisposable d = someObject as IDisposable) != null) {

  d.Dispose ();

} else {

  Console.WriteLine("Cannot dispose objects of type {0}", d.GetType().Name);

}

switch (char c = charReader.ReadChar()) {

  case 'a':

  case 'b': {

     return c;

  }

  ...

}

It would prevent some name pollution and make porting code from C/C++ easier.

spivonious said:

Blue Ink said:

*snip*

I took another look at my calls to Dispatcher.Invoke and found something strange.

 

Intellisense tells me "delegate, priority, args".

 

My code was "priority, delegate, args" because that's how Bea Stolnitz's blog had it.

 

Changed it around and now I'm getting some other errors. Maybe that was it? Why would it even compile if the arguments were in the wrong order?

Both versions exist (you may have noticed that if you hover on Invoke, you get a tooltip with "+9 overloads").

Yet, Intellisense only show four of them, as the other six have attributes that hide them ([Browsable(false), EditorBrowsable(EditorBrowsableState.Never)]).

It has been like that since .NET 2.0, so there must be some good reason for the hidden overloads, but I fail to see what that might be.

spivonious said:

Okay, I turned on .NET source debugging and now I'm getting two exceptions.

 

The first seems to be unrelated, and just something in the test container:

 

First-chance exception at 0x7c812afb in UserControlTestContainer.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..

 

If I click Continue the app runs for a while and then I get another exception. This is what brings the app down.

An unhandled exception of type 'System.Reflection.TargetParameterCountException' occurred in mscorlib.dll
Additional information: Parameter count mismatch.

 

Any ideas?

 

 

edit - just ran it again, didn't get the second exception, and the app still crashed. It seems to go down right before the WPF control would be shown. I wish I could run this in VS2010, but the Oracle Data Provider doesn't show up in the provider list, since MS changed how providers are listed in the registry.

 

edit2 - okay, I attached VS2010's debugger to the running app and caught the second exception above. It's got to be that.

 

edit3 - could it be something with the Dispatcher? It seems to get the error after everything processes but before the interface is updated. I basically made a subclass of ObservableCollection that holds a reference to the Dispatcher and performs a CheckAccess before each method call. If it has access it calls the base operation, if not it does a BeginInvoke for the method.

I don't know if that's your case, but you will get a System.Reflection.TargetParameterCountException if you call Dispatcher.Invoke passing the wrong number of arguments for the delegate.

Personally, I use lambdas. This way I can get the compiler to check the parameters and intellisense.