|
Has MS made any thoughts on when/if a 64 bit version might happen more recently than a half dozenish years ago?
At the time the VS PMs reason for not doing it was that it wouldn't actually help scaling to larger solutions much because hitting the 4GB limit was always due to an algorithm/datastructure that was O(n^2) or worse, meaning that a 64 bit version would only let things get a tiny bit bigger before hitting the wall again, and that finding the performance/memory bottlenecks and rewriting them to be O(n) or O(n log n) would have much bigger returns than exhaustively reviewing/fixing the entire codebase to make sure everything was 64bit pointer safe. At the same time he did say that any module being worked on was being made 64bit safe, with the intent of gradually reducing the size of the remaining 64 bit conversion until doing so was justifiable in terms of the amount of work it'd require (vs spending the labor on other features local optimizations).
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
A Visual Studio PM was replying to comments in the blog post talking about VS2019.
He said that the consider the pros and cons of going 64 bit before each release, and theyève decided not to do it for VS2019.
I know that's not exactly a thought from MS on when 64 bit Visual Studio might happen. But it's at least a thought from MS on when it won't happen. 
|
|
|
|
|
Thanks for that. I read the blog but didn't slum into the comments to see if there was anything interesting posted.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
No it isn't.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
Mention "goto" to many programmers and they'll say, "Never use them, they lead to spaghetti code." It's a conditioned response. It seems to be a definition - "Dad, what's for dinner?" - "We're having goto." - "Again?". Ask them to explain why it is so bad, and you'll likely get a blank stare, or they just chant "spaghetti, spaghetti, …" Of course, a misused goto can lead to spaghetti code, but a (misused) [any reserved word] can lead to [some bad thing]. Have we developed an irrational fear of goto born out of ancient coding dogma? Or is goto inherently and absolutely evil?
Update: As suggested by englebart, I'm adding why I asked this question.
It came out of a recent discussion. I was reviewing some code someone showed me (they didn't write it) that had a goto in it. He said the code was Spaghetti Code. When I asked why, he said because it had a goto. I asked why that made it spaghetti, and all he could come up with was that he was taught that. I asked about a few other "programming truths", and had much the same response. This is good, that is bad, but I don't really know why. I started thinking about how for some things, aspects of programming have become more faith than science.
modified 8-Jun-18 8:46am.
|
|
|
|
|
It creates functions which are strictly monolithic. It's not bad but it create impediments in further expansions or refactorizations of the function that uses it.
Goto to code outside the function containing it is problematic for the compilers, breaks modularity in C code as much as global variables do, and is completely undoable in OOP due to context changes.
All in all it may be a good solution but ultimately not worth the delayed troubles if not under very constrained circumstances.
GCS 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--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I would say your examples are good examples of misuse, and not problems with goto itself. I don't use goto myself, except in rare cases to short-circuit a function.
|
|
|
|
|
That's a nice spot to use goto, I have used it twice in my life precisely for that: later I ended up removing them due to a refactor that improved every aspect of those functions (performance, readability, debuggability).
That said, I don't discard it out of hand as it is a powerful tool. As TNCaver said "You think goto is evil: try writing Assembly programs without JMP" (it has been in my signature for years... and I do also write Assembly code so it was really appropriate).
GCS 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--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
You can use goto to short-circuit time-constrained algorithms for academic or scientific purposes.
Don't use it anywhere else, especially not in a professional setting, or people will be strongly compelled to gut, rape and murder your code the first chance they get.
And can you really blame them for it?
|
|
|
|
|
den2k88 wrote: breaks modularity in C code
That is true for C, but not so much for C++. goto is context dependent in C++, it will call appropriate constructors/destructors. When used in local context it will not make the function/method monolithic. So if goto is so bad, you might be using a badly outdated language?
|
|
|
|
|
Plamen Dragiyski wrote: goto is context dependent in C++, it will call appropriate constructors/destructors.
Which is an Access Violation waiting to happen when the code changes.
Plamen Dragiyski wrote: So if goto is so bad, you might be using a badly outdated language?
And that would be?
GCS 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--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: Which is an Access Violation waiting to happen when the code changes.
How? If jumping outside block can causes access violation, then every "}" is potential access violation.
If you talk about inter-scope goto, that's is entirely different story. You can do that in C using signals. What will be the state in C++ after such goto it is indeed unknown, so that's one possible misuse of goto. But if all affected variables are on the stack (and in C++ they should be - all pointer should be wrapped into appropriate *_ptr object allocated on the stack), jumping outside of scope is completely safe. Jumping inside non-conditional scopes is also safe. Jumping inside anything else is a bad idea.
Jumping outside scope, can be realized by do-while wrapping:
do {
} while(false);
But it cannot be used inside loop/switch statement and it is utterly more ugly than goto.
|
|
|
|
|
den2k88 wrote: Which is an Access Violation waiting to happen when the code changes.
And you are claiming that cannot happen without gotos?
Or if those others occur they can only occur when another feature of the language is used correctly?
|
|
|
|
|
Looking to some MSDN examples, I never saw goto, I only saw things like this (also a kind of goto):
....
while(true)
{
if (!Method_1())
break;
...
if (!Method_N())
break;
...
}
...
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
There are gotos in the source code for C# in places.
|
|
|
|
|
Hi,
RandyBuchholz wrote: It's a conditioned response.
That's exactly what it is. A few years ago I had to use some goto statements in a device driver written in C where the push/pop function prolog/epilog[^] was causing a performance reduction of between 30% - 40%. I could not find anything that matched the speed of the goto statement and left it in the production code.
High-performance code is almost always ugly.
RandyBuchholz wrote: Or is goto inherently and absolutely evil?
I would say that you do not need a goto statement 99.999% of the time. But I have used it at least ONE time in the past two decades where I feel it was necessary.
Best Wishes,
-David Delaune
|
|
|
|
|
I do not use goto in C++ programs while I use it in C ones. I do abuse of gotos in assembly code.
|
|
|
|
|
RandyBuchholz wrote: Have we developed an irrational fear of
Speak for yourself.
Just look what I'm working on right now. Every opcode that starts with B is a branch (= goto).
; =========================================================================================
; BIOS Command selection
;
; Parameters:
; ---
;
; Returns:
; ---
; =========================================================================================
BIOS_Command: LDI hi(TxtEnterCommand)
STXD
LDI lo(TxtEnterCommand)
STXD
SEP R4
dw WriteLine
CMD_Repeat: LDI 00FFH ; get RS232 input, max. timeout
STXD
SEP R4
dw RS232InSoftware
IRX ; timeout?
LDX
BZ CMD_Skip
STXD ; echo input
STXD
SEP R4
dw RS232Out
IRX
LDX
SDI 006EH ; test input = n
BZ CMD_Exit
LDX
SDI 0079H
BNZ CMD_Repeat
LDI hi(TxtNewLine) ; announce BIOS CMD
STXD
LDI lo(TxtNewLine)
STXD
SEP R4
dw WriteLine
LDI hi(TxtNewLine)
STXD
LDI lo(TxtNewLine)
STXD
SEP R4
dw WriteLine
LDI hi(TxtCmdTitle)
STXD
LDI lo(TxtCmdTitle)
STXD
SEP R4
dw WriteLine
CMD_Prompt: LDI hi(TxtCmdPrompt) ; output the prompt
STXD
LDI lo(TxtCmdPrompt)
STXD
SEP R4
dw WriteLine
LDI 00H ; get RS232 input, no timeout
STXD
SEP R4
dw RS232InSoftware
LDI TRUE
PLO RF
IRX ; echo input
LDX
STXD
STXD
SEP R4
dw RS232Out
IRX
LDX ; test input = x
SDI 0078H
BZ CMD_Exit
LDX ; test input = X
SDI 0058H
BZ CMD_Exit
LDX ; test input = h
SDI 0068H
BZ CMD_Help
LDX ; test input = H
SDI 0048H
BZ CMD_Help
CMD_Invalid: LDI hi(TxtCmdInvalid) ; error message (invalid command)
STXD
LDI lo(TxtCmdInvalid)
STXD
SEP R4
dw WriteLine
BR CMD_Prompt
CMD_Help: LDI hi(TxtCmdHelp) ; help text
STXD
LDI lo(TxtCmdHelp)
STXD
SEP R4
dw WriteLine
LDI hi(TxtCmdHelp1)
STXD
LDI lo(TxtCmdHelp1)
STXD
SEP R4
dw WriteLine
BR CMD_Prompt
CMD_Skip: LDI hi(TxtSkipped)
STXD
LDI lo(TxtSkipped)
STXD
SEP R4
dw WriteLine
CMD_Exit: SEP R5
;------------------------------------------------------------------------------------------
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I have no fears! 
My education is EE, and I still see registers (68xx architecture) in my head no matter what language I'm programming in. I don't actually see the code that way, it's just kind of a background image. It's amazing how many developers don't know that the only branching a CPU has is a goto.
|
|
|
|
|
Even one as unconventional as this one here.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Sacrilege! You will goto hell for such thoughts!
Oh wait. Even hell has been refactored: while (true) burnInHellForever(); 
|
|
|
|
|
Not:
Quote: while (true) burnInHellForever();
while (false) burnInHellForever();
"true" believers go to heaven! 
|
|
|
|
|
I've not used the goto keyword in any of my C/C++/C# code over the last 20 years or so.
I routinely use break (goto's more civilized brother, as it were) to exit for loops early. I do this in cases where expressing the iteration as a for loop is more appropriate for the general case, and the break handles the exceptions. I don't tend to use continue nearly as much in similar situations; I'm not sure why.
I dislike when code uses exceptions as an exotic form of iteration/flow control. My least favorite mechanism would have to be setjmp()/longjmp(), which is a very old C runtime library mechanism that fortunately doesn't see a lot of use today.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
