When I compile this helloworld example, I get the following error repeated 4 times:
error: expected primary-expression before ‘.’ token
Here is the code:
static struct fuse_operations hello_oper = {
.getattr = hello_getattr,
.readdir = hello_readdir,
.open = hello_open,
.read = hello_read,
};
int main(int argc, char *argv[])
{
return fuse_main(argc, argv, &hello_oper);
}
Your compiler is too old. It needs to support C99. Pass in -std=c99 if the compiler is current enough
That syntax is using a new feature of the C99 language standard called designated initializers. That feature is not part of the more common C89 standard (aka ANSI C), so a C89 compiler will give you syntax errors when you try to compile code that uses it.
To fix it, tell your compiler to use its C99 mode if it has one. For example, if you're using GCC, you should pass the -std=c99 compiler option. If your compiler doesn't support C99 at all, you'll have to either switch to a compiler that does, or refactor the code to avoid using C99 features.
Actually, gcc support newer dialects of C (or of C++). Try passing it gcc -std=c99 -Wall
Ran into a similar error, although I was unable to overcome it by adding "#define FUSE_USE_VERSION ..." as mentioned in one of the comments above.
To overcome the error, I wrote a wrapper around the fuse_operations as follows:
struct my_operations: public fuse_operations {
my_operations()
{
read = my_read;
open = my_open;
}
} operations;
main(int argc, char* argv[])
{
return fuse_main(argc, argv, &operations, NULL);
}
Related
Found strange behavior that i don't understand:
std::vector<std::string> subdomainVisits(std::vector<std::string> &cpdomains)
{
// return std::vector<std::string>();
}
int main(int argc, char const *argv[])
{
std::vector<std::string> data = { "9001 discuss.leetcode.com" };
auto result = subdomainVisits(data);
return 0;
}
In this case commented return in subdomainVisits function causes Segmentation fault(use gcc version 7.3.0 (Debian 7.3.0-19) ). Uncommenting fix this problem.
Why it happens?
The behaviour of your program as written is undefined.
A non-void function must have an explicit return value on all control paths.
The only exception to this is main, which has an implicit return 0;.
A fair number of compilers will warn you of trivial cases such as the above. Do you not have the warning level set high enough? (Pass -Wall and -Wextra to "turn up" the warning level on gcc.)
Note that the C++ standard does not require a compiler to fail compilation: theoretical computer science (the halting problem) tells us that reachability is impossible to prove.
I am trying to capitalize the first character of a std::string, using the same method mentioned here. For example for the following program
#include <cctype>
#include <iostream>
#include <string>
int main()
{
std::string name = "foobar";
name[0] = std::toupper(name[0]);
std::cout << name;
}
I am expecting the output to be
Foobar
When I compile this online (using GCC 4.9.2) I get the correct output without any warnings. However, when I compile the same code in Visual Studio 2013, I get a warning during the assignment back from toupper
warning C4244: '=' : conversion from 'int' to 'char', possible loss of data
Is the above method valid according to the C++ standard or is the warning correct? Otherwise is this just a false warning by Visual Studio?
The warning is correct as far the types go; the type of std::toupper as defined in the standard is:
int toupper( int ch );
Mostly because it's a remnant from the dark C ages (the cctype header is a hint at that).
However, this is just a part of the story. There's another toupper residing in the locale header:
template< class charT >
charT toupper( charT ch, const locale& loc );
This one shouldn't give you any warnings. If you're not sure what locale to provide, std::locale() will give you the default one.
std::toupper comes from the C standard, not C++, and has an annoying interface in that it takes and returns an int not a char. Using static_cast<char>(std::toupper(name[0])) will suit you.
The warning is correct, compiler will implicitly cast from int to char but this might cause lost of data in some cases. To see warning under gcc you need to add -Wconversion compiler option. Which will generate:
main.cpp: In function 'int main()':
main.cpp:8:13: warning: conversion to '__gnu_cxx::__alloc_traits<std::allocator<char> >::value_type {aka char}' from 'int' may alter its value [-Wconversion]
name[0] = std::toupper(name[0]);
^
Foobar
Why it is not present when -Wall is set, read here:
https://gcc.gnu.org/wiki/NewWconversion
Why isn't Wconversion enabled by -Wall or at least by -Wextra?
Implicit conversions are very common in C. This tied with the fact
that there is no data-flow in front-ends (see next question) results
in hard to avoid warnings for perfectly working and valid code.
Wconversion is designed for a niche of uses (security audits, porting
32 bit code to 64 bit, etc.) where the programmer is willing to accept
and workaround invalid warnings. Therefore, it shouldn't be enabled if
it is not explicitly requested.
I may have found a bug with GCC v4.8.2, but I want to check first before I submit it as it could be me doing something wrong!
The following code:
#include <vector>
struct Message
{
typedef union {
char byte;
const char *str;
} Parameter;
Parameter p1;
Parameter p2;
};
int main()
{
std::vector<Message> messages_;
messages_.push_back({{ .byte = 'a' }});
Message message = {{ .byte = 'a' }, { .str = "Hello World" }};
messages_.push_back(message);
messages_.push_back({{ .byte = 'a' }, { .str = "Hello World" }});
}
clang++ -std=c++11 main.cpp compiles this fine. However g++ outputs this:
main.cpp: In function ‘int main()’:
main.cpp:23:66: internal compiler error: in reshape_init_class, at cp/decl.c:5216
messages_.push_back({{ .byte = 'a' }, { .str = "Hello World" }});
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
Preprocessed source stored into /tmp/ccrf5vwr.out file, please attach this to your bugreport.
I'll submit this as a bug if nobody has any ideas, although in my experience a programmers problem is almost never a compiler bug and almost always a fault of his own!
As answered in the comments above: Any error message you get from GCC that includes the phrases internal compiler error and Please submit a full bug report is definitely a compiler bug, not your own fault! In this case, the bug appears to be something to do with GCC's parsing of {{ ... }} in C++ mode where the "..." includes a designated initializer. #Sam has reported it as GCC bug 59832.
However, as #Angew pointed out, this line —
messages_.push_back({{ .byte = 'a' }});
— is not valid C++. Standard C++ doesn't allow designated initializers; that's a C99 feature that was not adopted into C++ (neither C++11 nor C++14).
As for why designated initializers have been problematic to add to C++, see here, where Doug Gregor asks how the compiler should interpret things like
struct Foo {int x,y; };
void f(Foo);
void f(std::initializer_list<int>);
int main(){
f({1});
f({1,2});
f({1,2,3});
f({.x=1});
f({.x=1,2});
f({.x=1,2,3});
}
For the record, GCC 4.8 treats all six as calls to f(initializer_list<int>). Clang 3.5 treats the first three as calls to f(initializer_list<int>), the next two as calls to f(Foo), and the last one as ill-formed. Basically, it's a non-standard construct: different compilers are within their rights to treat it differently, and they do.
I've been learning C++ and using the Terminal for the last couple of months. My code was compiling and running fine using g++ and C++11, but in the last couple of days it started giving errors and I have had problems compiling since. The only programs I can compile and run depend on older C++ standards.
The errors I first got related to #include < array > in the header file. Not sure why this happened, but I got around it by using boost/array instead. Another error I can't solve is with std::stoi. Both array and stoi should be in the C++11 standard library. I made the following simple code to demonstrate what's going on:
//
// stoi_test.cpp
//
// Created by ecg
//
#include <iostream>
#include <string> // stoi should be in here
int main() {
std::string test = "12345";
int myint = std::stoi(test); // using stoi, specifying in standard library
std::cout << myint << '\n'; // printing the integer
return(0);
}
Try to compile using ecg$ g++ -o stoi_trial stoi_trial.cpp -std=c++11
array.cpp:13:22: error: no member named 'stoi' in namespace 'std'; did you mean
'atoi'?
int myint = std::stoi(test);
~~~~~^~~~
atoi
/usr/include/stdlib.h:149:6: note: 'atoi' declared here
int atoi(const char *);
^
array.cpp:13:27: error: no viable conversion from 'std::string' (aka
'basic_string') to 'const char *'
int myint = std::stoi(test);
^~~~
/usr/include/stdlib.h:149:23: note: passing argument to parameter here
int atoi(const char *);
^
2 errors generated.
I also get these errors at compilation when using gcc or clang++ and with -std=gnu++11 (I guess they all depend on the same file structure). I also get the same error whether I specify std:: in the code, or if I specify using namespace std;
I worry that these issues arose because of the September Command Line Tools update via Xcode or because I installed boost and this somehow messed up my C++11 libraries. Hopefully there is a simple solution.
My system:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-> dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
Thanks for any insight you can offer.
clang has a weird stdlib, you need to add the following flag when you compile
-stdlib=libc++
your snippet works on my mac with
g++ -std=gnu++11 -stdlib=libc++ test.cpp -o test
This answer describes the problem
I am experiencing some troubles compiling a c++ file that worked well as a previous build under GCC.
The issue is, I am using vectors of variable array size:
unsigned int howmany;
std::vector<int>* array_adresses[howmany];
I am currently using the Visual-Studio 2010 C++ compiler to built Matlab 64-bit Mex-Files.
Since VC++ won't allow me to use arrays whose size is unknown at compile time, I am receiving the following error messages:
error 2057: constant expression expected
error 2466:
error 2133: unknown size
Is there any way to build the 64 bit mex file using a GCC-compiler option or build it with a different 64-bit compiler under Matlab?
Thanks in advance!!
howmany needs to be constant, and needs to be a defined amount, like so:
const unsigned int howmany = 5;
std::vector<int>* array_adresses[howmany];
Or you can define it dynamically like this:
unsigned int howmany = 5;
std::vector<int>* array_adresses = new std::vector<int>[howmany];
C++ standard doesn't allow variable-length arrays. Lets take this code:
int main(int argc, char *argv[])
{
int a[argc];
return 0;
}
This compiles fine with g++ foo.cpp, but fails if you require a strict standard compliance.
g++ foo.cpp -std=c++98 -pedantic:
foo.cpp: In function ‘int main(int, char**)’:
foo.cpp:8: warning: ISO C++ forbids variable length array ‘a’
You should use vector<vector<int> *> or vector<int> ** instead as others already suggested.
Simply replace
int ptr[howmany];
with
vector<int> ptr(howmany);
to obtain also automatic deallocation at the end of the scope.