My Visual Studio 2015 IDE (Community Edition) keeps complaining about the code below
struct item
{
int data;
std::vector<item*> linkedItems;
};
void traverseLinkedItems(item* p_item)
{
for (item* i : p_item->linkedItems) // Intellisense Error: A value of type "item*" cannot be used to initialize an entity of type "item*"
{
std::cout << i->data;
}
}
It compiles just fine. So I'm not sure whether it's a bug in VS, or am I missing something?
When I use auto instead of specifying the type of i explicitly, everything is OK.
Thanks!
IntelliSense is not always right. In order to know everything about your code, it would have to fully compile it, but this would be too slow to be (conveniently) usable. Instead, it parses your code in a faster but less complete way to get autocompletion information and find obvious errors. However, sometimes it trips over something, either due to a bug or because it did not manage to obtain all the information it needs. When this happens, its output is not so (Intelli)sensible.
I would simply ignore the IntelliSense error, or, like you said, use auto instead of item* if you want to get rid of the error. Maybe in a later update, or after changes to your code, the error will magically disappear.
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.
Can a good IDE (e.g. Visual Studio) find basic logic errors?
or is there no such thing as a "basic" logic error and all of these errors are undetectable by the IDE?
Yes, some IDEs (like Visual Studio) have continous syntax checks, that can find some logical errors. However, a logical error can only be spotted if there is something odd in the code, there is no AI trying to figure out what the code is actually intended to do.
If you for example write this in a C# method in Visual Studio:
int a = 1;
int b = 2;
Console.WriteLine(a + a);
then the IDE will notice that you never used the variable b, and put a warning in the form of a squiggly line under the variable. Pointing on it will reveal the message The variable 'b' is assigned, but its value is never used.
The IDE can't know if you intended to output a + b rather than a + a, and simply the use of a + a is not odd enough to render a warning, but it can see that you created a variable b and that you probably intended to use that for something.
Not really.
Sometimes it can pick up that a code path may never execute I think.
int x = 9;
if (x != 9)
{
foo();
}
and it maybe able to tell you that you've declared something without using it. It's stuff you can catch yourself. However, the real power is in the debugger where you can use "watch" or locals/autos and follow the code with step-in/out/over at any scope, see when they change, and change the values yourself to see what needs to happen. It's a good way to test logic. In assembly, you can move your code back a few lines and repeat it... it's not guaranteed to work, but you can override anything.
Edit: see https://en.wikipedia.org/wiki/Halting_problem
I've got a TypeScript script that has to interact with a third-party vendor that uses global functions as callbacks (you can't pass in a callback). For instance, to "listen" for a result from their "API", you define the function SetElqContent. E.g.,
window.SetElqContent = function(){/* handle result */};
When the TypeScript compiler sees this line, it complains that The property 'SetElqContent' does not exist on value of type 'Window'.
I thought I could get around this by simply casting to type "any". Actually, this isn't type casting but type assertion, but I think of it as casting, although I understand it's not quite the same. So, I tried:
(<any>window).SetElqContent = function(){/* handle result */};;
To m y surprise, this results in Syntax error, and the line number and column points to the < character in the <any> cast. I tried a few other variants, and I get Syntax error on the initial < of the cast no matter what kind of cast I was doing:
var windowAny = <any>window;
var docElement = <HTMLElement>window.document;
What is it about my type assertions that is invalid syntax?
I'm using Visual Studio 2013 with Update 2, which has a "compile on save" feature for TypeScript files. That's how I'm compiling my .ts files, and it's from in Visual Studio where the Syntax error message is emitted.
UPDATE: Apparently this is related to Visual Studio. When I use the standalone tsc compiler to compile the same file, it emits no errors or warnings.
Apparently my syntax is correct but there is a bug in the Visual Studio tooling. I can't provide exact reproduce steps, and in fact, deleting everything in the .ts file, saving, then restoring the code (via ctrl-z) and resaving caused the "syntax error" warning to disappear.
If I can determine any more specifics about what causes this issue to manifest, I'll report back.
Best way is to create a type definitions file for it
If the library name is eloqua.js, you create a eloqua.d.ts file and refer to it in your .js file like
/// < reference path="../typings/eloqua.d.ts" />
There are many type definition files online available at definitelyTyped website.
https://github.com/borisyankov/DefinitelyTyped
You can contribute yours to there as well.
If you extend the Window interface definition, you'll remove the error:
interface Window {
SetElqContent: Function;
}
window.SetElqContent = function(){/* handle result */};
Here is how you can do the assertion properly:
function SetElqContent(){/* handle result */};
// FINE
(<any>window).SetElqContent = SetElqContent;
or
// FINE
(<any>window).SetElqContent = function SetElqContent(){/* handle result */};
However you should avoid asserting and just do what Steve Fenton recommends as it is more discoverable
Update
Demo in VS:
For example, I could pretty much always do without the "not all code paths return a value" error squiggly. This generally means I'm in the process of writing the method. I don't need to be told it doesn't return a value. If I forget to add a return value, VS can tell me that when it builds. But I never want that while I'm working; it's annoying and usually tells me something I already know.
For another example, I could do without the errors that show up while I'm in the process of writing a switch statement, such as the one that tells me I don't have a break statement yet, as I'm still working on whatever case.
You can try to disable "Show live semantic errors",
http://www.devcurry.com/2011/01/disable-squiggly-or-wavy-lines-in.html
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.