Ways to insert unique ID into a logging function

[ahmd]

I'm writing a logging function for my service app and I need some way to come up with a unique ID to use in it. Here's what I mean. Say, I wrote a function:

void ReportIntoLog(UINT nUniqueID)
{
    //INFO: This is not my actual function. I'm giving it here to show the concept
    CString s;
    s.Format(_T("Time: %s, Error ID: %d"), 
        COleDateTime::GetCurrentTime().Format().GetString(),
        nUniqueID);
    RawWriteIntoLogFile(s);
}

And then, say if I have a situation I'd like to report in the log:

MY_BIG_ARRAY* pArray = new(std::nothrow) MY_BIG_ARRAY;
if(Array)
{
    //Work with array
}
else
{
    ReportIntoLog(1);
}

OK, now my question. Obviously, I will need to use unique ID each time ReportIntoLog is called. First, I was trying to come up with sequential IDs manually as I was inserting ReportIntoLog into my service, but it soon became apparent that it is quite challenging when the number of times ReportIntoLog was present in the projects went over 100. So, I was wondering, is there any way to make compiler insert a unique ID for me? I don't care what is the value of that ID as long as it's unique and doesn't change from build to build. My idea was to use __LINE__, but when I change the code that value may change as well (in regards to previous builds/versions of the service).

[Arjay]

What is the purpose of the UniqueID? In your example above, does the uniqueId correlate to the out of memory failure for the array?

[ahmd]

What is the purpose of the UniqueID? In your example above, does the uniqueId correlate to the out of memory failure for the array?

No, don't take my example above literally. The unique ID is simply the means for me to find the location in the source code. For instance, a client sends me their log and I see errors #126 and 156 in it. That way I can locate what actually happened in the source code.

[Paul McKenzie]

So, I was wondering, is there any way to make compiler insert a unique ID for me?

Have you considered calling the API functions that generate GUID's? That is what is usually done if a unique ID for any purpose needs to be generated.

A GUID is virtually guaranteed to be unique (virtually meaning that the chance of generating duplicate GUID's is astronomically small).

Regards,

Paul McKenzie

[ahmd]

Have you considered calling the API functions that generate GUID's?

It's a good idea about GUIDs. The API wouldn't work though, because those IDs have to be hard coded in the source code. I'm picturing it as a separate app that will generate a GUID after a button click and place it onto the clipboard.

That actually gave me an idea. I can use something smaller for an ID (the problem with GUID is that it's too unwieldy to operate with). The question is, what is easier: Use a piece of paper to write down those IDs in sequential order as I add them, or write a small APP that will keep track of them and dispense them one at a time

Still, I believe there's nothing in the precompiler that can do this for me, is there?

[Krishnaa]

Do whatever way man, try sequencing classes, then may be try doing 1.1, 1.2 for the functions.

[superbonzo]

Still, I believe there's nothing in the precompiler that can do this for me, is there?

as an alternative, you can pass the CRC (or some other hash function) of __FUNCDNAME__, eventually decorated with a function-local id to disambiguate ReportIntoLog calls occurring in the same function ( of course, the acceptability of this solution depends on your criteria to match ReportIntoLog calls to their respective ids ... which is not entirely clear from your problem description )

[Skizmo]

__FILE__ and __LINE__ ?

[itsmeandnobodyelse]

I used to have a string location in my error locs, e. g.

ReportIntoLog("MyClass::myFunction begin", ...);

That is easy to find in the sources and often you don't need to switch to that source when doing so cause the 'location' together withe the error code/error tetx already tells you what happened.

Unfortunately I don't see a way to let the precompiler do the job, but the function name should be fastly reachable.

Regards, Alex

[ahmd]

__FILE__ and __LINE__ ?

...My idea was to use __LINE__, but when I change the code that value may change as well (in regards to previous builds/versions of the service).

Thank you all. I wasn't able to find a helper program that I needed, so I made one. I'll share it with you since I started this thread. It would be nice if someone with knowledge of how to integrate it into the IDE did it, but until that you can use a hot key for it to generate a sequentual ID and place it on to a clipboard. So basically, to insert a new ID you hit Ctrl+Shft+I and then Ctrl+V.

[Arjay]

ahmd, this program doesn't work when I try to start it from a service or from an account with limited permissions. Any ideas?

[ahmd]

IDK, works for me. Here's how I use it. Say, I'm adding my logging functions into C++ project. When I type

ReportIntoLog(

I need the next sequential ID for the logging function. Before I would write them down on a piece of paper as I go, but now instead of doing it, I can hit Ctrl+Shft+I (or whatever hot key you set up there) and then Ctrl+V to paste the ID into my C++ project. (Obviously that program has to be running at the same time.) I don't have to worry about messing up those IDs anymore if I place it into the project I work on, so that it will be backed up, copied, upgraded, etc. with it.

I don't know why you'd want to run it from a service though? It obviously won't run since it requires user interaction. As for the limited account, I guess if you completely limit it. In a nutshell, what it does, it reads its settings from a file that it creates in the same folder where you run it from, then sets up a hot key and waits for that hot key. If it comes, it copies the current ID into Clipboard, increments it by one, makes a sound and writes the result into its storage file.

Again, I'm not asking you to debug it or do anything, it works as-is for me. I'm simply sharing it in case someone else might need to the same function. You can also change the code if you feel like doing so.

PS. Even though it was written with an earlier version of VS, I'm using it on Win7, with VS 2008 on a Standard (non admin) User account.

[Igor Vartanov]

else
{
    ReportIntoLog(1);
}

I would warn you against reporting this way.

Say you have your unique id in log. This tells you that there was something wrong with your particular code line. But what was wrong? What was the value(s) of critical variable(s) (not in your simplistic sample )? What was the last error code from Windows? Besides, it's not always critical errors you're gonna have all the time. You might want to trace warnings and informational comments as well.

And it makes you always have your source code in front of you to trace what happens step by step. Irregular numbers (imagine you decide to add another code a couple of months later) soon become a nightmare to trace.

Another issue to think about. You might want have your logs of moderate size (as all we know, when trying to catch a very tricky glitch, logs typically tend to grow fast, eat free disk space and eventually make the application/system/database suffocate ). This should give you an idea of having log levels and log subsystems. "Level" controls the level of details. "Subsystem" controls logging in particular component to be enabled/disabled.

And the last, to the original topic. As a sort of id we (me and my teammates) use __FUNCTION__ macro. As well, we always use human readable text in every log record along with printing pairs (critical variable = value) inside the text. Besides if applicable, the text contains hints to operation personnel about possible issue reasons and misfits in settings. The final log appears relatively easy to read on client side and at the same time having enough information to analyze.

[Arjay]

I don't know why you'd want to run it from a service though? It obviously won't run since it requires user interaction.

My comments were in reference to posting code in an effort to help, and then having someone comment that the code doesn't work for them or isn't exactly what they need. I'm sure you can make the connection.

[ahmd]

I would warn you against reporting this way.

Igor, first of all, you contradict yourself. You say that I should keep my logging to a bare minimum because of the log size concerns and then tell me to include "human readable text in every log record along with printing pairs (critical variable = value) inside the text".

Thank you for your comments though. As I said above, the example I gave is a minimalistic version of what is actually use. And, I agree with what you said, except that I always add a unique ID to every post in the log to prevent confusion when dealing with silimlar entries. It is also much easier to find the code lines in the source code by their ID rather then by a discriptive text. The exact log text entry might also get distorted when passed from one person to another. One more reason is that it's always easy to refer to a particular bug by its ID number among the members of our development team.

I did use __LINE__ and __FUNCTION__ in my logging before, but sometimes it gives out too much information about the code. I prefer to call my methods and functions with full descriptive names. (And, obviously, I don't mean our team. I'm talking about a situation when we ask a user of the product to do the testing on their side. So in that case having a unique ID in the log with the bare minimum technical information quite suffices.)


And, Arjay, I'm still not sure what you're talking about...