Re: namespace tlm

From: <john.aynsley@doulos.com>
Date: Tue Nov 02 2010 - 07:57:06 PDT

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.
Received on Tue Nov 2 07:58:08 2010

This archive was generated by hypermail 2.1.8 : Tue Nov 02 2010 - 07:58:12 PDT