[SOLVED]
I'm using CodeBlocks (C++) on Win10. I tried to create a simple graphic program - I downloaded a certain graphics package (graphics.h and other two files related to BGI - I added the lib in settings etc.). I tried this program but there seems to be a problem at the line marked. I ported this from Pascal (as my teacher -yes, it's about college-, only shows us Pascal programs) in a correct manner I suppose, or at least partially. The problem is certainly with the pointers (EDIT AFTER SOLVING: it wasn't!, check my answer). I'll give more details if needed.
The Question: Where I did mistakes and how to correct them (what to write, what to add, what to delete) so that it wil work fine? If there is no mistake in the code, but I NEED some files for graphics to work on my compiler, which are the files, where to get them and where to put them?
ERROR (not quite, now's a "warning"):
deprecated conversion from string constant to 'char*' [-Wwrite-strings]
(see code a bit below)
Please read: I would BE VERY GRATEFUL for a fixed version of my program. Refferences are USELESS, so unless you REALLY want to help me (thank you!), leave this page. My only related capacity is to compare two versions of a program that are intended to do the same thing but one has a mistake (or more).
CODE (updated!):
#include<iostream>
#include<graphics.h>
#include<conio.h>
using namespace std;
int main(){
int gr,xmax,ymax,r;
int gm,gd;
gd=DETECT;
gm=0;
initgraph(&gd, gm, "C:\\TC\\BGI"); /*edit(solved): followed the tutorial linked in my answer; not a directory in my PC.*/
gr=graphresult();
if(gr!=grOk) cout<<"Error!";
else {xmax=getmaxx();
ymax=getmaxy();
cout<<"Resol.: "<<xmax+1<<"x"<<ymax+1;}
setcolor(7);rectangle(0,0,xmax,ymax);setcolor(5);line(0,0,xmax,ymax);line(0,ymax,xmax,0);setcolor(3);
for(r=(ymax+1)/2;r>=0;r--) circle((xmax+1)/2,(ymax+1)/2,r);
getch();
closegraph();
return 0;
}
graphics.h source and guide: http://www.codewithc.com/how-to-include-graphics-h-in-codeblocks/
You get an error because you try to take the address of something that isn't stored in memory.
Character literals like ' ' are basically translated into integers by the compiler, and you would not expect e.g. &32 (the ASCII code for space) to work would you?
If you're supposed to pass a string, use double-quotes and no address-of operator, as in " ".
Just read your edited question and want to mention about LValue:
"LValue" means something which has an address i.e. you may apply the address operator &. LValue because it may appear on Left side of an assignment.
A variable has an address and thus is an LValue.
A character constant (e.g. 'A') has actually type int and is not an LValue.
A string constant (e.g. "Hello") has type const char[] (compatible to const char*) is (may be surprisingly) an LValue because the compiler must allocate data storage for it somewhere.
Thus, even the following would "work":
#include <stdio.h>
int main()
{
char *sz = "Hello";
printf("address of \"%s\": %p\n", sz, sz);
printf("address of sz: %p\n", &sz);
sz[0] = 'h';
printf(sz);
return 0;
}
I compiled and tested with gcc and cygwin (on Windows 10 - 64 bit):
$ gcc -o test-cstringlvalue test-cstringlvalue.c
$ ./test-cstringlvalue.exe
address of "Hello": 0x403060
address of sz: 0x61cc6c
Segmentation fault (core dumped)
So you see two important things:
It compiles fine. (Changing an LValue is not suspected by the compiler.)
It crashs because a constant string has been modified.
(It probably will not crash on any platform.)
However, I recommend not to modify string constants but it demonstrates what I tried to explain about LValues.
I hope the sample does not confuse you any more. I warmly recommend to get a good C book. There are a lot of tricks possible in C but the language itself is tricky.
Edit:
Reading my own text again I felt a little bit uncertain if I told it exactly right: Thus I googled again and found this link: SO: Why are string literals l-value while all other literals are r-value?.
I fixed the obvious syntax errors and marked the places by comment `/* <-- FIXED */:
#include<iostream>
#include<graphics.h>
#include<conio.h>
using namespace std;
int main()
{
int gr,xmax,ymax,r;
int gm,gd; /* <-- FIXED */
gd=DETECT;
gm=0;
initgraph(&gd, &gm, "C:/Users/MyName/Desktop/WORKFOLDER/"); /* <-- FIXED */
gr=graphresult();
if(gr!=grOk) cout<<"Error!";
else {
xmax=getmaxx();
ymax=getmaxy();
cout<<"Resol.: "<<xmax+1<<"x"<<ymax+1;
}
setcolor(7);rectangle(0,0,xmax,ymax);setcolor(5);line(0,0,xmax,ymax);line(0,ymax,xmax,0);setcolor(3);
for(r=(ymax+1)/2;r=0;r--) circle((xmax+1)/2,(ymax+1)/2,r);
getch();
closegraph();
return 0;
}
Unfortunately, I cannot compile and test it. (I don't have BGI libs and don't want to install it.)
Solved!
Downgraded CB (v16 to v13 I think, not sure if it was necessary) and replaced some files.
I followed this tutorial:
https://m.youtube.com/watch?v=FxCdMM9H66I
It was quite the same as the link in the question but probably (one or more of) those files (graphics.h, winbgim.h, libbgi.a) from the previous link were bugged, had some unobvious errors or so, or were incompatible etcetera), while the files given by the maker of the vid I provided in this answer were corrected. I don't (really want to) know.
Now, the warning still appears, BUT the program runs perfectly!
I replaced r=0 with r>=0 , this was a minor mistake. (I'll update the question if I still can)
Thanks for... your help! (Can't say "nothing", I'd be mean)
:)
EDIT:
Some "cleaner" version that shows the circle (just realised the variant in the question doesn't display the filled circle):
#include<iostream>
#include<graphics.h>
#include<dos.h>
using namespace std;
main(){
int gm,gd,gr,xmax,ymax,r;
gd=DETECT;
gm=0;
initgraph(&gd,&gm,"C:\\TC\\BGI");
gr=graphresult();
if(gr!=grOk) cout<<"Error!";
else {xmax=getmaxx();
ymax=getmaxy();
cout<<"Res.: "<<xmax+1<<"x"<<ymax+1;}
setcolor(7);
rectangle(0,0,xmax,ymax);
setcolor(5);
line(0,0,xmax,ymax);
line(0,ymax,xmax,0);
setcolor(3);
for(r=(ymax+1)/2;r>=0;r--) circle((xmax+1)/2,(ymax+1)/2,r);
getch();
closegraph();
}
EDIT2:
Downgrading not necessary CONFIRMED! :D
The warning should go away if you replace the literal with an array that can be converted to char*:
char driver[] = "";
initgraph(&gd, &gm, driver);
Related
This question already has an answer here:
Array[n] vs Array[10] - Initializing array with variable vs numeric literal
(1 answer)
Closed 12 months ago.
What i would like to do is declare an array with "dim" size :int A[dim];.
Now, this works if I declare something like const int dim = 1 but doesn't with const int dim = round(x);, which is what i need to do. (Where x comes from cin >> x.)
Note: With "doesn't work" i refer to Visual Studio Code throwing red wavy line under dim in int A[dim]; and displaying the following when hovering it with my mouse:
`
expression must have a constant valueC/C++(28)
main.cpp(15, 11): the value of variable "dim" (declared at line 13) cannot be used as a constant
`
This is the relevant code:
#include <iostream>
using namespace std;
int main(){
float x;
cin >> x;
const int dim = round(x);
int A[dim];
int i = 0;
}
}
Given the context i believe the error is caused by one of two reasons:
Some characteristic of round() that makes the const int dim = round(x) not recognized as constant from the array later.
The problem is the x and not the round() so cin >> x is the reason.
[Thanks for whoever can explain me what I'm missing or point to some documentation that does. I have done some research but I haven't found a solution to this. Also this is my first question on SO, so tell me if I should change/improve something]
EDIT: Apparently the problem isn't in the round(x) as I previously thought because simply replacing const int dim = round(x); with const int dim = x; gives the same "error".
So the problem has to do with cin >> x .
EDIT 2 Note: I'm looking for a solution that doesn't use std::vector. We haven't studied it yet in the course so I believe the algorithm(from which i took the relevant code) shouldn't comprehend it.
Final Edit I didn't realize that, as #paulmckenzie clarified, using cin made the array dynamic because the imput comes in runtime, it was a really stupid error but I apologize, I'm really a beginner. In my defense we really haven't talked about dynamic size arrays so I guess that's what threw me off. I realized from the beginning I was missing something very basic, sorry for wasting time, I'll put even more time analyzing everything before posting next time.
The size of an array variable must be compile time constant in C++. User input is not compile time constant, hence it cannot be used as the size of an array variable.
In order to create an array with runtime size, you must instead create a dynamic array. The simplest way to do that is to use std::vector from the standard library.
EDIT 2 Note: I'm looking for a solution that doesn't use std::vector.
It's possible to create a dynamic array without std::vector, but that requires the use and understanding of more advanced concepts. Using new expressions directly is more difficult, error prone and is something that isn't (or shouldn't) be done in most programs in practice.
Of course, another solution is to just not use user input but rather an array with constant size.
Whenever I am writing this following code, I am getting garbage(unexpected) output in some online compiler, but if I use code block then getting satisfied output. So my question is why I am getting this type of output?
for example, if I input
5 7
+ 5
- 10
- 20
+ 40
- 20
then I am getting
22 1
in the code block. But in the online compiler, it's something else.
#include<iostream>
#include<cstdlib>
using namespace std;
int main()
{
int have, n, i;
int kid=0;
cin>>n>>have;
int line[n];
for(i=0;i<n;i++)
{
cin>>line[i];
if(line[i]>=0)
have+=line[i];
else
{
if(have>=abs(line[i]))
have+=line[i];
else
kid++;
}
}
cout<<have<<" "<<kid<<endl;
}
The main problem I can see in your code is this:
int line[n];
This is known as a VLA (Variable Length Array) and it is not supported in C++. It is valid in C. Most compilers still allow this behaviour due to the fact that C++ is based on C, but it is not valid C++ code. In a previous question, I found out that clang supports designated initializers, when gcc and vc++ did not. The reason is because some compilers like clang, support c99-extensions by default. My point is that just because the code compiles, it doesn't mean it's always right.
If you compile with the -pedantic argument, you will see that the compiler is warning you about this being a C99 feature. Have a look at the rextester example here. From the comments below, using -pedantic-errors in the compiler flags, will prompt an error.
If you know the size of the array before run-time, then you should use a static array int line[4];, but if you don't then you need to use a dynamic array. std::vector is essentially a dynamic array that also handles memory for you. It's easy to use and very efficient. std::vector<int> line;
You can read more about the vector container here: http://www.cplusplus.com/reference/vector/vector/
Btw, I tried your code in rextester, ideone and repl.it and I got the same results: 22 1. I think what you are witnessing it undefined behaviour.
Also, you can qualify int n with constexpr and it'll be fine.
constexr int n = 200;
int line[n]; //now it's ok.
But this again means that you know the size of the array at compile time.
I've spent 2 days trying to figure this out and getting nowhere. Say I had a struct that looks like this:
struct Thing {
bool is_solid;
double matrix[9];
}
I want to create an array of that struct called things and then process that array on the GPU. Something like:
Thing *things;
int num_of_things = 100;
cudaMallocManaged((void **)&things, num_of_things * sizeof(Thing));
// Something missing here? Malloc individual structs? Everything I try doesn't work.
things[10].is_solid = true; // Segfaults
Is it even best practice to do it this way rather than pass a single struct with arrays that are num_of_things large? It seem to me that can get pretty nasty especially when you have arrays already (like matrix, which would need to be 9 * num_of_things.
Any info would be much appreciated!
After some dialog in the comments, it seems that OP's posted code has no issues. I was able to successfully compile and run this test case built around that code, and so was OP:
$ cat t1005.cu
#include <iostream>
struct Thing {
bool is_solid;
double matrix[9];
};
int main(){
Thing *things;
int num_of_things = 100;
cudaError_t ret = cudaMallocManaged((void **)&things, num_of_things * sizeof(Thing));
if (ret != cudaSuccess) {
std::cout << cudaGetErrorString(ret) << std::endl;
return 1;}
else {
things[10].is_solid = true;
std::cout << "Success!" << std::endl;
return 0;}
}
$ nvcc -arch=sm_30 -o t1005 t1005.cu
$ ./t1005
Success!
$
Regarding this question:
Is it even best practice to do it this way rather than pass a single struct with arrays that are num_of_things large?
Yes, this is a sensible practice and is usable whether managed memory is being used or not. An array of more or less any structure that does not contain embedded pointers to dynamically allocated data elsewhere can be transferred to the GPU in a simple fashion using a single cudaMemcpy call (for example, if managed memory were not being used.)
To address the question about the 3rd (flags) parameter to cudaMallocManaged:
If it is specified, it is not correct to pass zero (although OP's posted code gives no evidence of that.) You should use one of the documented choices.
If it is not specified, this is still valid, and a default argument of cudaMemAttachGlobal is provided. This can be confirmed by reviewing the cuda_runtime.h file or else simply compiling/running the test code above. This particular point appears to be an oversight in the documentation, and I've filed an internal issue at NVIDIA to take a look at that. So it's possible the documentation may change in the future with respect to this.
Finally, proper cuda error checking is always in order any time you are having trouble with a CUDA code, and the use of such may shed some light on any errors that are made. The seg fault that the OP reported in code comments was almost certainly due to the cudaMallocManaged call failing (perhaps because a zero parameter was supplied incorrectly) and as a result the pointer in question (things) had no actual allocation. Subsequent usage of that pointer would lead to a seg fault. My test code demonstrates how to avoid that seg fault, even if the cudaMallocManaged call fails for some reason, and the key is proper error checking.
This question already has answers here:
Undefined behavior and sequence points
(5 answers)
Closed 7 years ago.
I got stuck in operator precedence problem...In the first look it looks quite easy but it is really hard ...and i run it on DEV as well as Visual studio but it gives different output and i m completely shocked .here is my code
#include<iostream>
using namespace std;
int main(){
int a=0;
a=++a*++a*a++;
cout<<a<<endl;
}
it gives 8 output in Dev and g++ but 9 in Microsoft Visual studio 2013, any help would be appreciated ...Also plz tell me in which order does these operators call each other so that to get the desired output on the console.
a=++a*++a*a++;
Should be
++a;++a; //a = 2, because you have the two pre-increments.
temp = a * a; //temp = 4
temp = temp * a; //temp = 8
a = temp; //a = 8
a++; //a = 9, for the post-increment.
So you should probably report this to the compiler teams along with your CPU specs.
However, according to gnu.org regarding operator precedence:
In C you cannot assume that multiple subexpressions are evaluated in
the order that seems natural. For instance, consider the expression
++a * f(). Does this increment a before or after calling the function f? The compiler could do it in either order, so you cannot make
assumptions.
(Note that the above is taken from the GNU c manual).
So technically this is not a bug, even though it's inconsistent.
Short term solution:
a = 9;
f you really wrote code like this, you are in trouble.
Better you must to use aux variables like
#include<iostream>
using namespace std;
int main(){
int a=0;
int aux = ++a;
a=aux*aux*a++;
cout<<a<<endl;
}
or something like this to solve the ambiguity.
If you question is for learning purposes, there are cases that has no an unique result, because is the way that the compiler solve this equation.
Dr.dobbs's Magazine show several cases like this, and all equations haven't an exact result.
I can't get now some page to show code you never will use, to avoid bugs like this.
Just for example: http://www.cplusplus.com/forum/beginner/26383/
This is a sequence-point issue, and should have warned you about it if you have -Wsequence-point enabled. In essence your statement is undefined, and is why different compilers give different results.
Please look at a previous answer to this problem: undefined-behavior-and-sequence-points
I want to modify the string variable present in main function by the external function, by passing the address of the same.
Below is the code which I've written
void change(char * str)
{
str="Max";
}
void main()
{
char a[]="Test";
change(a);
cout<<a;
}
Please correct me if I am wrong
Please note that I am using Borland Turbo C++ 4.5.
I guess you mean pass by reference, you can simply pass the given string by reference to the external function as follows:
void modifyString( string& str)
{
//modify the string
}
inside main, you can call this function.
You want this:
void change(char * str)
{
strcpy(str,"Max");
}
Recall what a pointer is, and that the pointer itself cannot be changed only what it points to.
First of all you should not use Turbo C/C++, It was last updated long time ago,
You can change a string in a function as follows,
void change(char * str)
{
*(str+0)='M';
*(str+1)='A';
*(str+2)='X';
*(str+3)='\0';
}
int main()
{
char a[]="Hello";
change(a) ;
}
You ask,
“correct me if i am wrong”
after presenting this code:
void change(char * str)
{
str="Max";
}
void main() {
char a[]="Test";
change(a);
cout<<a;
}
So, here goes:
str="Max";
only changes the local pointer str. with a compiler conforming to the C++11 standard it won’t even compile, because str is declared as char* while the literal "Max" is of type char const [4], and C++11 does not anymore support an implicit conversion from string literal to pointer to non-const.
void main
will not compile with any standard-conforming C or C++ compiler, no matter which standard. however, visual c++ will compile it with no diagnostic. and possibly old turbo c++ did too, but note that turbo c++ predated the first C++ standard (which came in 1998). the standard requires int result type for main for an ordinary hosted C++ implementation.
cout<<a;
will not compile with a standard-conforming compiler without including <iostream> and having a using declaration or directive. note that this changed with the standardization. before the 1998 standard, in ARM C++, you could include <iostream.h> and use unqualified cout.
A proper way to do your program, in modern C++, is
#include <iostream> // std::cout, std::endl
#include <string> // std::string
using namespace std;
string foo() { return "Max"; }
int main()
{
string a = "Test";
a = foo(); // Changed!
cout << a << endl;
}
another answer, which as I’m writing this you have selected as “solution”, recommends using raw pointers and strcpy, instead of std::string. using raw pointers and arrays is advice that will make you unhappy if you follow it. for example, it’s very easy to inadvertently write beyond the end of the provided buffer, with disastrous effects. ownership handling is exceedingly difficult to do correctly, and so on. the advice was presumably given in the Stack Overflow tradition of answering the literal question with no regard for what the question was really about, which is a good way to obtain Stack Overflow reputation points (it beats me what is so desirable about them, the silly T-shirts or whatever are really not worth it), at the cost of creating severe problems for others, sort of like maiming a few bystanders in order to steal a small bar of chocolate.