- g++ compiles, msvc crashes, is the code correct? - 3 Updates
- free(): invalid pointer, Aborted - 14 Updates
- Reproducing a sequence from a binary tree... - 4 Updates
- HMI - 1 Update
- std::sort-issue - 2 Updates
- Two different Results between C and C++ - 1 Update
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 06 04:05PM +0200 MSVC bug report: <url: https://developercommunity.visualstudio.com/content/problem/1067774/ice-internal-compiler-error-on-constexpr-range-bas.html> Since the msvc compiler crashes I have only g++'s word that the following code is valid. Is it? --------------------------------------------------------------------------- #include <limits.h> // CHAR_BIT #include <stdint.h> // int... #include <bitset> #include <initializer_list> #include <iostream> #include <string> #include <type_traits> template< class Type > constexpr int bits_per_ = sizeof( Type )*CHAR_BIT; namespace impl { template< int n_bits > struct Int_t_; template<> struct Int_t_<8>{ using T = int8_t; }; template<> struct Int_t_<16>{ using T = int16_t; }; template<> struct Int_t_<32>{ using T = int32_t; }; template<> struct Int_t_<64>{ using T = int64_t; }; // TODO: conditional definition for 128-bits. } // namespace impl template< int n_bits > using Int_ = typename impl::Int_t_<n_bits>::T; template< int n_bits > using Unsigned_int_ = std::make_unsigned_t<Int_<n_bits>>; template< class Enum, int n_bits = bits_per_<void*>, class = std::enable_if_t<std::is_enum_v<Enum>> class Bitset { using Integer = std::underlying_type_t<Enum>; using Bits = Unsigned_int_<n_bits>; Bits m_bits; public: constexpr Bitset( const std::initializer_list<Enum>& values ): m_bits() { for( const Enum v: values ) { const auto i = static_cast<Integer>( v ); if( i < 0 or i > n_bits ) { throw "Ugga bugga"; } m_bits |= (Bits( 1 ) << i); } } }; enum Values {one, two, three, five, seven}; auto main() -> int { constexpr auto x = Bitset({ one, two, five }); // constexpr auto y = Bitset({ 1, 2, 5 }); (void) x; } #include <cppx-core-language/all.hpp> #include <limits.h> // CHAR_BIT #include <stdint.h> // int... #include <bitset> #include <initializer_list> #include <iostream> #include <string> #include <type_traits> template< class Type > constexpr int bits_per_ = sizeof( Type )*CHAR_BIT; namespace impl { template< int n_bits > struct Int_t_; template<> struct Int_t_<8>{ using T = int8_t; }; template<> struct Int_t_<16>{ using T = int16_t; }; template<> struct Int_t_<32>{ using T = int32_t; }; template<> struct Int_t_<64>{ using T = int64_t; }; // TODO: conditional definition for 128-bits. } // namespace impl template< int n_bits > using Int_ = typename impl::Int_t_<n_bits>::T; template< int n_bits > using Unsigned_int_ = std::make_unsigned_t<Int_<n_bits>>; template< class Enum, int n_bits = bits_per_<void*>, class = std::enable_if_t<std::is_enum_v<Enum>> class Bitset { using Integer = std::underlying_type_t<Enum>; using Bits = Unsigned_int_<n_bits>; Bits m_bits; public: constexpr Bitset( const std::initializer_list<Enum>& values ): m_bits() { for( const Enum v: values ) { const auto i = static_cast<Integer>( v ); if( i < 0 or i > n_bits ) { throw "Ugga bugga"; } m_bits |= (Bits( 1 ) << i); } } }; enum Values {one, two, three, five, seven}; auto main() -> int { constexpr auto x = Bitset({ one, two, five }); // constexpr auto y = Bitset({ 1, 2, 5 }); (void) x; } --------------------------------------------------------------------------- - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 06 04:11PM +0200 On 06.06.2020 16:05, Alf P. Steinbach wrote: > Since the msvc compiler crashes I have only g++'s word that the > following code is valid. > Is it? Sorry for the doubly posted code with a spurious #include added. That was due to imprefect editing of a draft where I intended to remove that unnecessary #include. Thunderbird's fault, or Mozilla, or Donald Trump. - Alf |
| Ian Collins <ian-news@hotmail.com>: Jun 07 10:23AM +1200 On 07/06/2020 02:11, Alf P. Steinbach wrote: >> following code is valid. >> Is it? > Sorry for the doubly posted code with a spurious #include added. It doesn't compile with anything, whats "is_enum_v"? -- Ian. |
| alelvb <alelvb@inwind.it>: Jun 06 04:03AM +0200 Il 05/06/20 23:16, Dash ha scritto: > Matrix<double> m {{0,0,1},{0,1,2},{1,0,1}}; //OK > and you'll get the same bounding error. > -- Dash Hello Dash, I've replaced the line as you suggested but my code still works: this is the output: 0 0 1 0 1 2 1 0 1 Determinant = -1 thank you |
| alelvb <alelvb@inwind.it>: Jun 06 04:31AM +0200 Il 05/06/20 23:58, Paavo Helde ha scritto: >> the code for a couple of days without any clue do you believe me? > I guess you don't have the right tools, or you don't know how to use > them. My compiler pinpointed the problem in seconds: Maybe the second ;) > studio\2017\professional\vc\tools\msvc\14.11.25503\include\vector > Line: 1796 > Expression: vector subscript out of range I use code::blocks 17.01 on Debian 10: g++ --version g++ (Debian 8.3.0-6) 8.3.0 My compiler compiled the code without any problem. I made a newbie error. I'm still learning. When I tried to debug the code I got a generic message like: Program received signal SIGABRT, Aborted. No clues of what was happening or why. cppcheck does not spot the problem. When I started playing with programming I tried Java 1.2 and javac spot array out of bound errors on compilation stage. I know C++ doesn't have such a feature but in my opinion it would be a blessing for many people. Thank you for your kind patience alessandro |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 06 05:03AM On Sat, 2020-06-06, alelvb wrote: > g++ (Debian 8.3.0-6) 8.3.0 > My compiler compiled the code without any problem. > I made a newbie error. I'm still learning. Yes, that is stuff you have to learn to investigate. For dealing with problems in runtime, and on Linux, there are at least these things: 0 - building against debug versions of the library (that's what Paavo did) 1 - building with -fsanitize=something 2 - running the code under a debugger 3 - running the code under Valgrind 4 - crashing, getting a core dump and running /that/ one in a debugger Different people prefer different tools; I personally mostly do 3 and 4. > When I tried to debug the code I got a generic message like: > Program received signal SIGABRT, Aborted. > No clues of what was happening or why. This is a side issue, but that's a bit odd, IMHO. On Unix you typically get SIGABRT by calling std::abort(), and that's usually (not always) called by assert() or due to an uncaught exception. In both cases something more should be printed on standard error. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Melzzzzz <Melzzzzz@zzzzz.com>: Jun 06 05:22AM > Program received signal SIGABRT, Aborted. > No clues of what was happening or why. > cppcheck does not spot the problem. Try with eg qtcreator, there you can debug line by line and set breakpoints. -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Juha Nieminen <nospam@thanks.invalid>: Jun 06 07:02AM > Hello folks, > I've written the following code (that I report entirely) > of which I'm not able to find the bug. The first and most important rule of asking such programming questions is to create a *minimal* example that demonstrates the problem. You do not "report it entirely". You go through the trouble of reducing it to the absolutely minimal essential clear version that still exhibits the problem. There are two main reasons for that. Firstly, you should put some effort into it rather than expecting others to do all the work for you. You were lucky that this time someone just ran the code through a debugger which caught the problem. If it had been something more complicated, you would have been expecting people to wade through miles of code to try to find that bug for you. Secondly, when you go through the process of reducing the program to the absolutely minimum that replicates the problem, you are essentially going through a process of elimination, and zoning in the source of the problem. Chances are that you'll end up finding the bug yourself. |
| Bo Persson <bo@bo-persson.se>: Jun 06 10:10AM +0200 On 2020-06-06 at 04:03, alelvb wrote: > 0 1 2 > 1 0 1 > Determinant = -1 The key here is "seems to work". :-) The memory allocator is likely to work in even block sizes. So when you ask for 3 elements, you might get space for 4. Or 8, or 16. It is still an error to use any extra space. Bo Persson |
| alelvb <alelvb@inwind.it>: Jun 06 02:09PM +0200 Il 06/06/20 04:31, alelvb ha scritto: >> work, crash mysteriously, or fail with assert failures like above. And >> yes, in my setup it also fails with assert failures for smaller sizes >> than 4. OK, so let's suppose I didn't make the array out of bounds error... My code would have to function right it is doing now. So how could I spot the problem? Now another question arises: some times the error that I get is something about a double free deletion. But my code uses just std library items and default destructor, default copy constructor and default move constructor and some people report the same issue. What do you think about? thank you, alessandro |
| alelvb <alelvb@inwind.it>: Jun 06 02:10PM +0200 Il 06/06/20 09:02, Juha Nieminen ha scritto: > the absolutely minimum that replicates the problem, you are essentially > going through a process of elimination, and zoning in the source of the > problem. Chances are that you'll end up finding the bug yourself. I'll make treasure of your advices, thank you. alessandro |
| "Öö Tiib" <ootiib@hot.ee>: Jun 06 08:40AM -0700 On Saturday, 6 June 2020 15:09:29 UTC+3, alelvb wrote: > OK, so let's suppose I didn't make the array out of bounds error... > My code would have to function right it is doing now. So how could I > spot the problem? Did you ask that if we suppose that you did not make the error then how are we supposed to spot problem we just supposed that you did not introduce? It is impossible to spot errors that weren't made. > Now another question arises: > some times the error that I get is something about a double free deletion. A program that you wrote does something different than you think that it does. It is normal. After decades of programming and knowing lot of other programmers I can confirm that it happens with everybody forever. More skill improves abilities to notice and to fix it sooner. > copy constructor and default move constructor and some people report the > same issue. > What do you think about? The std library classes are not magical. Nonsense can be expressed using those and lot of situations with those are defined to be undefined behavior. So out-of-bounds with operator [] of vector is defined to be undefined behavior in C++. Your own responsibility as programmer is to ensure that there are no out of bounds accesses. If you want to get exceptions for out-of-bounds accesses use vector::at; if you want to get guaranteed crashes (like Paavo demonstrated) use debug version of standard library. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 06 04:42PM On Sat, 2020-06-06, Öö Tiib wrote: > On Saturday, 6 June 2020 15:09:29 UTC+3, alelvb wrote: ... > The std library classes are not magical. Nonsense can be expressed > using those and lot of situations with those are defined to be > undefined behavior. I have to agree with the OP though: double-free errors are a little bit surprising. I associate those with ownership through raw pointers, and getting it wrong. And I agree with you. What's most important is not having bugs, not what happens when you trigger one. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Paavo Helde <eesnimi@osa.pri.ee>: Jun 06 08:33PM +0300 06.06.2020 15:09 alelvb kirjutas: > copy constructor and default move constructor and some people report the > same issue. > What do you think about? If your own code does not contain any malloc/new/free/delete, then it is indeed surprising to get "double free" errors. I can think only of improper multithreading synchronization or general memory corruption (i.e. a buffer overwrite similar to the last bug). One thing is pretty certain, the bug is in your code, not in the compiler or STL, with 99.99% probability. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 06 08:19PM +0200 On 06.06.2020 19:33, Paavo Helde wrote: > (i.e. a buffer overwrite similar to the last bug). > One thing is pretty certain, the bug is in your code, not in the > compiler or STL, with 99.99% probability. Re compilers it used to be so in the 1980's, when I learned programming. It's no longer the case that compilers are dependable. When I code I regularly encounter compiler bugs & extreme limitations. One MSVC ICE (Internal Compiler Error, a crash) today. Combined with all the ungood stuff in modern Windows, the Microsoft idea of sabotaging "technologies" that they (some MS managers) want to discontinue, I have for some years felt a strong aversion to coding. The last time I was /surprised/ by the sabotage thing was in the early 2000's. I'd made a nice analog clock as a Windows HTML application via HTML+TIME. Suddenly one day the latter"technology" had been discontinued, they'd pulled the rug from under my little app. I don't know if Windows HTML applications still work. It's an HTML file with extension .HTA, running in local security context. It seems that all the desktop gadget "technologies" have disappeared, and they're similar: HTML, Javascript, local security context or sandbox. But, back to C++. Did you know, that MSVC has a 16KB limit on string literals? For example. It's something from original Zortech C I think. - Alf |
| Paavo Helde <eesnimi@osa.pri.ee>: Jun 06 10:40PM +0300 06.06.2020 21:19 Alf P. Steinbach kirjutas: > Re compilers it used to be so in the 1980's, when I learned programming. > It's no longer the case that compilers are dependable. > When I code I regularly encounter compiler bugs & extreme limitations. Although I normally stick to much more traditional coding style than seen in your examples, I have also encountered several compiler bugs - hence the 99.99% estimation of the bug being in my code, not 100%. > the ungood stuff in modern Windows, the Microsoft idea of sabotaging > "technologies" that they (some MS managers) want to discontinue, I have > for some years felt a strong aversion to coding. I believe the key point is to avoid proprietary languages and frameworks which can disappear on a whim. Hence - C++. If MSVC is discontinued, one can switch over to another implementation. > with extension .HTA, running in local security context. It seems that > all the desktop gadget "technologies" have disappeared, and they're > similar: HTML, Javascript, local security context or sandbox. The MS WebBrowser control (usable in a C++ app) is still working and apparently can be configured to support any of the broken IE versions from the past (if we are talking about backward compatibility). > But, back to C++. Did you know, that MSVC has a 16KB limit on string > literals? For example. It's something from original Zortech C I think. No, I did not know that (so obviously the limit has been large enough for my needs). And it seems to be 64K, not 16K, in my quick test: 1>fatal error C1091: compiler limit: string exceeds 65535 bytes in length |
| Ike Naar <ike@sdf.lonestar.org>: Jun 06 08:50PM A few style issues about the code you posted: > friend T determinant(Matrix<T> &matrix, uInt dim) It looks like the determinant function is not supposed to change the matrix. If that's indeed the case, make matrix a const reference instead of a nonconst reference. It also looks like dim is required to be equal to matrix.rows()-1 (and to matrix.columns()-1). If that's indeed the case, remove the dims parameter and use matrix.rows() (or matrix.columns() instead inside the function. > { > return ((r+c)%2 == 0) ? 1 : -1; > } Why is sign() a member function? It doesn't do anything with any member so it might just as well be a free function. > } > count=0; > } count can be moved inside the loop: uInt r=0, maxcols=0; for(auto y : lil) { Uint count = 0; r++; data.push_back(std::vector<T>()); for(auto x : y) { count++; } if(count > maxcols) { maxcols = count; } } |
| Ike Naar <ike@sdf.lonestar.org>: Jun 06 05:45AM > return (sgn( v )*abs_sin_value)*cos_value; > } > }; Have you also the identity sin(v) * cos(v) == 0.5 * sin(2.0 * v) ? I haven't measured, but I would not be surprised if computing 0.5 * sin(2.0 * v) would run faster than either Stdlib or Pythagoras. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 06 11:28AM +0200 On 06.06.2020 07:45, Ike Naar wrote: > ? I haven't measured, but I would not be surprised if computing > 0.5 * sin(2.0 * v) > would run faster than either Stdlib or Pythagoras. Thanks! However, the point (from up-thread context) was not to compute sin*cos, but to compute both sin and cos. The sin*cos function result is just a dependency that, when e.g. stored in a `volatile` variable, prevents the compiler from optimizing away the calls. The sin and cos values are used by the OP's code to find a point on a circle in the complex number plane, specifically one of the n n'th roots of a complex number. - Alf |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 06 11:49AM -0700 On 6/6/2020 2:28 AM, Alf P. Steinbach wrote: > On 06.06.2020 07:45, Ike Naar wrote: >> On 2020-06-04, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> wrote: [...] > The sin and cos values are used by the OP's code to find a point on a > circle in the complex number plane, specifically one of the n n'th roots > of a complex number. Correct. Now, it would be nice to keep everything in polar form. However, I need to do two things with it. Wrt my highly experimental fractal root storage thing, I need to add two complex numbers together. This is not ideal in polar form. So, I convert it into rectangular form via cos and sin. Also, the need to actually plot these damn points is in order. Therefore rectangular form is "needed" to get at the x and y components anyway. Fwiw, I am storing information in the roots of these numbers in the context of a fractal, basically a Julia set. Here is some context on visually plotting these roots: https://en.wikipedia.org/wiki/Julia_set#Using_backwards_(inverse)_iteration_(IIM) Take a fractal, say: z = z^7+c Well, this actually creates a seven ary tree to store data. I am doing this for fun, and it works. An interesting part to me is the the fact that any message can be encoded in a single complex number using this method. The problem is precision... An arbitrary precision package can be used. Its not all that practical to store a large message in a single complex number for the damn real and imaginary parts can contain hundreds of digits each... The main idea is instead of randomly choosing a root, let a stream of real data determine what root to follow during iteration. Btw, is there a technique to add two complex numbers together in polar form that is faster than rectangular form? So far, I am having some trouble finding any. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 06 09:06PM +0200 On 06.06.2020 20:49, Chris M. Thomasson wrote: > Btw, is there a technique to add two complex numbers together in polar > form that is faster than rectangular form? So far, I am having some > trouble finding any. Rform( re1, im1 ) + Rform( re2, im2 ) = Rform( re1 + re2, im1 + im2 ) PForm( v1, m1 ) + PForm( v2, m2 ) = PForm( seriously inefficient calc ) The one exception is when the angles v1 and v2 are identical or opposite, in which case the magnitudes m1 and m2 can just be added or subtracted, respectively. On the other hand /multiplication/ is more efficient in polar form than in rectangular form, namely 1 add + 1 mul versus more for rectangular. Disclaimer: my math knowledge is from college, early 1980's. - Alf |
| Juha Nieminen <nospam@thanks.invalid>: Jun 06 06:54AM >>> consistency with 2001: A Space Odyssey. >> And what exactly does it have to do with C++? > Fuck. Off. You are one of the most vocal opponents of that religious guy who keeps spamming this newsgroup with off-topic posts. You are no different from him. You are both hypocrites. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jun 05 11:33PM -0400 Jorgen Grahn wrote: > I'd expect a quality compiler to optimize them the same way. > (Of course it's different if things like std::strings are involved.) > /Jorgen Sorry, has been off the group for a while. The point was not in unrolling 2-dim array to 1-dim array (although it is also often beneficial in some apps like matrix ops but it's besides the point). parallel vs pairs want make a different for copy of course. The point was in that you have, say, those 50 std::pair<int, int> -- which are logically 2-D vectors (x,y); and you want to e.g. find an array of 50 lengths of these vector using, say, Intel vector instructions for that (some SSE-something), you are better off if you had them in parallel arrays of 50 xs and 50 ys to load to, say, XMM registers and index by a single index register, say, EDI than storing them as an array of 50 pairs (for both load/store streaming and indexing convenience). And, if you only need xs or only ys for some op (say, translate your vectors only up or down or only left or right), it's even more obvious. -Pavel |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 06 06:38AM On Sat, 2020-06-06, Pavel wrote: > array to 1-dim array (although it is also often beneficial in some apps like > matrix ops but it's besides the point). parallel vs pairs want make a different > for copy of course. The point was in that [snip explanation] Thanks. Looking back, it's not clear to me why I thought the context was copying arrays. Perhaps it was, further upthread, /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Jun 06 12:07AM -0400 Real Troll wrote: for 1!=1, the type of relational operator in C++ is bool and in C it is int. -Pavel |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment