RE: namespace tlm

Okay, assuming that is settled, here are a couple of somewhat related issues.

The OSCI TLM-2.0 LRM includes several sections (10.2, 11.8, 11.8.1) that refer explicitly to the directory structure of the OSCI TLM-2.0 kit. We will want to omit most of these dependencies from the IEEE standard, right?

However, the OSCI LRM requires applications to #include the header files of any utilities from the tlm_utils directory, which raises the following questions:
- Does the directory tlm_utils need to be documented in the LRM?
- Do the names of the utility source files need to be documented?
- If not, how can applications that use TLM-2.0 utilities be made portable across implementations?

In the TLM-2.0.1 kit, the header file is named "tlm.h".  This name does not follow the convention used in SystemC, where
"systemc.h" is the old-style header that dumps all names into the global namespace
"systemc" is the new-style header where all names are in sc_core or sc_dt

Since the TLM-2.0 header is a new-style header, by rights it should have been named "tlm", be we need to retain the name "tlm.h" for backward compatibility. Any suggestions?

Thanks,

John A

-----Stuart Swan <stuart@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Philipp A Hartmann <philipp.hartmann@offis.de>
From: Stuart Swan <stuart@cadence.com>
Date: 11/02/2010 01:40PM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: 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.