I have looked up all I need to know on how to use a stopwatch, but I can't find out how to create one. MSDN has the info System.Diagnostics::Stopwatch but I don't know how to include system diagnostics into my program. Is there a #include and/or using namespace that I need?
I believe it's:
using namespace System::Diagnostics
This is in C++/cli which has access to c# libraries.
Related
I would like to know about this.
the relationship between #include and getch() method
What is the relationship between #include and getch() method?
getch() is declared inside the header file of conio.h, so you need to set the preprocessor directive #include <conio.h> in order to you use getch(). Without #include <conio.h> you can not use getch().
Note: conio.h is not supported by all C/C++ implementations and is not part of the C standard libraries. Rather use getc() or getchar() for catching a character from the input if you want to compile C or C++ code on Unix or Linux.
Your comment:
Mam, thank you for pointing out me. But, it would be very helpful to understand if you put some clarification of using it, mam.
Beside the case, that this is not the question you have asked for, this is not how Stack Overflow works. This is not a tutorial platform; it is a platform to ask for help if you did not understand a certain topic. You need to declare what you did not understand and we can help you.
If you look for a tutorial about getch(), here is one:
https://www.geeksforgeeks.org/difference-getchar-getch-getc-getche/
By the way, I´m not a Mam, but Ok.
In languages like java, a package name is a domain name, like com.foobar.mystuff.
So if you own com.foobar, it is highly unlikely that someone would have used the package name com.foobar, you can be reasonably sure there will not be a collision.
But in c++, you can choose any namespace name. How do you know if a library you are linking to, is not already using a particular namespace name ? Is there a way to test it, especially if you don't have access to source code or documentation ? Is there some guideline to avoid this problem ?
Is there some guideline to avoid this problem?
While it may surprise you to find that one of the third party libraries you are using uses a namespace as your application, it shouldn't cause too much problem, if any.
In the worst case scenario, you'll have to create a namespace that is specific to your application and create nested namespaces under the main namespace.
I am writing c++ in eclipse. When I add a new class it asks for a namespace. I added boost because I am using boost. When I looked at the class eclipse surrounded my class with namespace boost{}. I thought namespace was for java/c# not a c++. Also, I did a little research and it looks like adding namespace boost is a big no no. So I deleted namespace boost. One question, is there a good reason why I should of kept namespace boost and will erasing it haunt me later in the dev cycle?
Thanks, that what I thought. I don't know why eclipse wants me to add a namespace
Erm. #Aaron, "adding" a namespace is good practice, unless you want to be thrown back into the era of C APIs with eternal clashes library symbols or clumy libraryx_myfunction naming conventions.
In fact, chosing a proper namespace for your classes is so elementary that I'd rephrase that. It's not
adding a namespace to your class;
Rather it is
creating a namespace for your to (later) add types and functions to.
Namespaces serve to separate your code from LibraryX and LibraryX from LibraryY etc. Therefore it is indeed bad practice to chose a namespace name that is likely to collide. Defining user defined types is expressly prohibit in the std namespace (or Undefined Behaviour ensues).
Putting stuff into other lirary's namespaces is asking for trouble with
future extensions of the library
internal, undocumented symbols in those libraries
subtle bugs due to ADL (where the library might start finding your function(s) instead of it's own without knowing)
A good reason why I should keep namespace boost?
Why? Are you extending the boost library? I don't see any reason to keep namespace boost, in fact, for small projects, you do not need a namespace at all. Namespaces are designed to prevent name conflict, and for a small project, I doubt you'll have any (be careful about swap though).
Basically speaking, your question is almost the same as asking why I shouldn't surround my code with namespace std, after all, I am using the standard library, right?
I need to generate random names which I'll be using to create temporary files in a directory. Currently I am using C standard function tempnam() for this. My code is in C++ and would like to use C++ equivalent for doing the same task. The code needs to work on Solaris as well as on Windows.
Is anyone aware of such thing in C++? Any pointer on this would be highly appreciated.
Try std::tempnam in the cstdio header. ;)
The C standard library is still available in C++ code. For convenience, they provide C++ wrappers (in headers with the 'c' prefix, and no extension), and available in the std namespace.
You can also use the plain C version (stdio.h and tempnam in the global namespace, but you did ask for the C++ version ;))
The C++ standard library only provides new functions when there's actually room for improvement. It has a string class, because a string class is an improvement over char pointers as C has. It has a vector class, because, well, it's useful.
For something like tempnam, what would C++ be able to bring to the party, that we didn't already have from C? So they didn't do anything about it, other than making the old version available.
I know this doesn't answer your question but as a side note, according to the man page:
Although tempnam(3) generates names
that are difficult to guess, it is
nevertheless possible that between the
time that tempnam(3) returns a
pathname, and the time that the
program opens it, another program
might create that pathname using
open(2), or create it as a symbolic
link. This can lead to security
holes. To avoid such possibilities,
use the open(2) O_EXCL flag to open
the pathname. Or better yet, use
mkstemp(3) or tmpfile(3).
Why not just using the same function you are currently using in C? C++ is backward compatible with C.
What's wrong with tempnam()? You can use regular libc function right? tempnam is in stdio.h, which you're likely already including.
#include <cstdio>
using std::tmpnam;
using std::tmpfile;
You should also check this previous question on StackOverflow and avoid race conditions on creating the files using mkstemp, so I would recommend using std::tmpfile
I have some custom dtrace probes in a C-library, and when linking and using the library with a C application my probes work fine, however when linked against C++ it says it can't find them. The reason seems to be because of C++ mangling, and trying to get it to work has become a duck chase.
Any ideas?
Note: Using gcc
So far I've found these "useful" links
Using DTrace to Profile and Debug A C++ Program
Using DTrace SDT provider with C++
but they haven't solved my problems.
Later on I found these articles:
User-land tracing gets better and better //this was very helpful
Putting developer-defined DTrace probe points in an application
Dtrace Using SDT probes //pdf that helped understand some details, but information is old
Basically it all boils down to using dtrace -h to headerfiles from ones probes.d
Did you try extern "C" { ... } when declaring the C functions?