Arghhhhh!...I Did It Again
-
Strange to hear someone complaining about this. It took a couple of seconds to guess that library dependencies weren't being updated without rebuild all. Makes very little difference to procedure.
Not sure what you mean here. The issue about updated header file is unrelated to my original problem that was solved by doing a Rebuild All. The problem I have had with updating a header file was more of an annoyance. As an example, I would add a new constant to a globally used header file, use that new constant in a project that included the header file (indirectly) and it would spit out an error because the update was not being detected. A Rebuild All will also fix this, but it seems odd that it was needed. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
Not sure what you mean here. The issue about updated header file is unrelated to my original problem that was solved by doing a Rebuild All. The problem I have had with updating a header file was more of an annoyance. As an example, I would add a new constant to a globally used header file, use that new constant in a project that included the header file (indirectly) and it would spit out an error because the update was not being detected. A Rebuild All will also fix this, but it seems odd that it was needed. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
Ah, updated header file; yes, that is more of an issue. I was thinking that the original commenter was referring to altered libraries, typically dll's on a MS system. My mindset isn't C/C++ at the moment, as I've spent the last three years using C# when in MS, with occasional forays into traditional languages on MonoDevelop(Linux). Actually if you look at MonoDevelop C/C++ library resolution, it offers a great deal that VS doesn't have; for example, if you put ANY dev package onto your system, Mono will offer 1-click access to an autodetected list, and once the dependencies are fixed, they generally stay that way. :)
-
Ah, updated header file; yes, that is more of an issue. I was thinking that the original commenter was referring to altered libraries, typically dll's on a MS system. My mindset isn't C/C++ at the moment, as I've spent the last three years using C# when in MS, with occasional forays into traditional languages on MonoDevelop(Linux). Actually if you look at MonoDevelop C/C++ library resolution, it offers a great deal that VS doesn't have; for example, if you put ANY dev package onto your system, Mono will offer 1-click access to an autodetected list, and once the dependencies are fixed, they generally stay that way. :)
Actually the library projects I was referring to in my original post create lib's, some of which are linked into the application I was debugging. The crash occurred when an object was deleting a buffer 'containing' an image. I had been modifying the library that handled the image buffer for display and it seemed plausible, that I could have messed something up. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
Actually the library projects I was referring to in my original post create lib's, some of which are linked into the application I was debugging. The crash occurred when an object was deleting a buffer 'containing' an image. I had been modifying the library that handled the image buffer for display and it seemed plausible, that I could have messed something up. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
Ah, I see. Still, these challenges to our reasoning are all part of the fun, yes? :)
-
Ah, I see. Still, these challenges to our reasoning are all part of the fun, yes? :)
Sure. I suppose you could say it is an extension to how it would be so much easier and faster to develop software if you never had to account for failure scenarios in the code. :) Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
Not sure what you mean here. The issue about updated header file is unrelated to my original problem that was solved by doing a Rebuild All. The problem I have had with updating a header file was more of an annoyance. As an example, I would add a new constant to a globally used header file, use that new constant in a project that included the header file (indirectly) and it would spit out an error because the update was not being detected. A Rebuild All will also fix this, but it seems odd that it was needed. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
We used to have these kind of errors occasionally in our application, until I decided to clean up our headers. For each of them I went through the following steps: 1. comment out all
#includestatements 2. create a .cpp file that just includes the header and nothing else (except maybe precompiled header, if you have one) 3. compile that file and work through compiler errors as follows: 3.1 for each 'unknown symbol' try fixing it with a forward declaration 3.2 if that doesn't work, find the header containing the declaration, and postpone the work on this header until you're done with that other header; then include the other header in this header 3.3 once there are no more compiler errors, find all .c or .cpp files that include this header and try compiling those: they may use symbols from header files that were formerly included by this header file; if so, #include the required headers directly in the .c/.cpp file 3.4 remove the still commented out #include statements from your header (they only served to aid in looking up required includes for you source files in the previous step) It took me more than a week, but as a result, build times were reduced considerably (from more than 5 minutes down to 1.5), and to my knowledge we've never got any such build dependency problems again. At least not by changing a header. (changes in external libraries were another matter...) -
We used to have these kind of errors occasionally in our application, until I decided to clean up our headers. For each of them I went through the following steps: 1. comment out all
#includestatements 2. create a .cpp file that just includes the header and nothing else (except maybe precompiled header, if you have one) 3. compile that file and work through compiler errors as follows: 3.1 for each 'unknown symbol' try fixing it with a forward declaration 3.2 if that doesn't work, find the header containing the declaration, and postpone the work on this header until you're done with that other header; then include the other header in this header 3.3 once there are no more compiler errors, find all .c or .cpp files that include this header and try compiling those: they may use symbols from header files that were formerly included by this header file; if so, #include the required headers directly in the .c/.cpp file 3.4 remove the still commented out #include statements from your header (they only served to aid in looking up required includes for you source files in the previous step) It took me more than a week, but as a result, build times were reduced considerably (from more than 5 minutes down to 1.5), and to my knowledge we've never got any such build dependency problems again. At least not by changing a header. (changes in external libraries were another matter...)It sounds like the right thing to do. I am just not sure it is feasible to do on our codebase. I have done something along those lines on some of the projects, but not quite to the extent you are laying out. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
-
It sounds like the right thing to do. I am just not sure it is feasible to do on our codebase. I have done something along those lines on some of the projects, but not quite to the extent you are laying out. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
I did it more for defragging header dependencies than anything else, and served me to get a grip on the codebase while I was still learning its layout. There were other reasons too, but without that much incentive I wouldn't have bothered spending a full week. I suppose it's worth it to occasionally check parts of your code in that manner if you feel you get too much inter-header-dependencies. But going over an entire codebase ... well you need a good reason for that. :cool:
-
I was trying to figure out why this new crash started happening in code that had been working for years. I was running my application in the debugger and had recently made some changes in related library code, so I concentrated on tearing that apart. I finally decided to do a Rebuild All on the entire library solution (39 C++ projects) followed by a Rebuild of the application. Voilà! No more crashing. I occasionally run into this kind of unexplained behavior and I always seem to fiddle around "too long" before I go with the Rebuild All attempt. This time it probably took me less than an hour before I smartened up, but it still annoys me to waste that time. At least I can now go to bed without this bug invading my dreams. :-\ Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
I have a series of applications that I've written that are used internally for a manufacturing company I work for. Most of these applications are very simple programs, and they just help automate a few processes that can otherwise takes hours to do manually. On occasion a database moves or some other network change occurs, and I have to crack open VS2008, make a slight modification, recompile and deploy my application. For many of these applications, on a recompile of the app, the program would break in odd places, when all I've done is updated a title bar or something! Very annoying. Turns out, it was a breaking change in C# and this isn't, technically, a bug. The problem has to do with hardcoded 0's when calling methods with multiple signatures. My old app would work, because it was compiled under an old variation of C# and the .Net compiler. When it was recompiled, however, the application would break, even though the code hasn't changed. I'm not trying to write thesis, but if you want to read the thorough details of this oddity, check out my specific question I ask on StackOverflow[^].
-
1. Don't you mean "Oops!", not "Argh!" ? 2. I have found 2012 to be quite poor at rebuilding c++ files when headers have changed, and I don't really have a very complex group of projects in my solution. Luckily, it becomes very clear when you step into a function in another module, and it's the wrong function... Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
Iain Clarke, Warrior Programmer wrote:
I have found 2012 to be quite poor at rebuilding C++ files..
This should be no surprise to anyone here -- Visual Studio has been poor at this from day one.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
I was trying to figure out why this new crash started happening in code that had been working for years. I was running my application in the debugger and had recently made some changes in related library code, so I concentrated on tearing that apart. I finally decided to do a Rebuild All on the entire library solution (39 C++ projects) followed by a Rebuild of the application. Voilà! No more crashing. I occasionally run into this kind of unexplained behavior and I always seem to fiddle around "too long" before I go with the Rebuild All attempt. This time it probably took me less than an hour before I smartened up, but it still annoys me to waste that time. At least I can now go to bed without this bug invading my dreams. :-\ Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
Aaaahhhh! the magic of Rebuild All... I've always found C++ support on Visual Studio flimsy, but wait until you mix managed with unmanaged code (or do some C++/CX in a WinRT Component) and the fun it's endless.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I was trying to figure out why this new crash started happening in code that had been working for years. I was running my application in the debugger and had recently made some changes in related library code, so I concentrated on tearing that apart. I finally decided to do a Rebuild All on the entire library solution (39 C++ projects) followed by a Rebuild of the application. Voilà! No more crashing. I occasionally run into this kind of unexplained behavior and I always seem to fiddle around "too long" before I go with the Rebuild All attempt. This time it probably took me less than an hour before I smartened up, but it still annoys me to waste that time. At least I can now go to bed without this bug invading my dreams. :-\ Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
My first guess would be an uninitialized variable floating high or low. In the n years you've been working on it, it floated in the right direction. One day, it decided to float in the wrong direction and then crashitis. Have you now got a faster or slower machine? That causes crashes sometimes. Also beware of #pragma library statements: they do this weird thing of copying libraries all over the place (you'll notice that in C#). On one project, I had 115 copies of the same library and they don't always update. Welcome to the world of versionitis.
-
My first guess would be an uninitialized variable floating high or low. In the n years you've been working on it, it floated in the right direction. One day, it decided to float in the wrong direction and then crashitis. Have you now got a faster or slower machine? That causes crashes sometimes. Also beware of #pragma library statements: they do this weird thing of copying libraries all over the place (you'll notice that in C#). On one project, I had 115 copies of the same library and they don't always update. Welcome to the world of versionitis.
No, it's nothing like that. As I mentioned, a Rebuild All fixed the problem. All the .lib files are stored in the same folder and there are no copies floating around, but thanks for the heads up about that in C#:thumbsup: I have been looking at the library that had the crashing code. It does not have dependency set to the library I had modified, but I have not yet found anything that warrants that. I think I will go ahead and add the dependency, just to help minimize these problems in the future. Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty