RE: namespace tlm

OK, that is fine with me. When someone asks why we didn’t introduce separate
tlm1 and tlm2 namespaces in this round we can point to Philipp’s nice email below..

Thanks
Stuart

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Tuesday, November 02, 2010 7:57 AM
To: Philipp A Hartmann
Cc: john.aynsley@doulos.com; Stuart Swan; P1666 Technical WG
Subject: Re: namespace tlm

Stuart, Philipp,

Right. So I propose leaving things as they are, i.e. not introducing two new namespaces but keeping with namespace tlm.

John A

-----"Philipp A. Hartmann" <philipp.hartmann@offis.de> wrote: -----
To: Stuart Swan <stuart@cadence.com>
From: "Philipp A. Hartmann" <philipp.hartmann@offis.de>
Date: 11/01/2010 04:16PM
Cc: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
Subject: Re: namespace tlm

Stuart, John, All,



On 01/11/10 23:40, Stuart Swan wrote:

> I don’t have strong opinion on this.



I don't have a strong opinion either. I just want to throw a potential

(though probably minor) issue in the ring: Koenig's famous

argument-dependent lookup might break.



Consider the following example in the "new" situation:



// The new library would look like this:

// Classes defined in either tlm1 or tlm2

namespace tlm2

{

  struct tlm_generic_payload {};

}



// and brought into tlm for backwards compatibility

namespace tlm

{

   using namespace tlm2;

}



// users may have added their own functions to the "old" namespace,

// that rely on argument depending lookup:

namespace tlm

{

  // print a generic payload

  std::ostream&

  operator<<( std::ostream os, tlm_generic_payload const & )

    { return os << __PRETTY_FUNCTION__ << std::endl; }

}



// now, the following breaks:

int main()

{

  tlm::tlm_generic_payload gp;

  std::cout << gp;

  // error: no match for ‘operator<<’

}



Otherwise, I also think that this would probably be a good separation,

especially since we defined terms like TLM-2 compliance.



My 0.02€,

Philipp





> I think the motivation for having the

> tlm1 and tlm2 namespaces was for people who wanted to clearly indicate in their

> models that they were using one or the other, but not both. If OSCI were designing

> tlm1 and tlm2 from scratch, we’d probably have done something like this to avoid the confusion.

> But you may be right that it is too late now .. Aside from a bit more clutter in the LRM, what practical

> drawbacks do you see for users – they can continue to just use tlm:: if they want and be oblivious

> to the other names, right ?

>

> -Stuart

>

> From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com

> Sent: Monday, November 01, 2010 3:34 PM

> To: systemc-p1666-technical@eda.org

> Subject: namespace tlm

>

> All,

>

> A while back we discussed introducing two new namespaces, tlm1 and tlm2, but observed that in order to keep backward compatibility we would have to retain the namespace tlm incorporating names from both namespaces.

>

> Given the existence of substantial amounts of legacy code for both TLM-1 and TLM-2.0, all of which uses namespace tlm, I am wondering about the wisdom of introducing two new namespaces at this point. Does it really buy us anything? Will users really want to bothered with distinguishing between tlm1:: and tlm2:: ?

>

> What does everyone think?

>

> Thanks,

>

> John A

>

>

>

> --

> This message has been scanned for viruses and

> dangerous content by MailScanner<http://www.mailscanner.info/>, and is

> believed to be clean.

>





--

Philipp A. Hartmann

Hardware/Software Design Methodology Group



OFFIS Institute for Information Technology

R&D Division Transportation · FuE-Bereich Verkehr

Escherweg 2 · 26121 Oldenburg · Germany

Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.