compiler-warnings

I would like to make compilation fail for some function call but not others. The function call that I want to fail are those that do not handle return values when the value is of a certain type. In the example below, not handling a function returning Error is a compilation error but not handling a function that returns anything else should succeed just fine. Note: our runtime environment (embedded) does not allow us to use the following constructs: RTTI, exceptions. This code only needs to compiler with Clang, I would prefer not having to annotate each function. We prefer a solution that fails

For class I have an assignment: Write a C++ program that will output the number of distinct ways in which you can pick k objects out of a set of n objects (both n and k should be positive integers). This number is given by the following formula: C(n, k) = n!/(k! * (n - k)!) Your program should use two value-returning functions. The first one should be called factorial and should return n! . The second function should be called combinations and should return n!/(k! * (n - k)!). Test your program for different values of n and k five times (count-controlled loop). I came up with a solution:

I have two very similar methods. The only difference is the use of ClassTag and TypeTag : def matchClass[A: ClassTag](v: Any) = v match { case a: A => "it's A" case _ => "not A" } def matchType[A: TypeTag](v: Any) = ... // same code as matchClass A compile warning will show for matchType , but not for matchClass : abstract type pattern A is unchecked since it is eliminated by erasure case a: A Why is there a warning? why does it show only for TypeTag and not ClassTag ? You don't see a warning for classTag because that check simply works for those: scala> matchClass[Int]("aaa") res82: String =

This question already has an answer here: Why isn't it legal to convert “pointer to pointer to non-const” to a “pointer to pointer to const” 5 answers I have a large codebase that recently moved from Microsoft's compiler to the Intel C++ Compiler. Our team's goal is compilation without warnings in the mainline. Since the switch, one instance of warning 167 has confounded me. If I compile the following code: int foo(const int pp_stuff[2][2]) { return 0; } int foo2(const int pp_stuff[][2]) { return 0; } int main(void) { int stuff[2][2] = {{1,2},{3,4}}; foo(stuff); foo2(stuff); return 0; } The

Given the following code, where x is a dangling const reference to a vanished object, and is therefore undefined behavior. auto get_vec() { return std::vector<int>{1,2,3,4,5}; } const auto& x = get_vec().back(); It seems like neither GCC 7.3 , Clang 6.0 and MSVC is able to emit a warning, even with all warnings enabled. Does anyone know if it is any way to emit a warning in these cases? Is there any difference between const auto& and auto&& in these cases? Note, if back() would return by value, it wouldn't be undefined behavior as the lifetime temporary object x is extended to function scoop.

Background: Consider the following example : #include <iostream> #include <vector> int main() { std::vector<bool> vectorBool{false, true}; for(const auto &element : vectorBool) std::cout << std::boolalpha << element << ' '; return 0; } It emits the warning: test.cpp:6:21: warning: loop variable 'element' is always a copy because the range of type 'std::vector<bool>' does not return a reference [-Wrange-loop-analysis] for(const auto &element : vectorBool) std::cout << std::boolalpha << element << ' '; ^ test.cpp:6:9: note: use non-reference type 'std::_Bit_reference' for(const auto &element :

I have my Eclipse configured to show warnings on missing javadoc comments and tags for public elements. That comes very usefull for me in order to keep my code well documented. But sometimes I have a class, where I have several constants describing for example states of DFA or something.. theres no need to document theese constant, because they are self-explaining.. So I added annotation @SuppressWarnings("javadoc") to the class and here's my point - Eclipse does not concider the annotation and still shows warnings on missing javadocs.. @SuppressWarnings("all") does the job, but that has side