|
I have no idea, but I feel bad that it hasn't been solved, so I am going to throw out my best guess (even though it's probably 2 words, not one).
Candycanes
C = One hundred
andy = (Warhol) pop artist
canes = sticks
Although knowing your trickery, I expect "sticks" is more about being sticky like toffee - but I got nowhere with that angle.
|
|
|
|
|
CANDYCANES is correct!
You are up tomorrow!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Damn, wasn't expecting that to be right... go me 
|
|
|
|
|
So right now my little mini C# subset does not support a lot of really convenient operators
like most of the op+assignment operators (+=,-=,/=,*=) nor does it support either post or pre increment or decrement operators (++a, a++, --b, b++)
The reason it doesn't is because the CodeDOM it renders to does not.
The primarily annoying this is it forces you to declare your for loops like this:
for(int i = 0;i<10;i=i+1)
that takes some getting used to.
Now here's the thing, I can simulate these operators with other equivalents. Like, every time I see a ++a, i can turn it into a=a+1
But the problem is, it's not exactly the same thing. What if someone has overloaded ++?
All of the sudden your code will not run the target ++ code and why could be very confusing unless you're willing to pour over God only knows how many lines of generated source code it created.
So that's why I don't do it.
Eventually, I may, if I decide to make this generated code forcibly call the static operator overload methods (like op_Increment()) exposed from the target type, but right now that's a long out to do. But doing so would keep the semantics. even then i can probably never support i++, only ++i, but that's a longer story.
My question is this - am I being too much of a stickler here? Should I just go ahead and remap these operators and say to hell with the minor semantic change it introduces? Or should I remain conservative in this respect?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It depends on what you want to do with your solution. If you are the only one who will ever use it, then you can do as you want. But if you plan one someone else using it, then you'd better implement these operators. If you don't, then expect a bad reaction from people when they will realize that they cannot use increment/decrement operators, or if they can use prefix increment/decrement but not postfix ones, or the other way around.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
 I guess that means implementing the op_XXXXX calls then.
Hateful VB. That's the whole reason for this mess. VB doesn't support these operators so the CodeDOM doesn't.
Thanks for your input. It may not have been what I wanted to hear, but it was probably what I needed to here.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Glad to have helped 
One question strikes me though: you are talking about a subset of C#; so how is VB concerned at all? Wouldn't you have to define a subset of VB for the same?
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
No, the subset of C# i'm rendering is what is compliant with the CodeDOM. The CodeDOM itself is a genericized abstract-syntax-tree for representing code constructs. Those code constructs are rendered to a target language by a 3rd party "CodeDOM provider" - when people make languages for .NET they make a CodeDOM provider that introduces rendering for their language. "Stock" .NET distributions include a renderer for VB and C#.
Well, I don't like building those CodeDOM trees by hand, so I wrote "Slang" which takes a C# subset and turns it into a CodeDOM tree so that it can then be rendered into one of N target languages, including C# and VB
that's where VB comes into it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Thanks, now I get it.
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
Wow, I managed to successfully explain a thing. 
I feel good about that. LOL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Provide a compilation option to turn OFF the feature (and write decent documentation about  ).
|
|
|
|
|
There's an idea, although I'm not sure where to put it. I like this idea because it provides me a way out without having to do full op_XXXXX call support.
I'll certainly consider it. Thanks.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Can you support pre- and post increment operators for C#, but convert them to a full i = i + 1 in VB (or i += 1, which is supported)?
The pre- and post semantics would be gone, but that's what you get for wanting to use unsupported operators.
Maybe you could show a warning if you have those operators and target VB.
On a side note, I never use pre- and post increment operators and you can do completely without.
They're not THAT convenient and can be confusing if you don't fully understand them (everyone else on the team).
Even the people who say they understand it actually don't (in fact, I'm not even sure if I do).
For example, I wasn't able to predict the outcomes in this quiz[^] for the increment operators (I wonder how well you score!).
As far as I know you can choose to not support them and still do everything you want, but with less ambiguity.
|
|
|
|
|
The CodeDOM is about 80% complete in terms of language support. You can do most of what you can do in a regular language in the CodeDOM, just less ambiguously, as you say.
So you wouldn't have a problem using my tool as is. I think when the CodeDOM was designed VB.NET may not have supported those operators or maybe I'm wrong and they skipped them in the CodeDOM for other reasons.
Postfix is difficult to support because it would require me to internally insert a variable declaration into the code as it is being rendered in order to support it. I may do that in a future version but i'd have to alter how I'm using the codedom to be able to support it (this is backburnered because there's other reasons i want to do it too, like reintroducing switch/case support - simulated using ifs)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: like reintroducing switch/case support - simulated using ifs
I think that's how the compiler compiles up to three or four case switch statements, as if, else if, else...
How did you do on the quiz?
Or are you too ashamed to share?
|
|
|
|
|
I'm not taking it at this hour and hamstringing myself. It's 2:20am
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
D. C. Fontana, 1939-2019 | Tor.com[^]
Star Trek would likely have been less without her efforts. (Even if she was partly responsible for that "The way to Eden" monstrosity. Although it did get rewritten under her.)
TTFN - Kent
|
|
|
|
|
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
On the Add Solution to Subversion dialog is a checkbox "Commit files in the intial commit", defaulted to checked.
I unchecked this, and everything works as expected
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Hooray
|
|
|
|
|
so you found the solution to find your solution
|
|
|
|
|
So, I have a server sitting next to my dev PC.
I went on the server and installed SVN Server and set it up. No problems there.
I went onto my Dev PC running VS2017 and install AnkhSVN via Tools => Extensions and Updates. No problem there. I then went to Tools => Source Control and selected AnkhSVN.
I then opened my solution, right-clicked on it, and go down towards the bottom of the menu and there's an Add to SVN option. Awesome!
I select that, and a dialog opens for me to specifiy the URl to the server. I fill that in, click OK, there's a pause for about 20 seconds. The SVN Checking window opens, so I know the AnkhSVN extension is working.
Then VS restarts, and there's no trace of SVN on the Solution menu. POOF! GONE!
Go back into Tools => Source Contro, AND GOD DAMN GIT IS SELECTED AGAIN!!!
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Is it just this solution, or any solution that has this problem?
What sourcecontrol you're using is stored in the solution file, and if it's corrupt it will revert to default.
|
|
|
|
|
Try VisualSVN. I love it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
