Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Interfaces maybe?

Status
Not open for further replies.

JianBean

Technical User
Oct 26, 2003
26
US
This is a little complicated but, I'm going to try and explain as best I can... [wink]


I have a program that I'm working on, it has several classes, one main class that controls everything called: 'voidNN' this class uses other classes inside of it called 'voidL', all of which are dynamically created and deleted, through a doubly-linked list. The 'voidL' classes are aware of one-another, and are linked together, again dynamically, with some insignificant values, relevant only to their communication.

That being said, here is my problem: [sad]
I have to have quick access to any 'voidL' object within the 'voidNN' class, so I decided to use pointers, and return these pointers to the user, so that the user can use them to quickly access a particular object, however, the data in the 'voidL' classes is very sensitive, and could have unexpected results if it were tampered with by the user, so I only return "void *" pointers to the user, which I type cast back to 'voidL's.

...still going!...[ponder]

Lastly there are three different types of 'voidL', all of which are similar in all aspects except for one or two added functions. It would be extremely helpful if I could pass some sort of object back to the user as a sort of interface to use to interact with the 'voidL' objects, without having to go through the 'voidNN' object to do so. Is there any type of interface object that I could return, that was slightly different depending on what implementation of the 'voidL' object was being used?


I am sorry if this didn't quite make sense, please post any questions that you have, I'm not entirely sure how to explain it, but I'll try to answer any questions you have![tongue] And thank you in advance for any help!
 
>the data in the 'voidL' classes is very sensitive, and could have unexpected results if it were tampered with by the user

Return 'const voidL*' or 'const voidL&' instead. Then a client can't change the contents (not without casting anyway). If protecting by const isn't enough (though casting away const is pretty much a no-no) then return a copy of voidL rather than a pointer/reference. Slower performance - but the client can abuse the returned voidL at will...

>Lastly there are three different types of 'voidL', all of which are similar in all aspects except for one or two added functions

Let them all inherit a common base class that does all the common stuff.

>I am sorry if this didn't quite make sense

It'd make more sense if you showed the real typenames. voidNN and "there are three different types of 'voidL'" is unneccesarily obfuscating.



/Per

"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."
 
Per-
Thank you very much for your response, maybe this information will help:

I did this from memory last night, the class 'voidNN' is actually 'NN' and 'voidL' is actually 'LAYER'.
I was going off of the filenames, because I thought I used the same naming conventions, sorry!

Here are the definitions, how they currently stand:

Code:
[b]class NN[/b]
{
public:
	NN();
	~NN();

	void * AddNewLayer();
	void DeleteLayer(void * lDelete);
	int GetNumLayers();
	void SetNumNeurons(void * lSet,unsigned int iNNeurons);

	void AddInput(void * lSet,unsigned int iNeur,double dVal);
	void SetInput(void * lSet,unsigned int iNeur,double dVal);
	double GetInput(void * lSet,unsigned int iNeur);
	void SetTarget(void * lSet,unsigned int iNeur,double dVal);
	double GetTarget(void * lSet,unsigned int iNeur);
	double GetOutput(void * lSet,unsigned int iNeur);
	double GetError(void * lSet,unsigned int iNeur);
private:
	int iNumLayers;
	LAYER * lLayers;
};

Code:
[b]class LAYER[/b]
{
public:
	LAYER();
	~LAYER();
	void * GetLastPointer();
	void * GetFirstPointer();
	void DeleteForwardPointers();
	void DeleteBackwardPointers();
	void SetNumNeurons(unsigned int iNN);

	void AddInput(unsigned int iNeur,double dVal);
	void SetInput(unsigned int iNeur,double dVal);
	double GetInput(unsigned int iNeur);
	void SetTarget(unsigned int iNeur,double dVal);
	double GetTarget(unsigned int iNeur);
	double GetOutput(unsigned int iNeur);
	double GetError(unsigned int iNeur);
	
	long iValidation;
	LAYER * lNext;
	LAYER * lPrev;
private:
	unsigned int iNumN;
	double * dNInput;
	double * dNOutput;
	double * dNError;
	double * dNTarget;
	
	LayConn * lcFrom;
	LayConn * lcTo;
};

and this is the 'LAYER' linking structure:
Code:
[b]struct LayConn[/b]
{
	LAYER * lFrom;
	LAYER * lTo;
	unsigned int iNFrom;
	unsigned int iNTo;

	unsigned int iNConn;
	double * dConn;

	LayConn * lcNext;
	LayConn * lcPrev;
};

It's not so much the 'LAYER's I'm worried about, I know how to do the 'LAYER's, they just behave a little differently, depending on where they are organized in 'NN'.
But the 'LAYER' class has three diffent possibilities as follows:
[ul]
[li]INPUT[/li]
[li]HIDDEN[/li]
[li]OUTPUT[/li]
[/ul]


FYI: I have to have the program able to process MANY, MANY calculations/sec (many hundreds of thousands, millions, or even billions, each time would be a bit different), so I have to keep it optimized as much as possible.

I would still like to know if it is possible to return some type of "interface" or something similar that could be used to manipulate the class? Again thank you in advance for your help!
 
>I would still like to know if it is possible to return some type of "interface

Code:
// The Layer interface
class LayerI
{
	// The common methods
	// ...
};

class LayerA : public LayerI
{
	// Some specialized methods
	// ...
};

class LayerB : public LayerI
{
	// Some specialized methods
	// ...
};

class LayerC : public LayerI
{
	// Some specialized methods
	// ...
};

Let the collection store instances of LayerA, LayerB or LayerC and have your queries return LayerI.

A couple of general suggestions:

1) Don't use void* as parameter, use pointer to real type instead. Casting should (and can) be avoided but by using void* you enforce casting.

2) You have a generic and efficient linked list mechanism provided by STL for free, the std:list (see the MSDN docs). No need to reinvent the wheel.




/Per

"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."
 
Thank you very much for your suggestions! Although, I'm not quite sure what you mean by: 'have your queries return LayerI'.
I understand how inheritance works, and that I should use a base class, and build off of it, but not sure what you meant by your comment?

Again, thank you Per, you've been very helpful!
 
> I'm not quite sure what you mean by: 'have your queries return LayerI'.

Code:
class Animal
{
  public:
    virtual ~Animal() {}
    virtual void sound() const = 0;
};

class Cat : public Animal
{
  public:
    void sound() const { cout << "Meow\n"; }
};

class Dog : public Animal
{
  public:
    void sound() const { cout << "Woof\n"; }
};

Animal* cat = new Cat;  // Note cat and dog
Animal* dog = new Dog;  // are Animal*

cat->sound();  // outputs "Meow"
dog->sound();  // outputs "Woof"

Basic polymorphism.

Note the important fact (and kinda the point) that you can manipulate objects that are "really" Cats and Dogs through the generic interface "Animal," and that you can have a list of Animal* that are really pointing to Cats, Dogs, Fish, Crocodiles, and whatnot.
 
> I'm not quite sure what you mean by: 'have your queries return LayerI'.

I think you are :)

Somewhat badly expressed on my part, but you nailed it perfectly.



/Per

&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;
 
Oh, missed that the question was from JianBean.

Anyway, chipperMDW gave a good explanation (as usual).

/Per

&quot;It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure.&quot;
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top