- Valgrind finds memory leak on ImVector<char[4096]>::resize(). Why? - 2 Updates
- About C++ ... - 1 Update
- Valgrind finds memory leak on ImVector<char[4096]>::resize(). Why? - 2 Updates
- Weird release build bug - 8 Updates
- uninitialized build-in types - 2 Updates
| ram@zedat.fu-berlin.de (Stefan Ram): Dec 18 09:33PM >Valgrind finds memory leak on ImVector<char[4096]>::resize(). Why? It might be a bug in the library. Or it might even be by design, which should be explained in the documentation. Or, otherwise: When a container is decreased in size, pointers to objects might become unreachable. This might have the consequence that these objects are not freed properly. |
| bleachbot <bleachbot@httrack.com>: Dec 19 12:00AM +0100 |
| Ramine <ramine@1.1>: Dec 18 06:07PM -0800 Hello, You have seen me inventing my parallel algorithms and synchronization algorithms, you can find all my project here: https://sites.google.com/site/aminer68/ And what i have been doing today is that since i have wrote my projects with Delphi and FreePascal, i have tried to port them to C++, so first comes first, i have first enhanced a library that was wrote in C++ and that permit to call a Dynamic library under Linux, Mac OSX and Windows, this library that was wrote in C++ was not working and i have enhanced it and corrected its bugs so that it works with C++Builder and with GCC and with Visual C++ on x86 architecture, and now it's working well, so now with this C++ library i have started to port my projects to C++, but when i was in the process of porting my projects i have encountered some problems that are inherent to the C++ Compilers, for example the GCC C++ compiler doesn't come with a scalable memory manager such as the Intel TBB malloc, so i have tried to compile the Intel tbbmalloc with GCC , but because of some bugs it didn't compile with GCC, and the scalable Hoard memory manager doesn't come with a makefile so that it compiles with Mingw 32bit and 64 bit, other than that the C++11 doesn't even come with a good Threadpool such as the one i wrote in Delphi and FreePascal, so i have realized then that C++ is not as good as it appear to us, so i am disapointed with C++, and i am discovering now that since i have knew more C++, that Delphi and FreePascal are becoming more attractive than C++, because i have invented many parallel algorithms and many sychchronization algorithms for them and FreePascal does even come with a portable and scalable memory manager such the tbbmalloc. Thank you for your time. Amine Moulay Ramdane. |
| Flix <writeme@newsgroup.com>: Dec 18 10:19PM +0100 Hi everybody. I'm using a library called https://github.com/ocornut/imgui, that includes a very simple template class called ImVector. This class is commented in this way: // Lightweight std::vector<> like class to avoid dragging dependencies (also: windows implementation of STL with debug enabled is absurdly slow, so let's bypass it so our code runs fast in debug). // Our implementation does NOT call c++ constructors because we don't use them in ImGui. Don't use this class as a straight std::vector replacement in your code! I thought that char arrays had no C++ constructor/destructor. Why do Valgrind complains when resizing the array ? |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Dec 18 02:56PM -0700 On Fri, 18 Dec 2015 22:19:35 +0100, Flix <writeme@newsgroup.com> wrote: >replacement in your code! >I thought that char arrays had no C++ constructor/destructor. >Why do Valgrind complains when resizing the array ? Can you post a small program that reproduces the problem? Louis |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 18 12:29AM +0100 On 17.12.15 22.53, Patricia Anaka wrote: > Thanks for the replies! I spent some time experimenting with restructuring the loop. It turns out that it was the little "j = i++" thing in the loop that caused it. I would not bet that this is the full truth. As you have seen other changes cause the code to work too. > So in other words, this works. Which compiler did you use. > So weird! Your first optimizer bug, isn't it? Marcel |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Dec 18 01:21AM -0700 On Thu, 17 Dec 2015 13:53:38 -0800 (PST), Patricia Anaka > return c; >} >So weird! If your compiler is up to date, and if you want to go to the trouble of creating a really simple test case, you can report this to the vendor. This can be trickier than it sounds, since you don't really know what triggers the bug. Instead of using i and j to index an array, you might want to try saving their values in another array which you would then print at the end of the function. You want to make the bad output obvious. As a wild guess, I would give something like this a shot: struct { int i; int j; } ij[1000]; // pick an upper bound int k = 0; for (i = 0, j = nvert - 1; i < nvert; j = i++) { // printf("i %d j %d\n", i, j); ij[k].i = i; ij[k].j = j; k++; } for (i = 0; i < k; i++) printf("i %d j %d\n", i, j); It can be a fair amount of work, but if it results in a better compiler, it could save you and other users a lot of time and trouble down the road. Louis |
| David Brown <david.brown@hesbynett.no>: Dec 18 09:25AM +0100 On 18/12/15 00:23, Marcel Mueller wrote: >> that a compiler bug is at fault. It is not impossible - but it is far >> down in the list of suspects. > You didn't work much with Borland C++ compilers, didn't you? Not much, though I have heard their reputation. None of the major PC compilers (gcc, clang, MSVC, icc) these days are at all likely to have such issues. (I have seen a number of compiler bugs over the years in the dozens of different tools I have used.) >> When you subtract almost identical floating point values, you are likely >> to have all sorts of numerical stability problems - the subtraction > This might be part of the problem indeed. This is certainly a problem in the code - but it might be an additional problem rather than the only one. As I said, compiler bugs are /possible/, but they are not the first place to look. |
| bsabiston@gmail.com: Dec 18 07:27AM -0800 The code is certainly not bullet-proof, but there's only a problem with it if the point values are ever going to be very close to each other. Which in my case, is not the case. And as I said before, that issue is certainly not causing the problem for which I was requesting help. |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 18 11:37AM -0600 Patricia Anaka <panakabear@gmail.com> wrote in > Thanks for the replies! I spent some time experimenting with > restructuring the loop. It turns out that it was the little "j = i++" > thing in the loop that caused it. It looks like the optimizer recognized a regular loop pattern and optimized the loop somehow, but failed to notice there is a side-effect of assigning j, and thus it got lost. What happens if you replace the "j = i++" with "j=i, i++"? Care to tell us the compiler name and version so we would know to take care when dealing with it? |
| Patricia Anaka <panakabear@gmail.com>: Dec 18 10:27AM -0800 > the loop somehow, but failed to notice there is a side-effect of assigning > j, and thus it got lost. > What happens if you replace the "j = i++" with "j=i, i++"? If I do that, then it works. > Care to tell us the compiler name and version so we would know to take care > when dealing with it? It's the ARM CC 5.04 compiler, a version which I think is specifically for Nintendo (3DS). |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 18 01:16PM -0600 Patricia Anaka <panakabear@gmail.com> wrote in >> side-effect of assigning j, and thus it got lost. >> What happens if you replace the "j = i++" with "j=i, i++"? > If I do that, then it works. Yes, it looks like the optimizer now noticed that it cannot optimize so heavily. >> take care when dealing with it? > It's the ARM CC 5.04 compiler, a version which I think is specifically > for Nintendo (3DS). Thanks. As suggested by others you might consider filing a bug report if this is the latest released version and you can come up with a small complete example program whose behavior depends on that change (looks like you have already done that). |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Dec 18 01:49PM -0700 On Fri, 18 Dec 2015 10:27:16 -0800 (PST), Patricia Anaka >> Care to tell us the compiler name and version so we would know to take care >> when dealing with it? >It's the ARM CC 5.04 compiler, a version which I think is specifically for Nintendo (3DS). It looks like 5.04 is at least a year old; 5.05 and 5.06 have been released: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472j/index.html About 20 years ago, I earned a living as a consultant porting C++ code from one buggy compiler to another -- cfront, DEC C++, Solaris C++, etc. I had one client who preferred to pay me to pull all-nighters working around compiler problems rather than pop for an upgrade. I had one gentleman at another site tell me I hadn't found a compiler bug until he found out the upgrade was free and then it was OK to say it was a compiler bug. When I found bugs in up-to-date compilers, I'd report them to the vendor. Louis |
| David Brown <david.brown@hesbynett.no>: Dec 18 09:10AM +0100 > what Rust and D had to offer up there - at least I'd know that when > coding in layer #1 I'd have known default values for int/bool/etc - > which is the only place I've found myself wanting that behavior. It is still going to be much easier to mix some C++11 with the C++03 stuff than to bring in D or Rust. The chances are high that the C++03 stuff will compile fine with C+11 standards, but you might have to be careful with api settings to make the linking match up (gcc at least gives you control of that from command-line switches - I don't know what compiler you are actually using here). > this into a C++ rant - I love the language dearly. I guess I was hoping > D and/or Rust might help with those areas too (no idea - almost > completely ignorant of their features). By all means, investigate D and Rust. Even if you don't use them in the end, you could get new ideas or inspiration to bring back to your C++ programming. Just don't expect wonders here - you might find a few nice points in these languages compared to C++, but you will also lose a lot - and I doubt if the balance is worth the effort of mixing the languages. (It is a another matter if you go for Python or something seriously different, where there are some things that are /much/ easier.) > ... and then somewhere else, perhaps a different file altogether: > Foo::Foo() : x_(0) { } > Which does come back to C++11 again. It's very simple. Either it doesn't matter that x_ is not initialised (and for many members, that is the case), or you initialise it in the class's constructor. That is what the constructor is for! >> have much more impact. > You may be right. > GOD I hope I got the annotations right this time!!!!!! Yes, the /attributions/ were absolutely fine - thanks. (You still haven't fixed your wrapping problem. It is quick enough for others with proper newsclients to re-wrap some posts, but it's a pain when you have formatted text such as code or lists. Again, I know this is a problem when using google groups. If you switch to a proper newsclient, you'll find Usenet far easier to use. GG is fine for searching across a range of groups, but for regular use a newsreader is much more efficient and convenient.) |
| flimflim1172@gmail.com: Dec 18 10:18AM -0800 On Friday, December 18, 2015 at 1:11:05 AM UTC-7, David Brown wrote: > careful with api settings to make the linking match up (gcc at least > gives you control of that from command-line switches - I don't know what > compiler you are actually using here). C++ from one compiler vendor cannot link against C++ from another compiler vendor, irrespective of whether either or both are 11 or 03. Name mangling won't match at the very least, among other issues. I can't build C++ (with say gcc) on top of C++ built with ghs for instance (one of the specific compilers I can't opt out of). A C layer would have to be in between them for the standard ABI. I'd feel a bit silly having C++ on C on C++. It would get me some C++11 features for some of the code, but I'd feel less silly if I was doing that for Rust or D or something else entirely. Rust on C on C++ looks less nuts somehow. Also, C++11 allowing me to write member x_ = 0 in my class declarations gets me close, but not 100% to where I'd rather be with respect to member variables. Again, this applies only to particular subsets of my code, where it's tangibly better for me if all objects default construct to the most likely desired initial state (like vector<int> does), rather than the fastest establishment of invariants (like both int and vector<int> do as you pointed out). I don't know much about D or Rust yet, but I do know they both do this. I naively thought "hey, allowing x = std::unspecified" (or x = void like D) would be having the cake and eating it too, but I accept the wisdom of others that this would do more harm than good. Many in my particular industry have long abandoned pure C++, opting for a mix of C++ and something else (often lua or C#) I'm slowly & stubbornly realizing that perhaps they're not all just crazy kids. > It's very simple. Either it doesn't matter that x_ is not initialised > (and for many members, that is the case), or you initialise it in the > class's constructor. That is what the constructor is for! That's not my issue either. I am neither unwilling to write local "int x = 0", nor am I unsure where I am required to initialize member x_. For member x_, the few seconds it takes to initialize in the required location is an insignficant non-issue much of the code I write, but a tangible source of minor drag in other code I write. I don't want to break the language to satisfy my desires in those specific contexts, and I accept that the suggestion of "int x is zero unless stated unspecified" would do just that. I think I just need a highly iterative language to sit on top of my highly optimized language. Might not be D or Rust. I've done nothing other than C++/C/ASM for my entire career, so other languages are very new ground for me. |
| 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