| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- C++ name mangling. - 1 Update
- Finding indirectly included header files - 4 Updates
- Improving a tutorial on the Visitor pattern - 1 Update
- Question about definition of static template member - 1 Update
| Martijn Lievaart <m@rtij.nl.invlalid>: Nov 09 11:09PM +0100 On Fri, 07 Nov 2014 16:54:56 -0500, DSF wrote: > mean "That's not important." or "That's none of your concern." > or does it mean "Is this important to your current work, or are you > going off on an unnecessary tangent? Or even a poorly worded "Why would you ever want to do this?" or "I sense you are solving the wrong problem". M4 |
| Paul <pepstein5@gmail.com>: Nov 09 05:39AM -0800 I am using the code blocks IDE with Mingw, gcc and Windows 7. I've noticed that when I #include<iostream> I get access to the functions in stl_algobase.h However, I can't see a way to anticipate that. What is the most straightforward way to find the files indirectly included by my #include preprocessor statements. Thank you, Paul |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 09 08:53AM -0600 Paul <pepstein5@gmail.com> wrote in > in stl_algobase.h However, I can't see a way to anticipate that. > What is the most straightforward way to find the files indirectly > included by my #include preprocessor statements. g++ -M myfile.cpp or g++ -MM myfile.cpp The latter leaves out system headers. Note that you cannot rely much on which system headers include others, this may easily change in the next version (unless documented in the standard, of course). |
| Paul <pepstein5@gmail.com>: Nov 09 07:32AM -0800 On Sunday, November 9, 2014 2:53:29 PM UTC, Paavo Helde wrote: > The latter leaves out system headers. Note that you cannot rely much on > which system headers include others, this may easily change in the next > version (unless documented in the standard, of course). Thanks, Paavo. I did indeed get both your commands to work in the way that you said. However, it's not clear to me from the output exactly which files are included in which headers. Maybe, it isn't supposed to be clear, and the right way is just to include everything that may be needed, with standard header guards used to prevent multiple declarations. For example, the below code seems to work with gcc. But it might be bad, and the better method might be to #include<algorithm> even though it isn't needed. #include <iostream> using namespace std; int main() { int x = min(5, 3); cout << x; } |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 09 10:27AM -0600 Paul <pepstein5@gmail.com> wrote in > included in which headers. Maybe, it isn't supposed to be clear, and > the right way is just to include everything that may be needed, with > standard header guards used to prevent multiple declarations. That's right. The only reliable source about which system headers include other headers is the standard. <iostream> for example is documented to include <ios>, <streambuf>, <istream> and <ostream>. > For example, the below code seems to work with gcc. But it might be > bad, and the better method might be to #include<algorithm> even though > it isn't needed. Of course, if your code uses std::max(), it should include <algorithm>. There is no excuse to avoid that, even if the code might sometimes appear to accidentally compile without that. And you can be sure all the needed include guards are present in the system headers. Cheers Paavo |
| "Tobias Müller" <troplin@bluewin.ch>: Nov 09 01:54PM > However, I am concerned about the code duplication here -- the line > v.visit(this) is just repeated verbatim regardless of what member of the > Element hierarchy v represents. This doesn't strike me as good design. The point of the visitor pattern is that the accept method is _not_ the same on every class in the hierarchy. It just _looks_ the same because the visit method is overloaded. In a language without overloading this would be obvious, there would have to be a visitThis(), visitThat(), visitOther() method. Tobi |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 09 01:10AM -0600 Vir Campestris <vir.campestris@invalid.invalid> wrote in news: >> particular, the compiler can choose to optimize it fully away > For an int (or similar) that's what I'd expect. I tend to use static > const... to replace #defines for exactly that reason. For a static const data member, the compiler can (and in most cases probably must) do both. It can optimize away all usages and use the immediate value in the generated code, and it can still place the constant also somewhere in some data segment, so that it has a consistent address, should some other code pieces happen to take it. Cheers Paavo |
| 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