Online C# tests

[babydavy]

I wondered if anyone knew of any online C# tests. I am a VB.NET
programmer and I have been learning C# and I wanted to see if I was
good enough yet to get a job using C#.

Thanks,

David.

[Vadym Stetsyak]

what tests do you mean?

AFAIK there should be no defference in performance as VB.NET and C# compile
to the same IL

"babydavy" <ab*****@hotmai l.com> wrote in message
news:a1******** *************** **@posting.goog le.com...

I wondered if anyone knew of any online C# tests. I am a VB.NET
programmer and I have been learning C# and I wanted to see if I was
good enough yet to get a job using C#.

Thanks,

David.

[chris]

>> "babydavy" <ab*****@hotmai l.com> wrote in message

news:a1******** *************** **@posting.goog le.com...

I wondered if anyone knew of any online C# tests. I am a VB.NET
programmer and I have been learning C# and I wanted to see if I was
good enough yet to get a job using C#.

Thanks,

David.

Vadym Stetsyak wrote: what tests do you mean?

AFAIK there should be no difference in performance as VB.NET and C# compile
to the same IL

I believe he wishes to test his programmatic prowess :-)

--
chris

[Ralph]

"Vadym Stetsyak" <pd****@ukr.net > wrote in message
news:e0******** ******@tk2msftn gp13.phx.gbl...

what tests do you mean?

AFAIK there should be no defference in performance as VB.NET and C# compile to the same IL

One would think that would be true. In a perfect world it should be true,
however, even a cursory comparison of the IL produced by VB.NET against
functionally similar code created using C# will demonstrate unique
differences.

VB.NET will always produce more 'clicks' than C#. Many are just NOPs, but C#
will produce slightly 'leaner' and likely 'faster' code. Just how
significant this difference is in an actual application is often difficult
to measure and likely insignificant.

For example, A switch/case statement that determines which file to read in
maybe 5 'clicks' faster than a VB.NET version - but the time of the overall
process will be dwarfed by the total time to complete the I/O which is
determined by the box and the Framework, and so is equal for both.

So while I have no wish to startup a VB.NET vs C# holy war - it is important
to note that the argument that both produce identical code is not valid.
There are other valid reasons making make a language choice that far
out-weight 'performance' considerations, anyway.

As for online C# tests - testing has become a big commodity and so few free
tests are available. Most of the bigger testing companies (AppDev, ForTest,
etc) do have some online 'sample' tests. But they often change locations - a
deligent Google search should turn up a number of them.

-ralph

[clintonG]

Get the C# MCAD cert training guides from QUEand
subscribe to the practice exam questions via Informit.com.

--
<%= Clinton Gallagher
A/E/C Consulting, Web Design, e-Commerce Software Development
Wauwatosa, Milwaukee County, Wisconsin USA
NET cs*********@REM OVETHISTEXTmetr omilwaukee.com
URL http://www.metromilwaukee.com/clintongallagher/
"babydavy" <ab*****@hotmai l.com> wrote in message
news:a1******** *************** **@posting.goog le.com...

I wondered if anyone knew of any online C# tests. I am a VB.NET
programmer and I have been learning C# and I wanted to see if I was
good enough yet to get a job using C#.

Thanks,

David.

[Bonj]

is it not also the case that VB.NET has simply *more* functions than C# has?
Looking in the SDK documentation it looks like they were the ones provided
to help VB6 users migrate - Shell for instance, VB.NET seems to have it but
C# doesn't (whereas C# would use Process.Start)
I think it's also clear that C# is the 'intended' language to compile to
MSIL, VB.NET seems to be just a VB6-like syntax wrapper round it...
"Ralph" <nt************ *@hotmail.com> wrote in message
news:qK******** ************@ar kansas.net...

"Vadym Stetsyak" <pd****@ukr.net > wrote in message
news:e0******** ******@tk2msftn gp13.phx.gbl...

what tests do you mean?

AFAIK there should be no defference in performance as VB.NET and C# compile

to the same IL

One would think that would be true. In a perfect world it should be true,
however, even a cursory comparison of the IL produced by VB.NET against
functionally similar code created using C# will demonstrate unique
differences.

VB.NET will always produce more 'clicks' than C#. Many are just NOPs, but

C# will produce slightly 'leaner' and likely 'faster' code. Just how
significant this difference is in an actual application is often difficult
to measure and likely insignificant.

For example, A switch/case statement that determines which file to read in
maybe 5 'clicks' faster than a VB.NET version - but the time of the overall process will be dwarfed by the total time to complete the I/O which is
determined by the box and the Framework, and so is equal for both.

So while I have no wish to startup a VB.NET vs C# holy war - it is important to note that the argument that both produce identical code is not valid.
There are other valid reasons making make a language choice that far
out-weight 'performance' considerations, anyway.

As for online C# tests - testing has become a big commodity and so few free tests are available. Most of the bigger testing companies (AppDev, ForTest, etc) do have some online 'sample' tests. But they often change locations - a deligent Google search should turn up a number of them.

-ralph

[Ralph]

"Bonj" <[e-mail]> wrote in message
news:eD******** ******@TK2MSFTN GP12.phx.gbl...

is it not also the case that VB.NET has simply *more* functions than C# has? Looking in the SDK documentation it looks like they were the ones provided
to help VB6 users migrate - Shell for instance, VB.NET seems to have it but C# doesn't (whereas C# would use Process.Start)
I think it's also clear that C# is the 'intended' language to compile to
MSIL, VB.NET seems to be just a VB6-like syntax wrapper round it...

[snipped]

A good observation, but I was referring to simpler constructs where more
even comparisons might be made. But you are correct that many VB.NET "ways"
are perhaps generally just plain "wordier" than similar C# constructs. But
even that gets confusing since several VB-leaning friends have demostrated
to me that often what appears as more VB code 'compiles' to a more compact
C#-like version in IL.

It also doesn't take long when directly working with the IL to appreciate
that neither VB.NET or C# truly utilizes all the capablities of the IL. Most
of the new language features that are coming with W'mb aren't based on a new
IL, just better exploitation of what is already available.

Which is leads to an interesting cottage industry which is cropping up -
writing a program/routine in either VB.NET or C#, then opening the IL and
tweaking it. While many of the practictioners believe this to be an original
idea, it is almost exactly what we use to do 20 years ago in C. Write the
basic routine in C, then dump the assembly, tweak it, then include the new
code as an _asm instruction or as a separate library. It seemed like a nifty
idea at the time - but ghod help the poor maintainer than came behind you.
<g>

I believe your observation that VB.NET does tend to maintain a VB-ness to it
is correct and deliberate, and believe this trend will continue. Just as it
is more likely that C# will evolve to a more direct exploitation of the IL.

That is why I felt the need to comment on the "identical" IL issue. It isn't
true now and will likely be even less true with W'mb. (Then we get a whole
new round of language wars. <smile>)

But that is only an opinion and I am often wrong.

-ralph