|
Obviously, but it's not something I like to do because what's being tested and validated is Main2 and not Main. It did happen that seemingly harmless test code broke or unbroke some behavior in the test subject so I try to avoid it as much as possible.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
Another option is to set the startup object in the project settings. That way you can have two mains, and call the second from the first. It doesn't entirely solve your problem, but it's an option.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
|
If only I could install anything (I managed to install VS before they took away that privilege).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
den2k88 wrote: And the breakpoint after the parsing moves the focus to the VS window hiding the Command prompt.
Well at least that one's easy to fix, get another monitor and reshuffle your windows around so they don't overlap.
It's really nice to have an unobscured view of the IDE open on one monitor, then a browser / console / Explorer windows on another, alongside a bunch of debug windows (locals / watch windows / output window / etc).
I typically RDP into my dev VM using a 4K monitor and a 1080p one, and that's my sweet spot. Although sometimes I could use a third.
[Edit]
Also - everything you pointed out in your message has to do with the editor - not language limitations and the like. So, it's a bit unfair to blame C# for any of this. I wonder if VS Code behaves better under the circumstances you describe...or third-party editors?
modified 28-May-24 11:39am.
|
|
|
|
|
dandy72 wrote: Well at least that one's easy to fix, get another monitor
No space, on my lab desk (the only place where I can debug) I have the specimen cage, and very large power supply (it has to provide up to 170 Amperes at 60V). I have barely enough space to cram the closed laptop between the power supply and the base of the monitor, especially because I also have a fixed drawer cabinet that forces the ergonomic position only barely where the monitor is.
Plus the laptop has a single HDMI port anyway and the docking station is available only in the office desk, not le lab one.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
den2k88 wrote: Plus the laptop has a single HDMI port anyway and the docking station is available only in the office desk, not le lab one.
I was gonna say, there's USB to HDMI adapters, but I see you have bigger (physical) problems to deal with.
I can sympathize. My desk is L-shaped; 5-feet long on the shorter end, and 8-feet long on the other. I couldn't find a spot to put a standard 8.5" x 11" sheet of paper to lay flat to write on.
|
|
|
|
|
den2k88 wrote: And the console does not stay open (yes the checkbox is unchecked, also ignored by VS).
You can run a command line tool in a Process. And then feed what ever you want to the command line and then collect the output. So build a testing harness.
Alternatively I used 'AutoIt' to test console apps some years ago.
|
|
|
|
|
|
Probably because it was modelled on languages which do allow execution to fall-through, and without an explicit break / return , early adopters might have thought the C# code was falling through.
[Proposal] Case fall through should be allowed · dotnet/csharplang · Discussion #603 · GitHub[^]
See also Eric Lippert's comments on SO:
C# enforces the no-fall-through rule in every switch section, including the last one. This is so that switch sections can be re-ordered arbitrarily, possibly by mechanical tools, without introducing semantic changes in the program.
C# enforces the no-fall-through rule by requiring that the end point of every switch section be unreachable. It is not necessary for a switch section to end in a break. It can end in a break, return, goto, continue, throw, or a detectable infinite loop:
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
For the most common scenario it just adds a line of code that has to be written which has no meaning.
It just clutters the code with additional meaningless lines. Bah, or better, !
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
Richard Deeming wrote: detectable infinite loop
Classic! You won't find any of my switch statements without one of those.
Regards,
Rob Philpott.
|
|
|
|
|
As opposed to an undetectable infinite loop?
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
Indeed.
The compiler isn't magic, and there are constructs which are obvious infinite loops to a human which the compiler cannot detect as such.
For example:
switch (x)
{
case 1:
while (x < 42);
case 2:
return 123;
} Whilst we can clearly see that the loop is infinite, since x starts as 1 and is never modified within the loop, the compiler still complains:
Quote: CS0163 Control cannot fall through from one case label ('case 1:') to another
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
In my student days, "correctness proofs" were the rage. Everyone were convinced that soon, a program would be able to prove (or disprove) that a program behaved according to specifications.
The first real proof we learned in that course was not a program, but a logical proof that no program analyzer can, in the general case, detect every possible infinte loop. I did understand the proof then; I don't remember the details today, and even if I found the text, I would probably be unable to explain it to someone unfamiliar with it. But I know the proof exists (just like I know that there exists a proof that you cannot trisect an arbitrary angle); I trust the experts that the proof still holds.
|
|
|
|
|
I agree with a specific "end of case" being required - as Richard quoted, it allows the compiler to spot code faults instead of letting them cause runtime problems.
It may be "unnecessary", but it does trap some errors which could be difficult to diagnose at run time.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It does allow multiple "entry points", so
case 1:
case 2:
Some code
break;
So it can't just assume a break. Sure they can come up with rules for how it would be interpreted, but kind of glad they didn't.
|
|
|
|
|
Personally, I'd have preferred multiple entries to be a different syntax:
case 1,
2,
3:
... code
break;
case 4:
... code
break; Or even:
case 1,
2,
3:
{
... code
break;
}
case 4:
{
... code
break;
} I think it would have been clearer as well as less easy to mess up by adding a new case between them. Perhaps with brackets round the case list as well?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Or even:
case 1,
2,
3:
case 4:
The Pascal style (except for the 'break' statements). I don't like the C# 'No fallthrough except when the case alternative is empty', so I sort of agree with you, although it is not a big matter.
I do upset some people by always using braces, like in your second alternative: Indentation and braces go hand-in-hand. Call it 'two-factor level nesting'. I want to indent the case alternative, so it should be made a block. Blocks are indented. Statements are not, neither single nor multiple statements. In- and un-denting without braces makes a mess of nesting levels.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
You only need braces in the case when you're creating a new variable in the case. Otherwise, they're unnecessary.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I didn't know this (C# is not my main language) and now it makes sense. From the compiler errors I supposed it didn't allow multiple entry points as well, just like VB6 used to do.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
I blame Ken Thompson.
switch should never have had fall-through, break should never have affected switch . That should have been their first clue.
|
|
|
|
|
I blame Ken Thompson for the vast majority of bugs in today's software. The entire concept of null terminated strings and buffers is simply asking for trouble. DEC and IBM both had descriptor-based buffers, which gives the OS calls that manipulate buffers a way to block buffer overflows.
|
|
|
|
|
Nice, but... which OS?
There are no OS where we are going.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
C was just an easier, portable assembly language.
I blame the overflow buffer errors on the chip designers that encouraged storing local variables on the call stack! Call stack pointer should be read only except for jsr and ret instructions.
|
|
|
|