The following code compiles fine with GCC, Comeau, EDG/C++ and VC++ 8/9:


#include <cstdio>
#include <string>


int main() {
  {
    std::string names[3] = { "One", "Two", "Three" };
  }
  std::puts("\n\npress <ENTER> to exit...");
  std::getchar();
  return 0;
}


I think its still invalid; am I right?


-- 
Chris M. Thomasson
http://appcore.home.comcast.net

Chris Thomasson wrote:
> The following code compiles fine with GCC, Comeau, EDG/C++ and VC++ 8/9:
> 
> 
> #include <cstdio>
> #include <string>
> 
> 
> int main() {
>  {
>    std::string names[3] = { "One", "Two", "Three" };
>  }
>  std::puts("\n\npress <ENTER> to exit...");
>  std::getchar();
>  return 0;
> }
> 
> 
> I think its still invalid; am I right?

I believe you're right that you think it's still invalid (although there 
is nobody but you that can confirm that so far, there is no way for us 
to know what you think except when you tell us).  However, I don't 
immediately see anything invalid in the code, could you perhaps elaborate?

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov wrote:
> Chris Thomasson wrote:
>> The following code compiles fine with GCC, Comeau, EDG/C++ and VC++ 8/9:
>>
>>
>> #include <cstdio>
>> #include <string>
>>
>>
>> int main() {
>>  {
>>    std::string names[3] = { "One", "Two", "Three" };
>>  }
>>  std::puts("\n\npress <ENTER> to exit...");
>>  std::getchar();
>>  return 0;
>> }
>>
>>
>> I think its still invalid; am I right?
> 
> I believe you're right that you think it's still invalid (although there
> is nobody but you that can confirm that so far, there is no way for us
> to know what you think except when you tell us).  However, I don't
> immediately see anything invalid in the code, could you perhaps elaborate?

  There are lots of things wrong in that code. For starters, it doesn't
check that printing to standard output succeeded.

  (Yes, that was supposed to be humoristic.)

"Juha Nieminen" <nospam@thanks.invalid> wrote in message 
news:yWg1k.315$oS4.276@read4.inet.fi...
> Victor Bazarov wrote:
>> Chris Thomasson wrote:
>>> The following code compiles fine with GCC, Comeau, EDG/C++ and VC++ 8/9:
>>>
>>>
>>> #include <cstdio>
>>> #include <string>
>>>
>>>
>>> int main() {
>>>  {
>>>    std::string names[3] = { "One", "Two", "Three" };
>>>  }
>>>  std::puts("\n\npress <ENTER> to exit...");
>>>  std::getchar();
>>>  return 0;
>>> }
>>>
>>>
>>> I think its still invalid; am I right?
>>
>> I believe you're right that you think it's still invalid (although there
>> is nobody but you that can confirm that so far, there is no way for us
>> to know what you think except when you tell us).  However, I don't
>> immediately see anything invalid in the code, could you perhaps 
>> elaborate?
>
>  There are lots of things wrong in that code. For starters, it doesn't
> check that printing to standard output succeeded.
>
>  (Yes, that was supposed to be humoristic.)

lol!

:^D


Okay... Here is what I want to be able to do; the following should compile 
and run fine:
_______________________________________________________________________
/* Active Object
______________________________________________________________*/
template<
 typename T,
 void (T::*T_fp_start) () = &T::start,
 void (T::*T_fp_join) () = &T::join
> struct active {

  T object;

  struct guard {
    T& object;

    guard(T& _object) : object(_object) {
      (object.*T_fp_start)();
    }

    ~guard() {
      (object.*T_fp_join)();
    }
  };

  active() {
    (object.*T_fp_start)();
  }

  template<typename T_p1>
  active(T_p1& p1) : object(p1) {
    (object.*T_fp_start)();
  }

  template<typename T_p1>
  active(T_p1 const& p1) : object(p1) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2>
  active(T_p1& p1, T_p2& p2) : object(p1, p2) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2>
  active(T_p1 const& p1, T_p2& p2) : object(p1, p2) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2>
  active(T_p1& p1, T_p2 const& p2) : object(p1, p2) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2>
  active(T_p1 const& p1, T_p2 const& p2) : object(p1, p2) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2, typename T_p3>
  active(T_p1 const& p1, T_p2& p2, T_p3& p3)
    : object(p1, p2, p3) {
    (object.*T_fp_start)();
  }

  // [and on and on for more and more parameters...]

  ~active() {
    (object.*T_fp_join)();
  }
};




/* Sample usage
______________________________________________________________*/
#include <cstdio>
#include <cstddef>
#include <string>

struct Buffer {
  Buffer() {
    std::printf("(%p)->Buffer::Buffer()\n", (void*)this);
  }

  ~Buffer() {
    std::printf("(%p)->Buffer::~Buffer()\n", (void*)this);
  }
};


struct Producer {
  int const m_id;
  std::string const m_name;
  Buffer& m_Buffer;

  Producer(int const id, Buffer& _Buffer)
   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
    std::printf("(%p)->Producer::Producer()\n", (void*)this);
  }

  Producer(int const id, char const* name, Buffer& _Buffer)
   : m_id(id), m_name(name), m_Buffer(_Buffer) {
    std::printf("(%p)->Producer::Producer()\n", (void*)this);
  }

  ~Producer() {
    std::printf("(%p)->Producer::~Producer()\n", (void*)this);
  }

  void start() {
    std::printf("(%p)-> void Producer<'%s'>::start() - Buffer(%p)\n",
      (void*)this, m_name.c_str(), (void*)&m_Buffer);
  }

  void join() {
    std::printf("(%p)-> void Producer::join() - Buffer(%p)\n",
      (void*)this, (void*)&m_Buffer);
  }
};


struct Consumer {
  int const m_id;
  std::string const m_name;
  Buffer& m_Buffer;

  Consumer(int const id, Buffer& _Buffer)
   : m_id(id), m_name("Default Consumer"), m_Buffer(_Buffer) {
    std::printf("(%p)->Consumer::Consumer()\n", (void*)this);
  }

  Consumer(int const id, char const* name, Buffer& _Buffer)
   : m_id(id), m_name(name), m_Buffer(_Buffer) {
    std::printf("(%p)->Consumer::Consumer()\n", (void*)this);
  }

  ~Consumer() {
    std::printf("(%p)->Consumer::~Consumer()\n", (void*)this);
  }

  void start() {
    std::printf("(%p)-> void Consumer<'%s'>::start() - Buffer(%p)\n",
      (void*)this, m_name.c_str(), (void*)&m_Buffer);
  }

  void join() {
    std::printf("(%p)-> void Consumer::join() - Buffer(%p)\n",
      (void*)this, (void*)&m_Buffer);
  }
};


#define ARRAY_DEPTH(mp_this) ( \
  sizeof((mp_this)) / sizeof((mp_this)[0]) \
)


int main() {
  {
    Buffer b;

    active<Producer> p[] = {
      active<Producer>(123, b),
      active<Producer>(456, "Custom Producer", b),
      active<Producer>(789, b),
      active<Producer>(234, "I am a Producer!", b),
      active<Producer>(567, b)
    };

    active<Consumer> c[] = {
      active<Consumer>(891, "I am a Consumer!", b),
      active<Consumer>(345, b),
      active<Consumer>(678, b)
    };

    std::size_t i;

    std::puts("-----------------------");

    for (i = 0; i < ARRAY_DEPTH(p); ++i) {
      std::printf("p[%u].m_id == %d\n", i, p[i].object.m_id);
      std::printf("p[%u].m_name == %s\n----\n",
        i, p[i].object.m_name.c_str());
    }

    putchar('\n');

    for (i = 0; i < ARRAY_DEPTH(c); ++i) {
      std::printf("c[%u].m_id == %d\n", i, c[i].object.m_id);
      std::printf("c[%u].m_name == %s\n----\n",
        i, c[i].object.m_name.c_str());
    }

    std::puts("-----------------------");
  }
  std::puts("\n\npress <ENTER> to exit...");
  std::getchar();
  return 0;
}

_______________________________________________________________________



This code compiles perfectly fine with no warnings on GCC, Comeau, VC++ 8/9 
and EDG/C++.


Can any of you spot any undefined behavior? Also, is the code anywhere near 
standard C++? Please try and bear with be here. I am NOT a C++ expert...

:^(


Thanks for all of your time! I really do appreciate it. 

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message 
news:g2402s$9mn$1@news.datemas.de...
> Chris Thomasson wrote:
>> The following code compiles fine with GCC, Comeau, EDG/C++ and VC++ 8/9:
>>
>>
>> #include <cstdio>
>> #include <string>
>>
>>
>> int main() {
>>  {
>>    std::string names[3] = { "One", "Two", "Three" };
>>  }
>>  std::puts("\n\npress <ENTER> to exit...");
>>  std::getchar();
>>  return 0;
>> }
>>
>>
>> I think its still invalid; am I right?
>
> I believe you're right that you think it's still invalid (although there 
> is nobody but you that can confirm that so far, there is no way for us to 
> know what you think except when you tell us).  However, I don't 
> immediately see anything invalid in the code, could you perhaps elaborate?

I was thinking that the compiler would complain about something like:

"this form of non-aggregate initialization requires a unary constructor"

For some reason I thought I would have to do something like:


#include <cstdio>
#include <string>


int main() {
  {
    std::string names[3] = {
      std::string("One"),
      std::string("Two"),
      std::string("Three")
    };
  }
  std::puts("\n\npress <ENTER> to exit...");
  std::getchar();
  return 0;
}


This just goes to show you how little I actually know about C++! I am a C 
guy. Ouch!


Anyway, here is my next question:

http://groups.google.com/group/comp.lang.c++/msg/ad4f85b6d588eaf7


Does the code in that post look Kosher? 

"Chris Thomasson" <cristom@comcast.net> wrote in message 
news:34CdnS4u3Kw1ANjVnZ2dnUVZ_h_inZ2d@comcast.com...
[...]
> Okay... Here is what I want to be able to do; the following should compile 
> and run fine:
> _______________________________________________________________________
> /* Active Object
> ______________________________________________________________*/
> template<
> typename T,
> void (T::*T_fp_start) () = &T::start,
> void (T::*T_fp_join) () = &T::join
>> struct active {
[...]


I think that there might be some problems with ambiguity in the active<T> 
template constructors for certain usages. Need to think some more on this 
aspect... Humm...


> };
>
[...] 

Chris Thomasson wrote:
> [..]
> Okay... Here is what I want to be able to do; the following should 
> compile and run fine:
> _______________________________________________________________________
> /* Active Object
> ______________________________________________________________*/
> template<
> typename T,
> void (T::*T_fp_start) () = &T::start,
> void (T::*T_fp_join) () = &T::join > struct active {
> 
>  T object;
> 
>  struct guard {
>    T& object;
> 
>    guard(T& _object) : object(_object) {
>      (object.*T_fp_start)();
>    }
> 
>    ~guard() {
>      (object.*T_fp_join)();
>    }
>  };

I don't understand the importance of this 'guard' struct here.

> 
>  active() {
>    (object.*T_fp_start)();
>  }

This is rather dangerous.  If 'object' is a POD, it is left 
uninitialised.  If you wanted it default-initilaised, you need to put it 
in the initialiser list:

     active() : object() {
         ...
     }

otherwise you're trying to call a member function that might want to 
access the object's data, which are not in the proper state...

> 
> [..]
> };
> 
> 
> 
> 
> /* Sample usage
> ______________________________________________________________*/
> #include <cstdio>
> #include <cstddef>
> #include <string>
> 
> struct Buffer {
>  Buffer() {
>    std::printf("(%p)->Buffer::Buffer()\n", (void*)this);
>  }
> 
>  ~Buffer() {
>    std::printf("(%p)->Buffer::~Buffer()\n", (void*)this);
>  }
> };
> 
> 
> struct Producer {
>  int const m_id;
>  std::string const m_name;
>  Buffer& m_Buffer;
> 
>  Producer(int const id, Buffer& _Buffer)

The name "_Buffer" is reserved by the implementation for any uses, so 
you cannot use it here.  I recommend using lower case ('_buffer') or 
renaming the argument altogether.  All names that begin with an 
underscore and a capital letter are reserved.

Same sentiment applies for all occurrences of "_Buffer" below.

>   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
>    std::printf("(%p)->Producer::Producer()\n", (void*)this);

I don't believe you need to cast 'this' here.

>  }
> 
>  Producer(int const id, char const* name, Buffer& _Buffer)
>   : m_id(id), m_name(name), m_Buffer(_Buffer) {
>    std::printf("(%p)->Producer::Producer()\n", (void*)this);
>  }
> 
>  ~Producer() {
>    std::printf("(%p)->Producer::~Producer()\n", (void*)this);
>  }
> 
>  void start() {
>    std::printf("(%p)-> void Producer<'%s'>::start() - Buffer(%p)\n",
>      (void*)this, m_name.c_str(), (void*)&m_Buffer);
>  }
> 
>  void join() {
>    std::printf("(%p)-> void Producer::join() - Buffer(%p)\n",
>      (void*)this, (void*)&m_Buffer);
>  }
> };
> 
> 
> struct Consumer {
>  int const m_id;
>  std::string const m_name;
>  Buffer& m_Buffer;
> 
>  Consumer(int const id, Buffer& _Buffer)
>   : m_id(id), m_name("Default Consumer"), m_Buffer(_Buffer) {
>    std::printf("(%p)->Consumer::Consumer()\n", (void*)this);
>  }
> 
>  Consumer(int const id, char const* name, Buffer& _Buffer)
>   : m_id(id), m_name(name), m_Buffer(_Buffer) {
>    std::printf("(%p)->Consumer::Consumer()\n", (void*)this);
>  }
> 
>  ~Consumer() {
>    std::printf("(%p)->Consumer::~Consumer()\n", (void*)this);
>  }
> 
>  void start() {
>    std::printf("(%p)-> void Consumer<'%s'>::start() - Buffer(%p)\n",
>      (void*)this, m_name.c_str(), (void*)&m_Buffer);
>  }
> 
>  void join() {
>    std::printf("(%p)-> void Consumer::join() - Buffer(%p)\n",
>      (void*)this, (void*)&m_Buffer);
>  }
> };
> 
> 
> #define ARRAY_DEPTH(mp_this) ( \
>  sizeof((mp_this)) / sizeof((mp_this)[0]) \
> )

You're better off not using a macro for this.  Try

     template<class T, size_t depth>
     size_t array_depth(T (&mp_this)[depth]) {
        return depth;
     }

(the case has changed, this is not a macro any more).

> 
> 
> int main() {
>  {
>    Buffer b;
> 
>    active<Producer> p[] = {
>      active<Producer>(123, b),
>      active<Producer>(456, "Custom Producer", b),
>      active<Producer>(789, b),
>      active<Producer>(234, "I am a Producer!", b),
>      active<Producer>(567, b)
>    };
> 
>    active<Consumer> c[] = {
>      active<Consumer>(891, "I am a Consumer!", b),
>      active<Consumer>(345, b),
>      active<Consumer>(678, b)
>    };
> 
>    std::size_t i;
> 
>    std::puts("-----------------------");
> 
>    for (i = 0; i < ARRAY_DEPTH(p); ++i) {
>      std::printf("p[%u].m_id == %d\n", i, p[i].object.m_id);
>      std::printf("p[%u].m_name == %s\n----\n",
>        i, p[i].object.m_name.c_str());
>    }
> 
>    putchar('\n');
> 
>    for (i = 0; i < ARRAY_DEPTH(c); ++i) {
>      std::printf("c[%u].m_id == %d\n", i, c[i].object.m_id);
>      std::printf("c[%u].m_name == %s\n----\n",
>        i, c[i].object.m_name.c_str());
>    }
> 
>    std::puts("-----------------------");
>  }
>  std::puts("\n\npress <ENTER> to exit...");
>  std::getchar();
>  return 0;
> }
> 
> _______________________________________________________________________
> 
> 
> 
> This code compiles perfectly fine with no warnings on GCC, Comeau, VC++ 
> 8/9 and EDG/C++.

So, they are a bit forgiving when it comes to reserved names (and you 
got lucky), and you didn't use the default c-tor for your 'active' 
template instantiated on a POD...

> Can any of you spot any undefined behavior? Also, is the code anywhere 
> near standard C++? Please try and bear with be here. I am NOT a C++ 
> expert...

Well, the code's close.

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"Chris Thomasson" <cristom@comcast.net> wrote in message 
news:kOudnR5GhJgGPdjVnZ2dnUVZ_o_inZ2d@comcast.com...
> "Chris Thomasson" <cristom@comcast.net> wrote in message 
> news:34CdnS4u3Kw1ANjVnZ2dnUVZ_h_inZ2d@comcast.com...
> [...]
>> Okay... Here is what I want to be able to do; the following should 
>> compile and run fine:
>> _______________________________________________________________________
>> /* Active Object
>> ______________________________________________________________*/
>> template<
>> typename T,
>> void (T::*T_fp_start) () = &T::start,
>> void (T::*T_fp_join) () = &T::join
>>> struct active {
> [...]
>
>
> I think that there might be some problems with ambiguity in the active<T> 
> template constructors for certain usages. Need to think some more on this 
> aspect... Humm...

Well, AFAICT the ambiguity problem only exists because I explicitly defined 
the template constructor types as references! Here is a fixed version which 
uses no decorations on the template parameter types passed into the 
constructor:


template<
 typename T,
 void (T::*T_fp_start) () = &T::start,
 void (T::*T_fp_join) () = &T::join
> struct active {

  T object;

  struct guard {
    T& object;

    guard(T& _object) : object(_object) {
      (object.*T_fp_start)();
    }

    ~guard() {
      (object.*T_fp_join)();
    }
  };

  active() {
    (object.*T_fp_start)();
  }

  template<typename T_p1>
  active(T_p1 p1) : object(p1) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2>
  active(T_p1 p1, T_p2 p2) : object(p1, p2) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2, typename T_p3>
  active(T_p1 p1, T_p2 p2, T_p3 p3)
    : object(p1, p2, p3) {
    (object.*T_fp_start)();
  }

  template<typename T_p1, typename T_p2, typename T_p3, typename T_p4>
  active(T_p1 p1, T_p2 p2, T_p3 p3, T_p4 p4)
    : object(p1, p2, p3, p4) {
    (object.*T_fp_start)();
  }

  // [and on and on for more and more parameters...]

  ~active() {
    (object.*T_fp_join)();
  }
};

"Chris Thomasson" <cristom@comcast.net> wrote in message 
news:DdWdnR35AOULPtjVnZ2dnUVZ_tninZ2d@comcast.com...
> "Chris Thomasson" <cristom@comcast.net> wrote in message 
> news:kOudnR5GhJgGPdjVnZ2dnUVZ_o_inZ2d@comcast.com...
>> "Chris Thomasson" <cristom@comcast.net> wrote in message 
>> news:34CdnS4u3Kw1ANjVnZ2dnUVZ_h_inZ2d@comcast.com...
>> [...]
>>> Okay... Here is what I want to be able to do; the following should 
>>> compile and run fine:
>>> _______________________________________________________________________
>>> /* Active Object
>>> ______________________________________________________________*/
>>> template<
>>> typename T,
>>> void (T::*T_fp_start) () = &T::start,
>>> void (T::*T_fp_join) () = &T::join
>>>> struct active {
>> [...]
>>
>>
>> I think that there might be some problems with ambiguity in the active<T> 
>> template constructors for certain usages. Need to think some more on this 
>> aspect... Humm...
>
> Well, AFAICT the ambiguity problem only exists because I explicitly 
> defined the template constructor types as references! Here is a fixed 
> version which uses no decorations on the template parameter types passed 
> into the constructor:
>
>
> template<
> typename T,
> void (T::*T_fp_start) () = &T::start,
> void (T::*T_fp_join) () = &T::join
>> struct active {
>
>  T object;
[...]


>  active() {
>    (object.*T_fp_start)();
>  }

Need to fix the error:



   active() : object() {
     (object.*T_fp_start)();
   }


[...]

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message 
news:g24801$pek$1@news.datemas.de...
> Chris Thomasson wrote:
>> [..]
>> Okay... Here is what I want to be able to do; the following should 
>> compile and run fine:
>> _______________________________________________________________________
>> /* Active Object
>> ______________________________________________________________*/
>> template<
>> typename T,
>> void (T::*T_fp_start) () = &T::start,
>> void (T::*T_fp_join) () = &T::join > struct active {
>>
>>  T object;
>>
>>  struct guard {
>>    T& object;
>>
>>    guard(T& _object) : object(_object) {
>>      (object.*T_fp_start)();
>>    }
>>
>>    ~guard() {
>>      (object.*T_fp_join)();
>>    }
>>  };
>
> I don't understand the importance of this 'guard' struct here.


Well, its there so the user can so something like:


{
  object o;
  active<object>::guard g(o);
}


So they can intervene in between the object construction and the invocation 
of its start procedure.



>
>>
>>  active() {
>>    (object.*T_fp_start)();
>>  }
>
> This is rather dangerous.  If 'object' is a POD, it is left uninitialised. 
> If you wanted it default-initilaised, you need to put it in the 
> initialiser list:
>
>     active() : object() {
>         ...
>     }
>
> otherwise you're trying to call a member function that might want to 
> access the object's data, which are not in the proper state...

OUCH!!   :^O




[...]

>>  Producer(int const id, Buffer& _Buffer)
>
> The name "_Buffer" is reserved by the implementation for any uses, so you 
> cannot use it here.  I recommend using lower case ('_buffer') or renaming 
> the argument altogether.  All names that begin with an underscore and a 
> capital letter are reserved.
>
> Same sentiment applies for all occurrences of "_Buffer" below.

DOH! Thanks again. What a bone headed mistake.  :^(...




>>   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
>>    std::printf("(%p)->Producer::Producer()\n", (void*)this);
>
> I don't believe you need to cast 'this' here.

Well, I thought that you could only pass a void* pointer to represent a %p 
formatter.




[...]
>>
>>
>> #define ARRAY_DEPTH(mp_this) ( \
>>  sizeof((mp_this)) / sizeof((mp_this)[0]) \
>> )
>
> You're better off not using a macro for this.  Try
>
>     template<class T, size_t depth>
>     size_t array_depth(T (&mp_this)[depth]) {
>        return depth;
>     }
>
> (the case has changed, this is not a macro any more).

Indeed. The macro is ugly compared to the template.




[...]

>> This code compiles perfectly fine with no warnings on GCC, Comeau, VC++ 
>> 8/9 and EDG/C++.
>
> So, they are a bit forgiving when it comes to reserved names (and you got 
> lucky), and you didn't use the default c-tor for your 'active' template 
> instantiated on a POD...

Very lucky!  ;^D




>> Can any of you spot any undefined behavior? Also, is the code anywhere 
>> near standard C++? Please try and bear with be here. I am NOT a C++ 
>> expert...
>
> Well, the code's close.

With all of your excellent help, I think I am going to get this right after 
all! I will repost the code in full once I kill all the bugs you so kindly 
pointed out:


- Default construct the `active<T>::object' in the `active<T>::active' ctor.


- Honor the reserved namespace rules by eliminating leading underscore and 
capital from all the names.


- Remove the macros in favor of templates.


Also, I think I need to remove the explicit reference decorations to the 
templated active<T> constructors. In other words I need to change:

  template<typename T_p1>
  active(T_p1& p1) : object(p1) {
    (object.*T_fp_start)();
  }


to:


  template<typename T_p1>
  active(T_p1 p1) : object(p1) {
    (object.*T_fp_start)();
  }


This should elude some ambiguity problems I can foresee with the former 
definition... 

Chris Thomasson wrote:
> [..]  I think I need to remove the explicit reference decorations to the
> templated active<T> constructors. In other words I need to change:
> 
>  template<typename T_p1>
>  active(T_p1& p1) : object(p1) {
>    (object.*T_fp_start)();
>  }
> 
> 
> to:
> 
> 
>  template<typename T_p1>
>  active(T_p1 p1) : object(p1) {
>    (object.*T_fp_start)();
>  }
> 
> 
> This should elude some ambiguity problems I can foresee with the former 
> definition...

Those usually work better, yes.

V
-- 
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message 
news:g24930$qv3$2@news.datemas.de...
> Chris Thomasson wrote:
>> [..]  I think I need to remove the explicit reference decorations to the
>> templated active<T> constructors. In other words I need to change:
>>
>>  template<typename T_p1>
>>  active(T_p1& p1) : object(p1) {
>>    (object.*T_fp_start)();
>>  }
>>
>>
>> to:
>>
>>
>>  template<typename T_p1>
>>  active(T_p1 p1) : object(p1) {
>>    (object.*T_fp_start)();
>>  }
>>
>>
>> This should elude some ambiguity problems I can foresee with the former 
>> definition...
>
> Those usually work better, yes.

Okay good; I thought so. BTW, the main end goal of this `active<T>' template 
is going to be an attempt at a full-blown C++ layer over POSIX Threads. I 
was thinking of using it to start and join objects which derive from a 
threading base class, which will provide the start/join() procedures for 
`active<T>' to automatically invoke, in a manner which respects the RAII 
idiom. Also, for the syntactic sugar of starting threads. You should be able 
to so something like:


class object : public thread_base {
  void on_entry() {
    // [the thread function];
  }
};


int main() {
  {
    active<object> o[4];
  }
  return 0;
}


That looks fairly clean to me...

;^) 

On Jun 3, 4:18 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
> "Victor Bazarov" <v.Abaza...@comAcast.net> wrote in message
> > Chris Thomasson wrote:
> >>   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
> >>    std::printf("(%p)->Producer::Producer()\n", (void*)this);
>
> > I don't believe you need to cast 'this' here.
>
> Well, I thought that you could only pass a void* pointer to represent a %p
> formatter.

You can pass any data pointer, it's all the same. However, GCC's handy
printf() warnings also warn when you pass a non-void* to a %p, so
casting it does get rid of that warning. Other than squashing a
compiler warning you don't have to do the cast.

Chris Thomasson wrote:

> I was thinking that the compiler would complain about something like:
> 
> "this form of non-aggregate initialization requires a unary constructor"
> 
> For some reason I thought I would have to do something like:
> 
> 
> #include <cstdio>
> #include <string>
> 
> 
> int main() {
>  {
>    std::string names[3] = {
>      std::string("One"),
>      std::string("Two"),
>      std::string("Three")
>    };
>  }
>  std::puts("\n\npress <ENTER> to exit...");
>  std::getchar();
>  return 0;
> }

std::string's char* constructor is not explicit.  You are actually using 
the constructor when you pass char const* data into your array construction.

<jason.cipriani@gmail.com> wrote in message 
news:f7ce3d34-671d-48c4-acc0-6f8450be44f1@r66g2000hsg.googlegroups.com...
> On Jun 3, 4:18 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
>> "Victor Bazarov" <v.Abaza...@comAcast.net> wrote in message
>> > Chris Thomasson wrote:
>> >>   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
>> >>    std::printf("(%p)->Producer::Producer()\n", (void*)this);
>>
>> > I don't believe you need to cast 'this' here.
>>
>> Well, I thought that you could only pass a void* pointer to represent a 
>> %p
>> formatter.
>
> You can pass any data pointer, it's all the same.

Even a function pointer?


> However, GCC's handy
> printf() warnings also warn when you pass a non-void* to a %p, so
> casting it does get rid of that warning. Other than squashing a
> compiler warning you don't have to do the cast. 

On Jun 3, 8:09 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
> <jason.cipri...@gmail.com> wrote in message
> > You can pass any data pointer, it's all the same.
>
> Even a function pointer?

Nope (not reliably, anyways). That's why I specified *data*
pointer. :-)

<jason.cipriani@gmail.com> wrote in message 
news:e5fee407-6d6b-454e-9fbc-f9255992f0d3@56g2000hsm.googlegroups.com...
> On Jun 3, 8:09 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
>> <jason.cipri...@gmail.com> wrote in message
>> > You can pass any data pointer, it's all the same.
>>
>> Even a function pointer?
>
> Nope (not reliably, anyways). That's why I specified *data*
> pointer. :-)

I misinterpreted you. :^o 

On Jun 3, 10:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> Chris Thomasson wrote:

    [...]
> >   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
> >    std::printf("(%p)->Producer::Producer()\n", (void*)this);

> I don't believe you need to cast 'this' here.

He's outputting to a "%p" format, which requires a void* (or
void const*).  He's passing this as a vararg.  This doesn't have
type void*.  So without the cast, it's undefined behavior.

This sort of thing is why good programmers eschew printf and
company.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jun 4, 1:36 am, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
> On Jun 3, 4:18 pm, "Chris Thomasson" <cris...@comcast.net> wrote:

> > "Victor Bazarov" <v.Abaza...@comAcast.net> wrote in message
> > > Chris Thomasson wrote:
> > >>   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
> > >>    std::printf("(%p)->Producer::Producer()\n", (void*)this);

> > > I don't believe you need to cast 'this' here.

> > Well, I thought that you could only pass a void* pointer to
> > represent a %p formatter.

> You can pass any data pointer, it's all the same.

That is simply false.  Technically, you can only pass a void*; I
don't see anything in ISO/IEC 9899 which would even allow void
const*.  In practice, unless the implementation explicitly
verifies, you'll also be able to pass char* and char const*,
since they are required to have the same size and representation
as a void*.  Anything else is undefined behavior, and I've
worked on machines where it would cause random junk to be
output (and could even cause a core dump if there were also a %s
or a %f elsewhere in the format string).

> However, GCC's handy printf() warnings also warn when you pass
> a non-void* to a %p, so casting it does get rid of that
> warning. Other than squashing a compiler warning you don't
> have to do the cast.

According to the C standard, you do.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jun 4, 1:36 am, "jason.cipri...@gmail.com"
> <jason.cipri...@gmail.com> wrote:
> > You can pass any data pointer, it's all the same.
>
> That is simply false.  Technically, you can only pass a void*; I
> don't see anything in ISO/IEC 9899 which would even allow void
> const*.  In practice, unless the implementation explicitly
> verifies, you'll also be able to pass char* and char const*,
> since they are required to have the same size and representation
> as a void*.  Anything else is undefined behavior, and ...

I did not know that. Is that to say that these two statements are not
the same:

int i;
int *k = &i;

void *a = *(void **)&k; // <--- this
void *b = (void *)k; // <--- and this

Or does that only mean that fprintf with %p is undefined unless you
explicitly cast pointer parameters to (void *) first? I could've sworn
that somewhere in C++ it said that the representation for data
pointers was always the same -- do you know where the relevant part of
the standard is (looking in C++03, I couldn't find anything relevant).

> ...I've
> worked on machines where it would cause random junk to be
> output ...

Just out of curiosity, what machines cause things like printf("%p",
(int *)&something); to print random junk?

Jason

On Jun 4, 5:16 am, James Kanze <james.ka...@gmail.com> wrote:
> This sort of thing is why good programmers eschew printf and
> company.

Do you happen to know if C++0x is introducing a convenient ostream
interface that makes things like:

printf("%+9.4f %8.3f\n", value1, value2);

Slightly easier to deal with than:

cout << showpos << fixed << setw(9) << setprecision(4) << value1 <<
noshowpos << setw(8) << setprecision(3) << value2 << endl;

Do you also happen to know if C++0x is introducing an iostreams
interface with informative error returns, e.g an equivalent of:

string errmsg;
if (fprintf(...) < 0)
  errmsg = strerror(errno); // <-- ?

I find iostreams has little to no value over stdio when you are only
dealing with built-in scalar types. Of course it's convenient to
define new ostream << operators for complex types; but for this kind
of stuff iostreams is incredibly cumbersome...

Jason

On Jun 4, 5:43 pm, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
> James Kanze wrote:
> > On Jun 4, 1:36 am, "jason.cipri...@gmail.com"
> > <jason.cipri...@gmail.com> wrote:
> > > You can pass any data pointer, it's all the same.

> > That is simply false.  Technically, you can only pass a void*; I
> > don't see anything in ISO/IEC 9899 which would even allow void
> > const*.  In practice, unless the implementation explicitly
> > verifies, you'll also be able to pass char* and char const*,
> > since they are required to have the same size and representation
> > as a void*.  Anything else is undefined behavior, and ...

> I did not know that. Is that to say that these two statements
> are not the same:

> int i;
> int *k =3D &i;

> void *a =3D *(void **)&k; // <--- this
> void *b =3D (void *)k; // <--- and this

Certainly not.  The first is undefined behavior, and will result
in a more or less random value for a on some processors.

> Or does that only mean that fprintf with %p is undefined
> unless you explicitly cast pointer parameters to (void *)
> first?

Correct.

> I could've sworn that somewhere in C++ it said that the
> representation for data pointers was always the same -- do you
> know where the relevant part of the standard is (looking in
> C++03, I couldn't find anything relevant).

I'm not sure I understand.  You want me to point out in the
standard where the guarantee isn't given.  The real question is
the reverse: what makes you think that an int* has the same size
and layout as a void*.

The fact that the standard feels it necessary to offer some
limited guarantees should be a strong indication, however (from
=A73.9.2, paragraphs 3 and 4, from the 1998 version, since that
and the current draft are all I have on line here):

    [...] The value representation of pointer types is
    implementation-defined.  Pointers to cv-qualified and
    cv-unqualified version of layout-compatible types shall have
    the same value representation and alignment requirements.

    Objects of cv-qualified or cv-unqualified type void*
    (pointer to void) can be used to point to objects of unknown
    type.  A void* shall be able to hold any object pointer.  A
    cv-qualified or cv-unqualified void* shall have the same
    representation and alignment requiremns as a cv-qualified or
    cv-unqualified char*.

In other words: const and non-const pointers to the same type
(or a layout compatible type) must have the same representation,
and void* and char* must have the same representation.  In
addition, the way incomplete types can be used more or less
forces an implementation to use the same representation for all
pointers to class types.  (The only thing the representation
could depend on is the spelling of the class name, which is, of
course, ridiculous.)

You might also look at the guarantees concerning casts---it's
quite clear that casting a void* to int* and back is not
guaranteed to result in the original pointer.  That's there for
a reason.

> > ...I've worked on machines where it would cause random junk
> > to be output ...

> Just out of curiosity, what machines cause things like
> printf("%p", (int *)&something); to print random junk?

Word addressed machines.  The machine in question had
sizeof(int*) =3D=3D 2, but sizeof(char*) =3D=3D 4; the basic hardware
pointer (16 bits) addressed words, and not bytes, and you needed
additional bits (an additional word) to access individual bytes.

Not so many years ago, this was the most frequent arrangment.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

On Jun 4, 5:57 pm, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
> On Jun 4, 5:16 am, James Kanze <james.ka...@gmail.com> wrote:

> > This sort of thing is why good programmers eschew printf and
> > company.

> Do you happen to know if C++0x is introducing a convenient ostream
> interface that makes things like:

> printf("%+9.4f %8.3f\n", value1, value2);

> Slightly easier to deal with than:

> cout << showpos << fixed << setw(9) << setprecision(4) << value1 <<
> noshowpos << setw(8) << setprecision(3) << value2 << endl;

Who writes things like that?  Normally you'd write something
like:

    cout << semantic1 << value1
         << ' ' << semantic2 << value2 << endl ;

Rather than specifying the formatting in each output statement,
you'd define application specific formatting for the specific
semantics of the values in your application, and use them.  (For
what it's worth, I think that setw() is the only standard
manipulator I've ever used.)

> Do you also happen to know if C++0x is introducing an
> iostreams interface with informative error returns, e.g an
> equivalent of:

> string errmsg;
> if (fprintf(...) < 0)
>   errmsg =3D strerror(errno); // <-- ?

> I find iostreams has little to no value over stdio when you
> are only dealing with built-in scalar types.

If you put no value on avoiding errors and undefined behavior,
nor on using logical mark-up, rather than low level physical
formatting primitives, nor on being able to output to more or
less anything, inserting filters, etc., without changing the
code doing the outputting, then they don't add much value, no.
I consider all three of those points important for good software
engineering, however.

> Of course it's convenient to define new ostream << operators
> for complex types; but for this kind of stuff iostreams is
> incredibly cumbersome...

I find it less cumbersome than fprintf.  And far less error
prone.

--
James Kanze (GABI Software)             email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34

"James Kanze" <james.kanze@gmail.com> wrote in message 
news:07ca5383-3d9b-4ec9-8f4d-8e6451fec750@r66g2000hsg.googlegroups.com...
> On Jun 3, 10:02 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> > Chris Thomasson wrote:

    [...]
> > >   : m_id(id), m_name("Default Producer"), m_Buffer(_Buffer) {
> > >    std::printf("(%p)->Producer::Producer()\n", (void*)this);

> > I don't believe you need to cast 'this' here.

> He's outputting to a "%p" format, which requires a void* (or
> void const*).  He's passing this as a vararg.  This doesn't have
> type void*.  So without the cast, it's undefined behavior.

Right. Thats what I thought.


> This sort of thing is why good programmers eschew printf and
> company.

;^)


Well, I use `printf', or I should correctly say `std::printf', simply 
because I am truly a C programmer at heart.

:^o 

On 4 Jun, 17:57, "jason.cipri...@gmail.com" <jason.cipri...@gmail.com>
wrote:
> Do you happen to know if C++0x is introducing a convenient ostream
> interface that makes things like:
>
> printf("%+9.4f %8.3f\n", value1, value2);
>
> Slightly easier to deal with than:
>
> cout << showpos << fixed << setw(9) << setprecision(4) << value1 <<
> noshowpos << setw(8) << setprecision(3) << value2 << endl;

Boost::format provides typesafe, "printf-like" formatting. If I'm not
mistaken Andrei Alexandrescu also published a similar utility.

DP

On Jun 5, 4:28 am, Triple-DES <DenPlettf...@gmail.com> wrote:
> On 4 Jun, 17:57, "jason.cipri...@gmail.com" <jason.cipri...@gmail.com>
> wrote:
>
> > Do you happen to know if C++0x is introducing a convenient ostream
> > interface that makes things like:
>
> > printf("%+9.4f %8.3f\n", value1, value2);
>
> > Slightly easier to deal with than:
>
> > cout << showpos << fixed << setw(9) << setprecision(4) << value1 <<
> > noshowpos << setw(8) << setprecision(3) << value2 << endl;
>
> Boost::format provides typesafe, "printf-like" formatting. If I'm not
> mistaken Andrei Alexandrescu also published a similar utility.

Thanks for pointing this out; I messed around with it and have been
using it for a couple of days now. It's really pretty cool. Maybe I'll
start dumping the printf habit after all. Maybe.

Jason