narrowing

Emacs: same buffer, two windows, one narrowed, one not

由 旧城冷巷雨未停 提交于 2019-12-18 11:41:22
问题 I find the narrow-to-region command useful, however it applies to the buffer and not to the current window. I'd like to have one window display a narrowed version of the buffer, while the buffer is displayed widened if it occurs in any other window. Is this possible? 回答1: Try M-x clone-indirect-buffer or C-x 4 c . For details, see Indirect Buffers. 来源： https://stackoverflow.com/questions/2387287/emacs-same-buffer-two-windows-one-narrowed-one-not

Understanding gsl::narrow implementation

由 牧云@^-^@ 提交于 2019-12-17 20:23:02
问题 The C++ Core Guidelines has a narrow cast that throws if the cast changes the value. Looking at the microsoft implementation of the library: // narrow() : a checked version of narrow_cast() that throws if the cast changed the value template <class T, class U> T narrow(U u) noexcept(false) { T t = narrow_cast<T>(u); if (static_cast<U>(t) != u) gsl::details::throw_exception(narrowing_error()); if (!details::is_same_signedness<T, U>::value && ((t < T{}) != (u < U{}))) // <-- ??? gsl::details:

C++11: “narrowing conversion inside { }” with modulus

由 ぃ、小莉子 提交于 2019-12-17 14:51:55
问题 I try to compile the following code with gcc and C++11 enabled: unsigned int id = 100; unsigned char array[] = { id % 3, id % 5 }; I get these warnings: narrowing conversion of ‘(id % 3u)’ from ‘unsigned int’ to ‘unsigned char’ inside { } [-Wnarrowing] see demo online Is there a way to help the compiler find out that the result of id % 3 fits into an unsigned char ? 回答1: In this specific case making id const or constexpr will fix the problem: constexpr unsigned int id = 100; since there is an

Why is “unsigned int ui = {-1};” a narrowing conversion error?

由 江枫思渺然 提交于 2019-12-10 18:16:04
问题 The Standard at § 8.5.4/7 explains what a narrowing conversion is: A narrowing conversion is an implicit conversion — from a floating-point type to an integer type, or — from long double to double or float, or from double to float, except where the source is a constant expression and the actual value after conversion is within the range of values that can be represented (even if it cannot be represented exactly), or — from an integer type or unscoped enumeration type to a floating-point type,

Narrowing conversion of '65280' from 'int' to 'short int' inside { }

由 泪湿孤枕 提交于 2019-12-08 09:01:22
问题 I have two arrays: short GMobiles[18] = {0x0000, 0x0001, 0x0002, 0x0003, 0x0004, 0x0005, 0x0006, 0x0007, 0x0008, 0x0009, 0x000A, 0x000B, 0x000C, 0x000D, 0x000E, 0x000F, 0x00FF, 0xFFFF}; short GMobiles2[18] = {0xFF00, 0xFF01, 0xFF02, 0xFF03, 0xFF04, 0xFF05, 0xFF06, 0xFF07, 0xFF08, 0xFF09, 0xFF0A, 0xFF0B, 0xFF0C, 0xFF0D, 0xFF0E, 0xFF0F, 0xFFFF, 0xFFFF}; When I compile, I get the following message: [Warning] narrowing conversion of '65280' from 'int' to 'short int' inside { } [-Wnarrowing] for

What are the consequences of ignoring narrowing conversions in C++0x

由 爷，独闯天下 提交于 2019-12-07 01:46:55
问题 Since switching on the C++0x standard in g++, I've started seeing 'narrowing conversion' errors, particularly when converting from an 'int' to a 'short' although I understand the error covers a much broader swath of conversions. Can anyone shed some light on the rational for introducing this extra level of safety?, What are the possible consequences of disabling this error? (apart from the potential loss of precision). Thanks. 回答1: From Assignment and compound assignment operators [expr.ass]

Optional<> and return type narrowing

由 亡梦爱人 提交于 2019-12-07 01:10:22
问题 In Java < 8, returning "unsafe" objects (objects or null), I was able to specialize return type in subclass: class A {} class B extends A {} interface Sup { A a(); /* returns A instance, or null */ } interface Sub extends Sup { B a(); } In Java 8, if I want to make my API "safer", I should return Optional<A> instead of "raw" A : interface Sup { Optional<A> a(); } interface Sub extends Sup { Optional<B> a(); } But doesn't compile! Because Optional<B> is not a subclass of Optional<A> . How I'm

float to double misinterpretation??? g++

由 微笑、不失礼 提交于 2019-12-06 08:16:46
for some reason I'm getting the following warning filename.cpp:99:53: warning: narrowing conversion of ‘sin(((double)theta))’ from ‘double’ to ‘float’ inside { } [-Wnarrowing] filename.cpp:99:66: warning: narrowing conversion of ‘cos(((double)theta))’ from ‘double’ to ‘float’ inside { } [-Wnarrowing] which makes it sounds like it's trying to use the 'double cos(double)' etc. instead of 'float cos(float)' etc. I keep trying to think of more ways to suggest this to the compiler but am not getting anywhere. What can I do to resolve this? void foo(float theta) { theta = (float)M_PI*theta/180.0f;

Why doesn't C++ show a narrowing conversion error when casting a float to a char?

由 做~自己de王妃 提交于 2019-12-05 23:31:43
问题 Compiling this code using g++ -std=c++17 -Wall -pedantic main.cpp doesn't produce any warnings: #include <iostream> #include <stdlib.h> int main(int argc, char const *argv[]) { for (int i = 0; i < 100; ++i) { float x = 300.0 + rand(); char c = x; std::cout << c << std::endl; } return 0; } Shouldn't it produce a narrowing error? 回答1: I did some research and I found that -Wall doesn't warn about type conversion issues. Instead, use the flag -Wconversion in order to get a warning about potential

What are the consequences of ignoring narrowing conversions in C++0x

由 吃可爱长大的小学妹 提交于 2019-12-05 05:38:07
Since switching on the C++0x standard in g++, I've started seeing 'narrowing conversion' errors, particularly when converting from an 'int' to a 'short' although I understand the error covers a much broader swath of conversions . Can anyone shed some light on the rational for introducing this extra level of safety?, What are the possible consequences of disabling this error? (apart from the potential loss of precision). Thanks. From Assignment and compound assignment operators [expr.ass] The meaning of x={v}, where T is the scalar type of the expression x, is that of x=T(v) except that no
订阅 narrowing