I'm using Visual Assist X trial on VS2010 Pro.
When I do extract method or modify method signature refactorings it gives me this:
void Solver::Work( Stack &s, Board &b )
However I would really appreciate if it gave me this:
void Solver::Work(Stack &s, Board &b)
No extra spaces. Is there a way to set this?
The spacing is defined in the VA Snippets whose titles start with "Refactor" - see "Editing VA Snippets" in the VA documentation. Similar questions have been raised on the Whole Tomato support forum here and here.
Related
I have recently gotten into programming and decided to learn C++. I took advantage of the sale on Udemy and bought three courses there, one for beginners on C++, one for game-making and one for Blender.
I started doing the course for beginners, the lecturer said that he would use Code::Blocks but that any other IDE would be fine so I downloaded Visual Studio 2017 because that's what the game-making course used. But when I do exactly as the lecturer says (and writes), the code won't compile correctly.
Here is an example:
What the lecturer wrote and got to work on his computer
#include <iostream>
using namespace std;
main()
{
cout << "Hello world! :-)";
}
What I figured out would work after some googling
#include <pch.h>
#include <iostream>
using std::cout;
int main()
{
cout << "Hello world! :-)";
}
And my question to those who are experienced is: What is the difference between Code::Blocks and Visual Studio 2017? What is different in that case? Will I even be able to use this course to learn?
Thanks in advance!
edit: edited in a missing # in the lecturer's code
#include <pch.h>:
See Gabriel's answer.
include <iostream> vs #include <iostream>:
The former is plain wrong. It has to be #include with the #.
using namespace std; vs using std::cout;:
While neither is particularly good practice, both should do the same thing here. If you write neither of them, you will have to write std::cout << ... instead of only cout << ... - that seems annoying but is something you should get used to if you want to eventually be a serious C++ programmer. See also Why is "using namespace std" considered bad practice?.
main() vs int main():
This is not something that Code::Blocks should allow because it is not correct C++. main should always return int.
Overall you seem to have hit an unfortunate number of differences between environments/compilers on this basic example already. However, neither your course nor VS2017 is wrong so far, so I recommend you keep using them. If something that your lecturer writes won't work for in a different environment, it's probably a bad idea to write that kind of code in the first place. And they did make several mistakes in this simple example.
PS: I strongly recommend enabling warnings, because they may tell you when you do something wrong in a more subtle way. There are many mistakes (of the "shooting yourself in the foot" kind) that the compiler is not required to stop you from making, but if you ask to be stopped (by heeding warnings) it will help you.
Using Visual Studio should be okay as long as you disable precompiled headers and your tutorial uses standard-compliant code.
About precompiled headers :
Visual Studio enables pre-compiled headers by default in a C++ command line program. This means that in your project, it'll by default force you to use a precompiled header in the first line of your source code (pch.h here).
By disabling them, you can almost* make the first snippet work in VS. To do this, select your project, go to the "Project->Properties" menu, then to the "Configuration Properties -> C/C++ -> Precompiled Headers" section, then change the "Precompiled Header" setting to "Not Using Precompiled Headers" option (this applies to VS 2012, applying this to other versions of VS should be easy).
If you want to avoid this in the future, you can create an empty project when setting up your project in VS.
See also : http://msdn.microsoft.com/en-us/library/h9x39eaw%28v=vs.71%29.aspx, How to avoid precompiled headers
* : The first snippet won't actually work since the declaration of main is not correct C++, only C (see https://en.cppreference.com/w/cpp/language/main_function, What is the proper declaration of main?)
To your actual question, VS will be fine for your course, although I'm still puzzled by the lecturer's original version of this code.
However, it's really useful to take the time to understand what all your changes did, and why they fixed your problem. Maybe you did this already - that's just not the impression I got from the phrase
What I figured out would work after some googling
when you get a compile error or warning, read it and try to understand it.
if you don't understand the error - and this is normal, certainly while you're learning - then hacking on the code until it works is perfectly fine. At least sometimes it's quicker, and the knowledge that you made progress is its own reward.
if hacking away at the code with the internet at your disposal doesn't get a solution, you'll just have to study the error message more. Turning all compiler errors and warnings on, and trying multiple compilers can both help - even if they all fail, the messages might be more useful. (I often find clang has useful errors, and godbolt.org is super helpful).
if hacking away at the code does get a solution, you should still try and understand why. Now you can see what you changed, look at the original error and try to understand why your changes fixed it. If you made multiple changes, were they all really necessary? Do you understand what they all did, and why?
If you do this, you can fix the next related problem faster, rather than going through the whole trial-and-error process again. You can even write better code that avoids the problem in the first place.
This is the part that actually constitutes learning, which is why I'm making a point of addressing it.
The important fix was changing the lines
include <iostream>
main()
to
#include <iostream>
int main()
because the former aren't legal C++. If your lecturer really wrote exactly that and you didn't somehow mis-copy, then I have no idea why their example worked.
The Visual Studio-specific stuff is the precompiled header, as described in Gabriel's answer.
But the remaining change is essentially cosmetic. Replacing:
using namespace std;
with
using std::cout;
Doesn't affect anything in your code, and just using
std::cout << "Hello world! :-)";
(with no using at all) would work just as well.
This is an odd question, I know.
Earlier this week, I was browsing hacker news and glossed past an article about the power of C# 6. I meant to 'pocket' the link at the time but I didn't and now I can't find the article again.
Long story short, there was an example of code which looked roughly like this...
using static Variables;
public class Blah
{
public Blah()
{
s = "something"
Console.WriteLine(s);
}
}
... as if to say, somehow it was possible using some magical combination of C# 6 features to remove the 'var' element of that equation and have valid code.
I'm struggling to see how that's possible without some extra Roslyn magic and even then, I'd struggle.
If you know where the article is please let me know. If not, is this even remotely possible? I'm fairly confident it would be an odd thing to do,..I'm just intrigued.
Thanks in advance.
I'm working with a small team, and we're fairly evenly split between the following styles:
public void Method() {
// code
}
and:
public void Method()
{
// code
}
I know we can each setup Visual Studio (2010 Professional) to place New Lines where we want them, but that's only at the time the code is authored.
Is it possible to have the code re-formatted when it's opened (or by running an External Tool?) to the current user's preference, or do we really need to have a long debate about the best style (or abandon any hope of consistent code)?
(note: I am NOT asking which style is best, please don't try answering that question. Just can we have VS eliminate the debate by automatically re-formatting existing code into the style preferred at the moment?)
Thanks for any help!
You can create an envrimental events macro to do just that. This link tells you how to create one of these macros.
Private Sub DocumentEvents_DocumentOpened(ByVal Document As EnvDTE.Document) Handles DocumentEvents.DocumentOpened
DTE.ExecuteCommand("Edit.FormatDocument")
End Sub
I have been searching for a FAQ to tell me how to open a Excel Workbook/Worksheet and also how to Save the File once I have finished.
I notice that in most FAQ and all the books I have purchased on F# one is show how to create a new Workbook/Worksheet but is never shown how to either open or Save it.
Being a newbie to F# I would very much appreciate it if anyone could kindly provide me with either an answer or perhaps a few pointers?
Update
As for why F# and not C# or VB?
I am pleased to say that inspite of being a newbie (with the exception of Forth, VBA & Excel 2003, 2007 & 2010 and Visual Basic) I can do this in both VB, VBA & C# and since I've been retired on medical grounds, with plenty of time unfortunately on my hands, I like to continually set myself challenges to keep my little grey cells active and being a sucker for trying new languages....well!
F# is now an intergral part of Visual Studio 2010 so I thought - why not. Consider this - if we are not willing to use or at least try a new languages - I would always be wonder if I might have prefer it to VBA, VB, C# ..... and if you look at it from another point of view, if no one is going to use it - why create it in the first place? I suppose you can say if cave men hadn't experimented and made fire by rubbing two sticks together - where would we be now and would matches have been invented?
Although an complete answer would be good, I prefer a few pointers, to keep my challenge going.
And lastly but not least - thank you for taking the trouble to respond!
I don't think their is a specific F# library for Office, so you will just use the exact same .NET library that you use in VB.NET/C#. F# is a .NET language, so anything that can be done in C# can be done in F# (but you probably already knew that :) ). The API call will be exactly the same, it just that they will be done using the F# syntax instead of the VB/C# one. So for example something that look like this
public void SaveMyWorkbook() {
string filePath = #"C:\failworkbooks\catfail.xlsx";
workbook.Save(filepath);
}
Will be expressed in F# as
let filePath = "C:\\failworkbooks\\catfail.xlsx";
let saveWorkbook() = workbook.Save(filePath) |> ignore //if the Save method return something
Now, what you will soon realize is that the API isn't exactly designed to be easily used from a functional language. It can be done, but this task in particuliar is much more tailored to C#/VB.NET.
If you really want to enjoy F#, I suggest you use in area where its strength really show. My personal experience is that functional language are awesome when a lot of math is involved. It is also marvellous if you want to easily introduce parallelism in your application (since F# code is usually side effect free). So anything that require data crunching on a lot of data is perfect for it. But for task that consist mainly of putting together a bunch of API call to an external library, F# is kind of meh. You could say that F# is kind of like a graphic card programming language, while C# a general purpose CPU programming language. A lot of thing run better with C#, but the stuff that run better on F# run really better on it.
But if you really want to go that route, my suggestion is to try to use the Office API as you already know it, but with a F# syntax. If at some point you really have no idea how to do a specific task, ask a question about it on stackoverflow with your code and exactly want you want to do. Those question get answered ridiculously fast compared to broad all-encompassing question, so you won't wait long. (Programmer seem to love precise question with a specific answer ^^)
I hope that it helped a little.
I found this http://iouri-khramtsov.blogspot.co.uk/2011/12/automating-excel-with-f.html helpful advice. Briefly, you'd use something like this:
#r "Microsoft.Office.Interop.Excel" // Assuming it's a script
let excel = ApplicationClass(Visible = true)
let openFileName = #"C:\MyDir\MyFilenameToOpen.xls"
excel.Workbooks.Open(openFileName)
// Do stuff
let savedFileName = #"C:\MyDir\MyFilename.xls"
workbook.SaveAs(savedFileName)
Using F# with Excel seems like a natural fit.
Getting to a result in Excel requires the use of several immutable values, each driven by formulas. Excel has a brilliant user interface, a lovely model of the world - I love rows, columns and cells - but to automate or customise things requires macros. Why learn this when you can use F#? Formulas and immutable values are fundamental to its design.
Ideally you'd write formulas yourself as a User Defined Function (UDFs) also in F# - see http://excel-dna.net/ . Then, perhaps, you'd want to do something interesting with objects/types - Look for "github com mndrake ExcelObjectHandler" (I don't have enough reputation to post a 3rd link).
Jack
I did a research on web and cannot find anything so maybe you know a way to solve my problem.
I am using MS VS 2010, and I use VS C++ (only CLR).. Let's say I have a class smt like this:
class A
{
public:
int x;
float a;
char* str;
};
While debugging my application, I open "Locals Window" and I see my variable name, value and Type. I would like to change (write) something to my value part. Like I habe a class A object a:
Name Value Type
a x: 4 a: 2.03f str: 'Hello!' A
I hope this was a clear example. I want to override value part in locals, autos ... windows.. Any way to do it?
Thanks...
If the class is a managed class then you can decorate it with a DebuggerDisplayAttribute. If it is unmanaged, which your example seems to be, then you need to edit a file called autoexp.dat. There's a fairly old article on MSDN about it here, I have done this a long time ago and remember it was a pain to get working. Also, there is a bug filed on Connect that autoexp.dat doesn't work for C++/CLI projects in VS 2010, though I haven't tried this myself.