Hello,

Compiling following example:

#include <string>
class A
{
     public:

         A(int)
         {
         }
         A(...)
         {
             throw 111;
         }
         ~A()
         {
         }
};
int main()
{
     A a( 55 );
     A b( std::string("aaa") );   // this doesn't work
}

would stop the compiler with next error output:
g++ yui.cpp
yui.cpp: In function �int main()�:
yui.cpp:23: warning: cannot pass objects of non-POD type �struct 
std::string� through �...�; call will abort at runtime


I tried modified the example to have a constructor as a template 
function, but since I am using pimpl idiom, I am getting next error:

************
[vladimir@thuja projectCyclades]$ ./scripts/build_host_unit_test.sh
In file included from 
/sandbox/vladimir/projectCyclades/_host_test/../utils/cxxtest/cxxtest/Root.cpp:17,
                  from 
/sandbox/vladimir/projectCyclades/_host_test/./obj/a_sda/testgen/unit_test_runner.cpp:955:
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward/auto_ptr.h: 
In destructor �std::auto_ptr<_Tp>::~auto_ptr() [with _Tp = 
ezono::ccapp::sda::FilterLogCompression::Imp]�:
/sandbox/vladimir/projectCyclades/_host_test/../code/i_ptr/inco_ptr_autoptr.hpp:127: 
   instantiated from �ezono::inco::ptr::AutoPtr<T>::AutoPtr(T*) [with T 
= ezono::ccapp::sda::FilterLogCompression::Imp]�
/sandbox/vladimir/projectCyclades/_host_test/../code/a_sda/ccapp_sda_filterlogcompression.hpp:119: 
   instantiated from 
�ezono::ccapp::sda::FilterLogCompression::FilterLogCompression(const 
InBuffType&, OutBuffType&) [with InBuffType = 
ezono::ccapp::sda::FilterBuffer<ezono::ccapp::sda::Buffer32Bits, false>, 
OutBuffType = 
ezono::ccapp::sda::FilterBuffer<ezono::ccapp::sda::Buffer8Bits, false>]�
/sandbox/vladimir/projectCyclades/_host_test/../code/a_sda/unittests/test_ccapp_sda_filterlogcompression.hpp:119: 
   instantiated from here
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward/auto_ptr.h:173: 
note: neither the destructor nor the class-specific operator delete will 
be called, even if they are declared when the class is defined.
************
I will create another example demonstrating this.


Is there a way to modify the example above to work for non-pod types?

Vladimir Jovic wrote:
> I tried modified the example to have a constructor as a template 
> function, but since I am using pimpl idiom, I am getting next error:
> 

Here is another example, with a template constructor :


// class header - guh.hpp
#include <memory>
#ifndef AAAAAAA_H
#define AAAAAAA_H
class A
{
     public:

         A(int);
         template< typename T >
         A(T) : pimpl( NULL )
         {
             throw 111;
         }
         ~A();


         struct Imp;
         std::auto_ptr< Imp > pimpl;
};
#endif


// class source - guh.cpp
#include "guh.hpp"
struct A::Imp
{
};
A::A(int) : pimpl( new Imp )
{
}
A::~A()
{
}

// the main()
#include "guh.hpp"
#include <string>
int main()
{
     A a(5);
     A b(std::string("aaa"));
}

The output is:
[vladimir@thuja data_create]$ g++ guh.cpp gug.cpp
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward/auto_ptr.h: 
In destructor �std::auto_ptr<_Tp>::~auto_ptr() [with _Tp = A::Imp]�:
guh.hpp:13:   instantiated from �A::A(T) [with T = 
std::basic_string<char, std::char_traits<char>, std::allocator<char> >]�
gug.cpp:8:   instantiated from here
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward/auto_ptr.h:173: 
note: neither the destructor nor the class-specific operator delete will 
be called, even if they are declared when the class is defined.

Template example update:
/////////////////////////////
template< typename T >
class B
{
     public:
         virtual ~B()
         {
         }
};
template< typename T >
class C : public B< T >
{
     public:
         virtual ~C()
         {
         }
};
class A
{
     public:
         A(const B< int > &)
         {
         }
         template< typename T >
         A(T)
         {
             throw 111;
         }
         ~A()
         {
         }
};
int main()
{
     A a( C<int>() ); // doesn't throw

     B<int> *b = new C<int>;
     A e(*b);         // doesn't throw

     C< int > c;
     A d(c);   // throws
}
////////////////

This example really demonstrates a problem I am facing.

So, is there a way to create such a constructor that is going a take a 
reference to a specific base type, and to throw for all other types?

"Vladimir Jovic" <vladaspams@gmail.com>
>         A(...)
> int main()
> {
>     A a( 55 );
>     A b( std::string("aaa") );   // this doesn't work

Passing non-POD as argument ... is undefined behavior.

> yui.cpp:23: warning: cannot pass objects of non-POD type �struct 
> std::string� through �...�; call will abort at runtime

Just as the compiler correctly states.

Vladimir Jovic wrote:
> Vladimir Jovic wrote:
>> I tried modified the example to have a constructor as a template 
>> function, but since I am using pimpl idiom, I am getting next error:
>>

And the error has nothing to do with your template, but everything to do 
with the fact that you're using 'auto_ptr'.

> 
> The output is:
> [vladimir@thuja data_create]$ g++ guh.cpp gug.cpp
> /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward/auto_ptr.h: 
> In destructor �std::auto_ptr<_Tp>::~auto_ptr() [with _Tp = A::Imp]�:
> guh.hpp:13:   instantiated from �A::A(T) [with T = 
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >]�
> gug.cpp:8:   instantiated from here
> /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/backward/auto_ptr.h:173: 
> note: neither the destructor nor the class-specific operator delete will 
> be called, even if they are declared when the class is defined.

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

Vladimir Jovic wrote:
> Template example update:
> /////////////////////////////
> template< typename T >
> class B
> {
>     public:
>         virtual ~B()
>         {
>         }
> };
> template< typename T >
> class C : public B< T >
> {
>     public:
>         virtual ~C()
>         {
>         }
> };
> class A
> {
>     public:
>         A(const B< int > &)
>         {
>         }
>         template< typename T >
>         A(T)
>         {
>             throw 111;
>         }
>         ~A()
>         {
>         }
> };
> int main()
> {
>     A a( C<int>() ); // doesn't throw
> 
>     B<int> *b = new C<int>;
>     A e(*b);         // doesn't throw
> 
>     C< int > c;
>     A d(c);   // throws
> }
> ////////////////
> 
> This example really demonstrates a problem I am facing.

Which is what?

> So, is there a way to create such a constructor that is going a take a 
> reference to a specific base type, and to throw for all other types?

You made three examples, all of different classes.  Some have a 
templated c-tor, others don't...  Do you expect us to read your mind? 
If you want help, write down (and post) the requirements.  Don't make 
use guess.  Please.

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

"Vladimir Jovic" <vladaspams@gmail.com>

>         struct Imp;
>         std::auto_ptr< Imp > pimpl;

instantiating any std:: element with an incomplete type is undefined 
behavior.
And auto_ptr is a poor choice anyway.

Use some appropriate smart pointer that is more tolerant, or make sure to 
postpone all visible and invisible instantiation points after the type is 
defined, it is not so easy both in theory and practice. 

Victor Bazarov wrote:

>> This example really demonstrates a problem I am facing.
> 
> Which is what?
> 
>> So, is there a way to create such a constructor that is going a take a 
>> reference to a specific base type, and to throw for all other types?
> 
> You made three examples, all of different classes.  Some have a 
> templated c-tor, others don't...  Do you expect us to read your mind? If 
> you want help, write down (and post) the requirements.  Don't make use 
> guess.  Please.


I thought an example would be better ;)

I have a bunch of template base classes representing buffers (to hold 
data), which are really arrays with different data types (unsigned int, 
unsigned short, unsigned char). There are few derived classes which do 
something, but the base classes just provide a pointer to it's internal 
data array. Total number of base classes is 6, but can be extended.

Then I have bunch of classes representing filters. Each filter class 
take a reference to input and output buffers, and use them to read input 
data, and to write processed data. Input and output buffers can have 
different data types.

Now, I want to connect these filters into a pipeline. I thought to 
create buffers, then to create filters.
Some filters support only one data type (for example 8-bit input, 16-bit 
output), and I want to throw an exception if someone tries to pass any 
other combination to this filter (for example, 32-bit input/8-bit output).



Maybe my design is broken in the first place. Please say if you think 
there is a better way.


The problem with auto_ptr is a side effect, which I will solve somehow.

Balog Pal wrote:
> "Vladimir Jovic" <vladaspams@gmail.com>
>>         A(...)
>> int main()
>> {
>>     A a( 55 );
>>     A b( std::string("aaa") );   // this doesn't work
> 
> Passing non-POD as argument ... is undefined behavior.
> 
>> yui.cpp:23: warning: cannot pass objects of non-POD type �struct 
>> std::string� through �...�; call will abort at runtime
> 
> Just as the compiler correctly states.
> 
> 

Thanks. So, that solution is out :(

"Vladimir Jovic" <vladaspams@gmail.com>
> Template example update:
> /////////////////////////////
> template< typename T >
> class B
> {
>     public:
>         virtual ~B()
>         {
>         }
> };
> template< typename T >
> class C : public B< T >
> {
>     public:
>         virtual ~C()
>         {
>         }
> };
> class A
> {
>     public:
>         A(const B< int > &)
>         {
>         }
>         template< typename T >
>         A(T)
>         {
>             throw 111;
>         }
>         ~A()
>         {
>         }
> };
> int main()
> {
>     A a( C<int>() ); // doesn't throw

this line is a declaration, not creating an onject 'a'. Try

     A a(( C<int>() )); // throws
>
>     B<int> *b = new C<int>;
>     A e(*b);         // doesn't throw
>
>     C< int > c;
>     A d(c);   // throws
> }
> ////////////////
>
> This example really demonstrates a problem I am facing.
>
> So, is there a way to create such a constructor that is going a take a 
> reference to a specific base type, and to throw for all other types?

With an overload set template function is chosed if it creates a better 
match -- in this case tepmlate is instantiated for  T = C<int> that matches 
perfectly, while the fixed function would need a derived-to-base conversion.

Boost:: has support for type traits and conditionals in templates, I guess 
you could create a template that checks whether its T is derived from B<T> 
using the tools there and make it work, while the rest throw.  (Btw what is 
the point of throw? Why not place a compile-time error/ STATIC_ASSERT 
there?) 

Vladimir Jovic wrote:
> Victor Bazarov wrote:
> 
>>> This example really demonstrates a problem I am facing.
>>
>> Which is what?
>>
>>> So, is there a way to create such a constructor that is going a take 
>>> a reference to a specific base type, and to throw for all other types?
>>
>> You made three examples, all of different classes.  Some have a 
>> templated c-tor, others don't...  Do you expect us to read your mind? 
>> If you want help, write down (and post) the requirements.  Don't make 
>> use guess.  Please.
> 
> 
> I thought an example would be better ;)
> 
> I have a bunch of template base classes representing buffers (to hold 
> data), which are really arrays with different data types (unsigned int, 
> unsigned short, unsigned char). There are few derived classes which do 
> something, but the base classes just provide a pointer to it's internal 
> data array. Total number of base classes is 6, but can be extended.

So, they are all different, yes?  Or do they have a common base class?

> Then I have bunch of classes representing filters. Each filter class 
> take a reference to input and output buffers, and use them to read input 
> data, and to write processed data. Input and output buffers can have 
> different data types.
> 
> Now, I want to connect these filters into a pipeline. I thought to 
> create buffers, then to create filters.

You create the filters using their c-tors?  Or is there some kind of 
factory mechanism?

> Some filters support only one data type (for example 8-bit input, 16-bit 
> output), and I want to throw an exception if someone tries to pass any 
> other combination to this filter (for example, 32-bit input/8-bit output).

So, are there filters that support more than one pair of types?  Are 
they created using pairs or do you define input and output separately?

> Maybe my design is broken in the first place. Please say if you think 
> there is a better way.

Let's imagine you have a bunch of type conversion classes.  Let's say 
that every class converts from type1 to type2.  And let's say that 
type1!=type2.  So we can come up with

     template<typename t1, typename t2> class converter;

Now, what's going to be its interface?  What is it supposed to do?

First off, if you're going to place them in some kind of container 
(queue, list, whatever), they gotta be homogeneous, yes?  So, they most 
likely have the same base class.

Second, if the container (queue, list) is going to act in some way to 
process itself, then it's going to call some kind of 'process' method, 
yes?  Now, I don't want to redesign all of it for you, but it does seem 
like a Pandora's box (a can of worms).  How are the data defined?  They 
need to be unified in some way for the list to process its contents in a 
generic way, yes?  And so forth.

The sky is the limit on the design, AFAICT.  What are the [6] types of 
the buffers the filters need to deal with?  What is the interface you 
think you need for the filters?  If you have figured it out, but are 
stuck on the implementation phase, let's see those interfaces 
(declarations only, if you don't have anything beyond that).

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:
> Vladimir Jovic wrote:
>> Victor Bazarov wrote:
>>
>>>> This example really demonstrates a problem I am facing.
>>>
>>> Which is what?
>>>
>>>> So, is there a way to create such a constructor that is going a take 
>>>> a reference to a specific base type, and to throw for all other types?
>>>
>>> You made three examples, all of different classes.  Some have a 
>>> templated c-tor, others don't...  Do you expect us to read your mind? 
>>> If you want help, write down (and post) the requirements.  Don't make 
>>> use guess.  Please.
>>
>>
>> I thought an example would be better ;)
>>
>> I have a bunch of template base classes representing buffers (to hold 
>> data), which are really arrays with different data types (unsigned 
>> int, unsigned short, unsigned char). There are few derived classes 
>> which do something, but the base classes just provide a pointer to 
>> it's internal data array. Total number of base classes is 6, but can 
>> be extended.
> 
> So, they are all different, yes?  Or do they have a common base class?
> 

They are all different types.
template< typename T > class BufferBase;
template< typename T, bool allign > class Buffer : public BufferBase<T>;
class SourceBuffer : class template< unsigned short >;
class DestinationBuffer : class template< unsigned char >;

T = "unsigned int", "unsigned short", or "unsigned char"
allign - tells if the data has to be 16-byte alignment, as I want to use 
sse2 instructions.

>> Then I have bunch of classes representing filters. Each filter class 
>> take a reference to input and output buffers, and use them to read 
>> input data, and to write processed data. Input and output buffers can 
>> have different data types.
>>
>> Now, I want to connect these filters into a pipeline. I thought to 
>> create buffers, then to create filters.
> 
> You create the filters using their c-tors?  Or is there some kind of 
> factory mechanism?
> 

Right now there are no factory mechanisms, as I starting working on this 
recently. But I will have to implement one later.

The filter classes have a common base class:
class PipelineElement;
class Filter : public PipelineElement;

>> Some filters support only one data type (for example 8-bit input, 
>> 16-bit output), and I want to throw an exception if someone tries to 
>> pass any other combination to this filter (for example, 32-bit 
>> input/8-bit output).
> 
> So, are there filters that support more than one pair of types?  Are 
> they created using pairs or do you define input and output separately?
> 

My plan is to create Filter types using BufferBase objects, but without 
having to define 8 different constructors.
For now, Filters support only one BufferBase pair. Not sure if that can 
change (I hope not, but nothing surprises me anymore).


Then another process sends a configuration message (not defined), and 
the pipeline modify itself in two steps:
1) create buffers between filters (the first and last buffers are always 
the source and destination buffers)
2) create filter objects - connect buffers in the filters constructor

If someone pass invalid configuration message, a filter creation fails 
with an exception. For example, connect a filter with 16-bit output on a 
filter that has 8-bit input.

Buffers (except for the source and destination) can be created in a 
vector, list, or queue (different container objects for different base 
buffer classes).
All filter objects will be stored in one container, and the data will be 
processed in one run.

Balog Pal wrote:
> "Vladimir Jovic" <vladaspams@gmail.com>
>> Template example update:
>> /////////////////////////////
>> template< typename T >
>> class B
>> {
>>     public:
>>         virtual ~B()
>>         {
>>         }
>> };
>> template< typename T >
>> class C : public B< T >
>> {
>>     public:
>>         virtual ~C()
>>         {
>>         }
>> };
>> class A
>> {
>>     public:
>>         A(const B< int > &)
>>         {
>>         }
>>         template< typename T >
>>         A(T)
>>         {
>>             throw 111;
>>         }
>>         ~A()
>>         {
>>         }
>> };
>> int main()
>> {
>>     A a( C<int>() ); // doesn't throw
> 
> this line is a declaration, not creating an onject 'a'. Try
> 
>      A a(( C<int>() )); // throws
>>     B<int> *b = new C<int>;
>>     A e(*b);         // doesn't throw
>>
>>     C< int > c;
>>     A d(c);   // throws
>> }
>> ////////////////
>>
>> This example really demonstrates a problem I am facing.
>>
>> So, is there a way to create such a constructor that is going a take a 
>> reference to a specific base type, and to throw for all other types?
> 
> With an overload set template function is chosed if it creates a better 
> match -- in this case tepmlate is instantiated for  T = C<int> that matches 
> perfectly, while the fixed function would need a derived-to-base conversion.
> 

The problem is that I have several base classes. Like in the example, 
the base class is a template. Do you have an example (or modify mine) 
how to do such conversion?

> Boost:: has support for type traits and conditionals in templates, I guess 
> you could create a template that checks whether its T is derived from B<T> 
> using the tools there and make it work, while the rest throw.  (Btw what is 

Will investigate. Thanks for pointing this out

> the point of throw? Why not place a compile-time error/ STATIC_ASSERT 
> there?) 
> 
> 

As explained to Victor, the processing pipeline should be set 
dynamically. Any attempt to create an invalid pipeline should be caught 
and the error should be reported.

Vladimir Jovic wrote:
> [..]
> Buffers (except for the source and destination) can be created in a 
> vector, list, or queue (different container objects for different base 
> buffer classes).

Where do those live and what is the relationship between buffers of 
different types (instance of different templates) and the queue (one 
object) which is going to "connect buffers"?

> All filter objects will be stored in one container, and the data will be 
> processed in one run.

OK, let's proceed with a simplified model.  Let's have a queue of two 
filters, and make it create all the "buffers" for those and process the 
input to get to the output.

struct Filter
{
    virtual void setFrom(???);
    virtual void setTo(???);

    virtual void process(??, ??);
};

// now, is this queue generic or does it know how many filters
// it has and what is the sequence of types it processes?
struct FilterQueue
{
     typedef std::list<Filter*> list;
     typedef list::iterator iterator;

     list filters;

     void append(Filter* pf) { filters.push_back(pf); }

     void createBuffers(???) {
         // the filters are added in 'append', here we need to add
         // all the buffers between the filters

         for (iterator it = filters.begin(); it != filters.end; ++it)
         {
            // it would seem that the buffers have to be *ALSO*
            // storable in some kind of container, no?  Otherwise
            // how do you move from 'createBuffers' to 'process'?
         }
     }

     void process(???) {
         for (iterator it = filters.begin(); it != filters.end; ++it)
             it->process(??,??);
     }
};

I can only see more questions that haven't yet been answered.  Do you 
have any answers?

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

"Vladimir Jovic" <vladaspams@gmail.com>

> As explained to Victor, the processing pipeline should be set dynamically. 
> Any attempt to create an invalid pipeline should be caught and the error 
> should be reported.

If so, any attmpt to to solve the situation by overload-resolution is 
futile. You have to decide validity *inside* the function, and throw on an 
if()-like condition.

You shall use some dynamic_cast, or a virtual function in the base interface 
that reports the attributes of your buffer. 

Balog Pal wrote:
> "Vladimir Jovic" <vladaspams@gmail.com>
> 
>> As explained to Victor, the processing pipeline should be set dynamically. 
>> Any attempt to create an invalid pipeline should be caught and the error 
>> should be reported.
> 
> If so, any attmpt to to solve the situation by overload-resolution is 
> futile. You have to decide validity *inside* the function, and throw on an 
> if()-like condition.
> 
> You shall use some dynamic_cast, or a virtual function in the base interface 
> that reports the attributes of your buffer. 
> 
> 

That would be another approach : to add a common base class for all 
BufferBase template classes, and use a dynamic_cast to expected buffer 
type, and if the cast fails then to throw an exception. But I thought 
there is a more elegant solution.

Too bad a trick with ellipses doesn't work :(

Victor Bazarov wrote:
> Vladimir Jovic wrote:
>> [..]
>> Buffers (except for the source and destination) can be created in a 
>> vector, list, or queue (different container objects for different base 
>> buffer classes).
> 
> Where do those live and what is the relationship between buffers of 
> different types (instance of different templates) and the queue (one 
> object) which is going to "connect buffers"?
> 

Buffers are created on the heap, and are completely independent. The 
requirements are that the first has to be the source buffer type, which 
somehow gets input data (doesn't matter how), and the last has to be the 
destination buffer type, where the resulting data is stored.

Data is of fixed size, which is known in front.

>> All filter objects will be stored in one container, and the data will 
>> be processed in one run.
> 
> OK, let's proceed with a simplified model.  Let's have a queue of two 
> filters, and make it create all the "buffers" for those and process the 
> input to get to the output.
> 
> struct Filter
> {
>    virtual void setFrom(???);
>    virtual void setTo(???);
> 
>    virtual void process(??, ??);
> };
> 

It is actually simpler :
struct Filter
{
   Filter( const BufferType1 &b1, BufferType2 &b2 );

   virtual void Process();
};

or as you wrote it:
struct Filter
{
   void SetFrom( const BufferType1 &b1 );
   void SetTo( BufferType1 &b1 );

   virtual void Process();
};

Only one combination of BufferType1/BufferType2 are valid for any Filter 
type.

The Process() method reads data from the input buffer, process it, and 
store the result in the output buffer.

> // now, is this queue generic or does it know how many filters
> // it has and what is the sequence of types it processes?

The queue is generic, and can be changed during the program execution. 
It can contain any number of filters.

If it was static, I would not have this problem.

> struct FilterQueue
> {
>     typedef std::list<Filter*> list;
>     typedef list::iterator iterator;
> 
>     list filters;
> 
>     void append(Filter* pf) { filters.push_back(pf); }
> 
>     void createBuffers(???) {
>         // the filters are added in 'append', here we need to add
>         // all the buffers between the filters
> 
>         for (iterator it = filters.begin(); it != filters.end; ++it)
>         {
>            // it would seem that the buffers have to be *ALSO*
>            // storable in some kind of container, no?  Otherwise
>            // how do you move from 'createBuffers' to 'process'?
>         }
>     }
> 
>     void process(???) {
>         for (iterator it = filters.begin(); it != filters.end; ++it)
>             it->process(??,??);
>     }
> };
> 
> I can only see more questions that haven't yet been answered.  Do you 
> have any answers?

There are actually two classes:

class BufferQueue
{
   typedef std::list<Filter*> list;
   typedef list::iterator iterator;

   void CreateBuffers( ConfigType & )
   {
     list.push( sourceBuffer);

     // create all intermediate buffers

     list.push( destBuffer);
   }

   list buffers;
};

struct FilterQueue
{
     typedef std::list<Filter*> list;
     typedef list::iterator iterator;

     list filters;

   void CreateFilters( ConfigType &, BufferQueue & )
   {
     // read configuration
     // create filters (types are defined in the configuration)
     // connect buffers to each filter
   }


     void process() {
         for (iterator it = filters.begin(); it != filters.end; ++it)
             it->process();
     }
};

Vladimir Jovic wrote:
> Victor Bazarov wrote:
>> Vladimir Jovic wrote:
>>> [..]
>>> Buffers (except for the source and destination) can be created in a 
>>> vector, list, or queue (different container objects for different 
>>> base buffer classes).
>>
>> Where do those live and what is the relationship between buffers of 
>> different types (instance of different templates) and the queue (one 
>> object) which is going to "connect buffers"?
>>
> 
> Buffers are created on the heap, and are completely independent.

They can't be independent if they are put in a queue.

 > The
> requirements are that the first has to be the source buffer type, which 
> somehow gets input data (doesn't matter how), and the last has to be the 
> destination buffer type, where the resulting data is stored.
> 
> Data is of fixed size, which is known in front.
> 
>>> All filter objects will be stored in one container, and the data will 
>>> be processed in one run.
>>
>> OK, let's proceed with a simplified model.  Let's have a queue of two 
>> filters, and make it create all the "buffers" for those and process 
>> the input to get to the output.
>>
>> struct Filter
>> {
>>    virtual void setFrom(???);
>>    virtual void setTo(???);
>>
>>    virtual void process(??, ??);
>> };
>>
> 
> It is actually simpler :
> struct Filter
> {
>   Filter( const BufferType1 &b1, BufferType2 &b2 );
> 
>   virtual void Process();
> };
> 
> or as you wrote it:
> struct Filter
> {
>   void SetFrom( const BufferType1 &b1 );
>   void SetTo( BufferType1 &b1 );
> 
>   virtual void Process();
> };
> 
> Only one combination of BufferType1/BufferType2 are valid for any Filter 
> type.
> 
> The Process() method reads data from the input buffer, process it, and 
> store the result in the output buffer.
> 
>> // now, is this queue generic or does it know how many filters
>> // it has and what is the sequence of types it processes?
> 
> The queue is generic, and can be changed during the program execution. 
> It can contain any number of filters.
> 
> If it was static, I would not have this problem.
> 
>> struct FilterQueue
>> {
>>     typedef std::list<Filter*> list;
>>     typedef list::iterator iterator;
>>
>>     list filters;
>>
>>     void append(Filter* pf) { filters.push_back(pf); }
>>
>>     void createBuffers(???) {
>>         // the filters are added in 'append', here we need to add
>>         // all the buffers between the filters
>>
>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>         {
>>            // it would seem that the buffers have to be *ALSO*
>>            // storable in some kind of container, no?  Otherwise
>>            // how do you move from 'createBuffers' to 'process'?
>>         }
>>     }
>>
>>     void process(???) {
>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>             it->process(??,??);
>>     }
>> };
>>
>> I can only see more questions that haven't yet been answered.  Do you 
>> have any answers?
> 
> There are actually two classes:
> 
> class BufferQueue
> {
>   typedef std::list<Filter*> list;
                       ^^^^^^
Really?

>   typedef list::iterator iterator;
> 
>   void CreateBuffers( ConfigType & )
>   {
>     list.push( sourceBuffer);

What is 'sourceBuffer'?  What type does it have?  Is it convertible to 
'Filter*'?

> 
>     // create all intermediate buffers
> 
>     list.push( destBuffer);
>   }
> 
>   list buffers;
> };
> 
> struct FilterQueue
> {
>     typedef std::list<Filter*> list;
>     typedef list::iterator iterator;
> 
>     list filters;
> 
>   void CreateFilters( ConfigType &, BufferQueue & )
>   {
>     // read configuration
>     // create filters (types are defined in the configuration)
>     // connect buffers to each filter
>   }
> 
> 
>     void process() {
>         for (iterator it = filters.begin(); it != filters.end; ++it)
>             it->process();
>     }
> };

Seems like you got a few things to figure out, still.

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:
> Vladimir Jovic wrote:
>> Victor Bazarov wrote:
>>> Vladimir Jovic wrote:
>>>> [..]
>>>> Buffers (except for the source and destination) can be created in a 
>>>> vector, list, or queue (different container objects for different 
>>>> base buffer classes).
>>>
>>> Where do those live and what is the relationship between buffers of 
>>> different types (instance of different templates) and the queue (one 
>>> object) which is going to "connect buffers"?
>>>
>>
>> Buffers are created on the heap, and are completely independent.
> 
> They can't be independent if they are put in a queue.

Not sure I understand. Why they wouldn't be independent?

> 
>  > The
>> requirements are that the first has to be the source buffer type, 
>> which somehow gets input data (doesn't matter how), and the last has 
>> to be the destination buffer type, where the resulting data is stored.
>>
>> Data is of fixed size, which is known in front.
>>
>>>> All filter objects will be stored in one container, and the data 
>>>> will be processed in one run.
>>>
>>> OK, let's proceed with a simplified model.  Let's have a queue of two 
>>> filters, and make it create all the "buffers" for those and process 
>>> the input to get to the output.
>>>
>>> struct Filter
>>> {
>>>    virtual void setFrom(???);
>>>    virtual void setTo(???);
>>>
>>>    virtual void process(??, ??);
>>> };
>>>
>>
>> It is actually simpler :
>> struct Filter
>> {
>>   Filter( const BufferType1 &b1, BufferType2 &b2 );
>>
>>   virtual void Process();
>> };
>>
>> or as you wrote it:
>> struct Filter
>> {
>>   void SetFrom( const BufferType1 &b1 );
>>   void SetTo( BufferType1 &b1 );
>>
>>   virtual void Process();
>> };
>>
>> Only one combination of BufferType1/BufferType2 are valid for any 
>> Filter type.
>>
>> The Process() method reads data from the input buffer, process it, and 
>> store the result in the output buffer.
>>
>>> // now, is this queue generic or does it know how many filters
>>> // it has and what is the sequence of types it processes?
>>
>> The queue is generic, and can be changed during the program execution. 
>> It can contain any number of filters.
>>
>> If it was static, I would not have this problem.
>>
>>> struct FilterQueue
>>> {
>>>     typedef std::list<Filter*> list;
>>>     typedef list::iterator iterator;
>>>
>>>     list filters;
>>>
>>>     void append(Filter* pf) { filters.push_back(pf); }
>>>
>>>     void createBuffers(???) {
>>>         // the filters are added in 'append', here we need to add
>>>         // all the buffers between the filters
>>>
>>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>>         {
>>>            // it would seem that the buffers have to be *ALSO*
>>>            // storable in some kind of container, no?  Otherwise
>>>            // how do you move from 'createBuffers' to 'process'?
>>>         }
>>>     }
>>>
>>>     void process(???) {
>>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>>             it->process(??,??);
>>>     }
>>> };
>>>
>>> I can only see more questions that haven't yet been answered.  Do you 
>>> have any answers?
>>
>> There are actually two classes:
>>
>> class BufferQueue
>> {
>>   typedef std::list<Filter*> list;
>                       ^^^^^^
> Really?
> 

Typo. Should have been Buffer*

>>   typedef list::iterator iterator;
>>
>>   void CreateBuffers( ConfigType & )
>>   {
>>     list.push( sourceBuffer);
> 
> What is 'sourceBuffer'?  What type does it have?  Is it convertible to 
> 'Filter*'?
> 

It is not. The source and destination buffers are declared like this:
class SourceBuffer : public BufferBase< unsigned short >;
class DestinationBuffer : public BufferBase< unsigned char >;


>>
>>     // create all intermediate buffers
>>
>>     list.push( destBuffer);
>>   }
>>
>>   list buffers;
>> };
>>

Actually, since I got 3 base types (BufferBase is a template), there 
should be 3 queues for each buffer type.

The idea is to have dump Buffer classes, which holds array as 
intermediate data points, and to use Filter classes to transfer and 
transform data from one point to another (from the source to the 
destination/sink)

>> struct FilterQueue
>> {
>>     typedef std::list<Filter*> list;
>>     typedef list::iterator iterator;
>>
>>     list filters;
>>
>>   void CreateFilters( ConfigType &, BufferQueue & )
>>   {
>>     // read configuration
>>     // create filters (types are defined in the configuration)
>>     // connect buffers to each filter
>>   }
>>
>>
>>     void process() {
>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>             it->process();
>>     }
>> };
> 
> Seems like you got a few things to figure out, still.

Looked simple and straight-forward on the paper :/

Vladimir Jovic wrote:
> Victor Bazarov wrote:
>> Vladimir Jovic wrote:
>>> Victor Bazarov wrote:
>>>> Vladimir Jovic wrote:
>>>>> [..]
>>>>> Buffers (except for the source and destination) can be created in a 
>>>>> vector, list, or queue (different container objects for different 
>>>>> base buffer classes).
>>>>
>>>> Where do those live and what is the relationship between buffers of 
>>>> different types (instance of different templates) and the queue (one 
>>>> object) which is going to "connect buffers"?
>>>>
>>>
>>> Buffers are created on the heap, and are completely independent.
>>
>> They can't be independent if they are put in a queue.
> 
> Not sure I understand. Why they wouldn't be independent?
> 
>>
>>  > The
>>> requirements are that the first has to be the source buffer type, 
>>> which somehow gets input data (doesn't matter how), and the last has 
>>> to be the destination buffer type, where the resulting data is stored.
>>>
>>> Data is of fixed size, which is known in front.
>>>
>>>>> All filter objects will be stored in one container, and the data 
>>>>> will be processed in one run.
>>>>
>>>> OK, let's proceed with a simplified model.  Let's have a queue of 
>>>> two filters, and make it create all the "buffers" for those and 
>>>> process the input to get to the output.
>>>>
>>>> struct Filter
>>>> {
>>>>    virtual void setFrom(???);
>>>>    virtual void setTo(???);
>>>>
>>>>    virtual void process(??, ??);
>>>> };
>>>>
>>>
>>> It is actually simpler :
>>> struct Filter
>>> {
>>>   Filter( const BufferType1 &b1, BufferType2 &b2 );
>>>
>>>   virtual void Process();
>>> };
>>>
>>> or as you wrote it:
>>> struct Filter
>>> {
>>>   void SetFrom( const BufferType1 &b1 );
>>>   void SetTo( BufferType1 &b1 );
>>>
>>>   virtual void Process();
>>> };
>>>
>>> Only one combination of BufferType1/BufferType2 are valid for any 
>>> Filter type.
>>>
>>> The Process() method reads data from the input buffer, process it, 
>>> and store the result in the output buffer.
>>>
>>>> // now, is this queue generic or does it know how many filters
>>>> // it has and what is the sequence of types it processes?
>>>
>>> The queue is generic, and can be changed during the program 
>>> execution. It can contain any number of filters.
>>>
>>> If it was static, I would not have this problem.
>>>
>>>> struct FilterQueue
>>>> {
>>>>     typedef std::list<Filter*> list;
>>>>     typedef list::iterator iterator;
>>>>
>>>>     list filters;
>>>>
>>>>     void append(Filter* pf) { filters.push_back(pf); }
>>>>
>>>>     void createBuffers(???) {
>>>>         // the filters are added in 'append', here we need to add
>>>>         // all the buffers between the filters
>>>>
>>>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>>>         {
>>>>            // it would seem that the buffers have to be *ALSO*
>>>>            // storable in some kind of container, no?  Otherwise
>>>>            // how do you move from 'createBuffers' to 'process'?
>>>>         }
>>>>     }
>>>>
>>>>     void process(???) {
>>>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>>>             it->process(??,??);
>>>>     }
>>>> };
>>>>
>>>> I can only see more questions that haven't yet been answered.  Do 
>>>> you have any answers?
>>>
>>> There are actually two classes:
>>>
>>> class BufferQueue
>>> {
>>>   typedef std::list<Filter*> list;
>>                       ^^^^^^
>> Really?
>>
> 
> Typo. Should have been Buffer*

So, what's a Buffer?  Below you say it's a template.  It can't be a 
template if you are going to put it in a common BufferQueue.  Or is it 
not a common BufferQueue, but itself a template?  Then you can't pass a 
reference to it to a single function in FilterQueue either...

> 
>>>   typedef list::iterator iterator;
>>>
>>>   void CreateBuffers( ConfigType & )
>>>   {
>>>     list.push( sourceBuffer);
>>
>> What is 'sourceBuffer'?  What type does it have?  Is it convertible to 
>> 'Filter*'?
>>
> 
> It is not. The source and destination buffers are declared like this:
> class SourceBuffer : public BufferBase< unsigned short >;
> class DestinationBuffer : public BufferBase< unsigned char >;
> 
> 
>>>
>>>     // create all intermediate buffers
>>>
>>>     list.push( destBuffer);
>>>   }
>>>
>>>   list buffers;
>>> };
>>>
> 
> Actually, since I got 3 base types (BufferBase is a template), there 
> should be 3 queues for each buffer type.

I am not sure I understand.  3 base types : BufferBase<unsigned char>, 
BufferBase<unsigned short>, BufferBase<unsigned long>?  Or something 
else?  So, do you have 3 queues which are also instantiations of some 
class template?  Consider spelling it out, don't expect me to pull it 
out of you with pliers.

> The idea is to have dump Buffer classes, which holds array as 
> intermediate data points, and to use Filter classes to transfer and 
> transform data from one point to another (from the source to the 
> destination/sink)
> 
>>> struct FilterQueue
>>> {
>>>     typedef std::list<Filter*> list;
>>>     typedef list::iterator iterator;
>>>
>>>     list filters;
>>>
>>>   void CreateFilters( ConfigType &, BufferQueue & )
>>>   {
>>>     // read configuration
>>>     // create filters (types are defined in the configuration)
>>>     // connect buffers to each filter
>>>   }
>>>
>>>
>>>     void process() {
>>>         for (iterator it = filters.begin(); it != filters.end; ++it)
>>>             it->process();
>>>     }
>>> };
>>
>> Seems like you got a few things to figure out, still.
> 
> Looked simple and straight-forward on the paper :/

Start writing code.  And start from the *use* of your classes, so you 
can figure out the interfaces.  Then try declaring the interfaces. 
Forget about linking, try making it compile.  Then add implementations 
to some of your interfaces.

It's an iterative process.  It looks very clean and straightforward in 
one's head, sometimes on paper, but as soon as you try coding it, the 
cleanliness and straightforwardness is usually gone (at least 
temporarily until you figure it all out).

I recommend trying to get as much done as you can and repost when you 
have more questions.  Post real compilable (or almost compilable) code 
at that time.

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