<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><pre style="line-height: 21px; white-space: normal; font-size: 15px; background-color: rgb(255, 255, 255); ">>1. I can declare the instance as a global variable. I don`t like to do that.<br>This is actually quite popular in many of our software projects, as it's clean and simple. It should be simple for logging. Logging should be as simple as cout (C++) or System.out.println (Java), no need to instantiate anything or at most instantiate the logger (<span style="font-family: Calibri, sans-serif; ">osoutput</span><span style="font-family: Calibri, sans-serif; ">) once.</span></pre><pre style="line-height: 21px; white-space: normal; font-size: 15px; background-color: rgb(255, 255, 255); "><span style="font-family: Calibri, sans-serif; ">In as sense,</span><span style="font-family: Calibri, sans-serif; "> t</span>he basic print statement like cout or in java System.out.println *is* a global singleton. No need to worry about thread safety as its just outputting.</pre><pre style="line-height: 21px; white-space: normal; font-size: 15px; background-color: rgb(255, 255, 255); "><br>>2. I can set up a namespace, so that the variable is visible from <br>everywhere within the namespace. This is what Andreas does in Ipopt, <br>but I read that it is frowned upon, essentially for the same reason <br>that global variables are deprecated.<br><br>This is actually the default behavior of log4j in java. Basically in the beginning of each class you instantiate a logger. And log4j will make sure that there will be one and only only logger instance for each class. That is no matter how many instances of a particular class, there one be one logger (osoutput) instance. </pre><pre style="line-height: 21px; white-space: normal; font-size: 15px; background-color: rgb(255, 255, 255); ">The reason: no need for more than one each class. In fact you can (as in 1 above) just have 1 global logger.</pre><pre style="line-height: 21px; white-space: normal; font-size: 15px; background-color: rgb(255, 255, 255); ">The pro: you naturally log4j can use the package (or namespace) as a category and you can configure output behavior or each category; no extra effort. </pre><pre style="line-height: 21px; white-space: normal; font-size: 15px; background-color: rgb(255, 255, 255); ">The con: you always will have one logger instantiate line in the beginning of each class.<br><br>>3. I can pass the instance as an extra argument to all methods that <br>use output (which is basically every routine we have ever written). As <br>far as I can see, this is clean, but it is cumbersome, and it blows <br>the API sky-high.</pre><div>This is cumbersome for sure, but might worth it. </div><div>The reason is because there is a fundamental difference between our osoutput and general logger use. </div><div>General logger will almost always have a static (i.e. pre-compile) property file which sets the behavior of logging or outputting. Users don't change the logging/outputting behavior at run time. In fact logging methods are usually private or in the code, rather than exposed as a public api methods for user to invoke. </div><div><br></div><div>In our case, user can during run time feed the logging behavior input like logging level etc., so 3 actually in my opinion fits our intended design the best. </div><div><br></div>Again, we can talk tomorrow.<div><br></div><div>Jun</div><div><br><div><div id="SkyDrivePlaceholder"></div>> Date: Mon, 26 Nov 2012 11:26:16 -0400<br>> From: Horand.Gassmann@dal.ca<br>> To: os-project-managers@list.coin-or.org<br>> Subject: Re: [Os-project-managers] ticket 14 - question about programming style<br>> <br>> Horand Gassmann <Horand.Gassmann@DAL.CA> wrote:<br>> <br>> > Kipp Martin <kmartin@chicagobooth.edu> wrote:<br>> ><br>> >> Hi Gus:<br>> >><br>> >> I don't see a good solution right now. I think the problem with <br>> >> solution 1 is that it makes the code no longer thread safe (I don't <br>> >> really understand thread safe, but I do know it important). I <br>> >> don't much about the namespace idea. I did not know this was <br>> >> frowned on.<br>> ><br>> > It's the same issue about thread-safety. <parrot> To implement <br>> > singletons in a thread-safe way, you need double-checking locks, and <br>> > from what I can tell, those are platform-dependent. </parrot><br>> <br>> This paper talks about the issues quite clearly:<br>> <br>> http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf<br>> <br>> _______________________________________________<br>> Os-project-managers mailing list<br>> Os-project-managers@list.coin-or.org<br>> http://list.coin-or.org/mailman/listinfo/os-project-managers<br></div></div> </div></body>
</html>