U++ framework
Do not panic. Ask here before giving up.

Home » Community » U++ community news and announcements » New graph packages
New graph packages [message #35124] Sun, 15 January 2012 09:45 Go to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello all

There are four new packages in Sandbox to draw Scatter and series graphs in general. They are:
- ScatterDraw: Basic class
- ScatterDraw_demo: Demo of headless drawing for console applications.
- ScatterCtrl: Control
- ScatterCtrl_demo: Different series graph demos.

They combine ScatterCtrl and PlotCtrl/PlotLib features, plus some additional things, like they admit:
- Any kind of data sources through DataSource class
- User defined graph and mark functions

Please test them hard. They are intended to be included in main U++ Smile.


Best regards
Iñaki
Re: New graph packages [message #35142 is a reply to message #35124] Mon, 16 January 2012 22:22 Go to previous messageGo to next message
BioBytes is currently offline  BioBytes
Messages: 312
Registered: October 2008
Location: France
Senior Member
Hi Koldo,

Does it mean that bar or stacked bar graphs will be available as in wxFreeChart library?

Kind regards
Biobytes
Re: New graph packages [message #35144 is a reply to message #35142] Mon, 16 January 2012 23:24 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello BioBytes

ScatterDraw package is rather flexible so it can admit many possible new graphs.

If a new graph makes sense for you, just do it or ask for it Smile.

The sooner the better, because now the programming interface is opened in the case a new graph would require to modify it.

And if you know a better simpler way to describe a new graph, just describe it.


Best regards
Iñaki
Re: New graph packages [message #35192 is a reply to message #35144] Sat, 21 January 2012 12:18 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

this sounds great but unfortunently, you're test project compiles OK but does not execute: the static part gives a X11 error
==4445== Invalid read of size 4
==4445==    at 0x69EB1B6: XInternAtom (in /usr/lib/libX11.so.6.3.0)
==4445==    by 0x8191FDB: Upp::XAtomRaw(char const*) (X11App.cpp:15)
==4445==    by 0x81920EA: Upp::XAtom(char const*) (X11App.cpp:26)
==4445==    by 0x8187B92: Upp::Ctrl::IsCompositedGui() (X11Wnd.cpp:662)
==4445==    by 0x8167695: Upp::Ctrl::Ctrl() (Ctrl.cpp:560)
==4445==    by 0x80A3DD4: Upp::ParentCtrl::ParentCtrl() (Static.cpp:202)
==4445==    by 0x80532DE: ScatterDemo::ScatterDemo() (ScatterCtrl_Demo.h:16)
==4445==    by 0x80607C4: WithTab10<ScatterDemo>::WithTab10() (ScatterCtrl_Demo.lay:62)
==4445==    by 0x806089C: Tab10::Tab10() (ScatterCtrl_Demo.h:153)
==4445==    by 0x806001F: s__s69_fn() (tab10.cpp:70)
==4445==    by 0x805223C: Upp::Callinit::Callinit(void (*)(), char const*, int) (Defs.h:169)
==4445==    by 0x806014D: __static_initialization_and_destruction_0(int, int) (tab10.cpp:69)
==4445==  Address 0x4d0 is not stack'd, malloc'd or (recently) free'd


I am under linux with gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)

I have full Upp up to date and Ide freshly compiled

I'm looking into it

Didier
Re: New graph packages [message #35198 is a reply to message #35192] Sat, 21 January 2012 21:29 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

I understand. The problem is that I constructed a Ctrl inside an INITBLOCK()...

Now inside the INITBLOCK() there will be only a function call Smile.


Best regards
Iñaki
Re: New graph packages [message #35201 is a reply to message #35198] Sat, 21 January 2012 23:27 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Solved.

Best regards
Iñaki
Re: New graph packages [message #35206 is a reply to message #35201] Sun, 22 January 2012 11:21 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

Thank's !

Looking at the recent posts, I new it was something like that.

Dideir
Re: New graph packages [message #35216 is a reply to message #35206] Mon, 23 January 2012 09:39 Go to previous messageGo to next message
ratah is currently offline  ratah
Messages: 107
Registered: July 2010
Experienced Member
Hello Koldo,

I'd like to try the new graph packages but I don't have access to the last nightly built u++ (windows version).
The last one in http://code.google.com/p/upp-mirror/downloads/list is 6 days old.

Best regards,

Ratah

[Updated on: Mon, 23 January 2012 09:39]

Report message to a moderator

Re: New graph packages [message #35221 is a reply to message #35216] Mon, 23 January 2012 19:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Demo looks good.

In Basic Test, there are two strange issues: In non-antialiased mode, bottom x line is missing. And there is quite big color difference between Draw and Painter - but perhaps it is because with Painter, there is some form of Color mixing? (I have not studied the code yet..)
Re: New graph packages [message #35222 is a reply to message #35221] Mon, 23 January 2012 19:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
I have fixed some GCC4.5 warnings, except:

/home/cxl/sandbox/ScatterDraw/ScatterDraw.cpp:1028:9: warning: variable ‘start’ set but not used [-Wunused-but-set-variable]

perhaps you might want to check the code.

Note: the main change was moving most of member initializations to the constructor body - the reason is that GCC complains a lot if the order of these initializations differs from the order of declarations in class.
Re: New graph packages [message #35225 is a reply to message #35222] Mon, 23 January 2012 22:38 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Mirek

Thank you for the fixes Smile. I have fixed the "start" warning too. I do not know why the initializations order is so important for GCC... Anyway soon I expect to have an efficient Linux with GCC 4.6. Now I have a good Ubuntu 10.04 but the latest goes through VirtualBox and it works terribly slow.

Quote:

In Basic Test, there are two strange issues: In non-antialiased mode, bottom x line is missing. And there is quite big color difference between Draw and Painter - but perhaps it is because with Painter, there is some form of Color mixing? (I have not studied the code yet..)


In non-antialiased mode also texts almost disappear. I am not sure if I am doing it right to get the best quality. I move 0.5 in X and Y to get nice thin lines in integer positions.

About color background, the explanation is easy: ScatterDraw supports opacity but... with the ScatterDraw background. Painter manages opacity of all overlapping items, but ScatterDraw Draw version only handles opacity with Ctrl background. Look that the blue background looks the same for all versions.

index.php?t=getfile&id=3617&private=0

In addition line opacity was removed as it was a problem to handle the opacity of the line with its own background.
  • Attachment: dib.PNG
    (Size: 31.38KB, Downloaded 1692 times)


Best regards
Iñaki

[Updated on: Tue, 24 January 2012 08:45] by Moderator

Report message to a moderator

Re: New graph packages [message #35230 is a reply to message #35124] Tue, 24 January 2012 08:48 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Quote:

I do not know why the initializations order is so important for GCC...


IIRC according to C++ standard definition the order of init is either implementation specific or as-defined.
So the order you write inits in the source is not used, and in case some of your init is order depended, this may lead to bugs which are quite difficult to find.

As long as you write the initializers in the as-defined order, you can see such mistake "visually" in case you use some of the variables before it is initialized on the later position.
Re: New graph packages [message #35343 is a reply to message #35230] Fri, 03 February 2012 18:22 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

There is a small bug in ScatterCtrl (also present in Scatter):
When 'SetMajorUnitsNum(xx,yy);' is not called, the ctrl can freeze in very very long loop while truing to adjust y2 unit.

If you add
SetMajorUnitsNum(10,10);
in the constructor of 'ScatterDraw', this bug is prevented.

NB: I am currently trying to enhance grid recalculation according to zoom, so that the grid does not end up filling the whole paint zone when zooming out real far !
I intend to use the same adjustement technique than the one used in PlotCtrl
Re: New graph packages [message #35345 is a reply to message #35343] Fri, 03 February 2012 19:53 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Ok. Added.

Quote:

NB: I am currently trying to enhance grid recalculation according to zoom, so that the grid does not end up filling the whole paint zone when zooming out real far !
I intend to use the same adjustment technique than the one used in PlotCtrl
Perfect, although be careful of avoiding to paint lines that go to points outside viewed window.


Best regards
Iñaki
Re: New graph packages [message #35346 is a reply to message #35345] Sat, 04 February 2012 00:11 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Also do not forget that SetSequentialX() only paints visible zoom.


Best regards
Iñaki
Re: New graph packages [message #35456 is a reply to message #35346] Sat, 18 February 2012 21:15 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier, Honza and all

Any new comments?.

Please include (Didier) your proposal of new functions, changed function names.



Best regards
Iñaki
Re: New graph packages [message #35458 is a reply to message #35456] Sun, 19 February 2012 13:30 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

I've just comme back from vacation and I'm gonna go back to my modifications.

Il post them when finished

Re: New graph packages [message #35601 is a reply to message #35458] Sat, 03 March 2012 21:56 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello all

After a month and a half after including new graph packages I will do the next steps:

- Review coding style to be more like standard U++
- Extract DataSource to a new parallel package
- Include the documentation

If you have proposals specially if they affect the external interface, please post them ASAP.

Mirek: In addition if there is anything that you do not like from these packages or you have any proposal please post it ASAP too.


Best regards
Iñaki
Re: New graph packages [message #35603 is a reply to message #35601] Sun, 04 March 2012 13:48 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

I think DataSource used in ScatterDraw should go template:

The only reason for this is to enable high performance if needed:
class DataSource {
public:
	typedef double (DataSource::*Getdatafun)(int id);

	DataSource() : isParam(false) {}
	virtual ~DataSource() {};	
	virtual double z(int id) 	{return Null;};
	virtual double y(int id) 	{return Null;};
	virtual double x(int id) 	{return Null;};
	virtual int GetCount()		{return Null;};
	bool IsParam()				{return isParam;};

	virtual double MinX() {return Min(&DataSource::x);}	
	virtual double MinY() {return Min(&DataSource::y);}	
	virtual double MinZ() {return Min(&DataSource::z);}	

	virtual double MaxX() {return Max(&DataSource::x);}				
	virtual double MaxY() {return Max(&DataSource::y);}	
	virtual double MaxZ() {return Max(&DataSource::z);}	

	virtual double AvgX() {return Avg(&DataSource::x);}	
	virtual double AvgY() {return Avg(&DataSource::y);}					
	virtual double AvgZ() {return Avg(&DataSource::z);}	


Class DataSource is a pure virtual class
==> so all method calls need to go by the virtual table ==> poor performance
This is specially true for the x,y,z methods which get called for each point drawn.

If Scatter Draw had was defined the following way:
template<class DATASOURCE = DataSource>
class ScatterDraw {
public:
...


The following high performance trivial class could be used intead:
template<int NBPOINTS>
class DataSource {
private:
	double _x[NBPOINTS];
	double _y[NBPOINTS];
	double _z[NBPOINTS];
public:

DataSource() {}
inline double z(int id) 	{return _x[id];}
inline double y(int id) 	{return _y[id];}
inline double x(int id) 	{return _z[id];}
inline int GetCount()		{return NBPOINTS;}
inline bool IsParam()		{return false;}

inline double MinX() {return ....;}	
inline double MinY() {return ....;}	
inline double MinZ() {return ....;}	

inline double MaxX() {return ....;}				
inline double MaxY() {return ....;}	
inline double MaxZ() {return ....;}	

inline double AvgX() {return ....;}	
inline double AvgY() {return ....;}					
inline double AvgZ() {return ....;}	
};


The backdraw to this is that most of ScatterDraw should go in the header
But after all that is not such a big issue.

NB: I know that most of the performance is due to drawing speed but all enhancements are welcome I think

What do you think ?

[Updated on: Sun, 04 March 2012 14:42]

Report message to a moderator

Re: New graph packages [message #35604 is a reply to message #35603] Sun, 04 March 2012 15:05 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Sorry. I do not understand you well Smile. DataSource class do not keep any data. It is just an interface to other classes.

About going template I did a first try... unsuccessful. If you feel you can get it and it is an advantage, and you can help, it would be great.


Best regards
Iñaki
Re: New graph packages [message #35610 is a reply to message #35604] Mon, 05 March 2012 22:33 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

As a matter fact it is exactly what I am doing.

I tried to modify ScatterCtrl but understanding everything took me to much time since there aren't any comments.

So I decided to create a new Graph package that uses the maximum of what you did (DataSource class fo example) but fills the areas which I feel need to be gapped.

Things are taking form so I'll publish wehn finished (quickly I hope ).

Re: New graph packages [message #35615 is a reply to message #35610] Tue, 06 March 2012 20:37 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Quote:

I tried to modify ScatterCtrl but understanding everything took me to much time since there aren't any comments.

I understand you. If you have followed my posts about Scatter you will see that I have tried to avoid modifying original code and style as much as possible. However if you see my previous post, you will see this first point:
Quote:

After a month and a half after including new graph packages I will do the next steps:

- Review coding style to be more like standard U++

So if main ScatterCtrl/ScatterDraw users agree with interface, I would ask you to wait until I can review the code to do it more legible. Could you wait a little bit? Smile.

Please do not do a new graph package. First was Andrei-Catalin, then I added new things, after that dolk.rce did a new package... many efforts for only one package, and there are many new packages to do... Smile



Best regards
Iñaki
Re: New graph packages [message #35616 is a reply to message #35615] Tue, 06 March 2012 21:17 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

Quote:

First was Andrei-Catalin, then I added new things, after that dolk.rce did a new package... many efforts for only one package, and there are many new packages to do...


I really need a good Graph ctrl and neither PlotCtrl nor ScatterCtrl fit my needs (which are quite simple) Crying or Very Sad .

My goal is not to make yet another Graph Ctrl but to use the maximum of what you created and only rebuilding what needs to.

In fact all the formulas are very complicated (to much) and it's very difficult and tricky to enhance it.

I am focusing on the following points:

  • Axis management : drawing/steps management/min-max mondification
  • Calculation simplification
  • Axis/title/legend position : make all these items modifiable


I dont need to rebuild data painting, the one you build is fine and configurable Smile

So I hope I can comme up with something that can easily be merged with ScatterCtrl

Anyway, even if it finally goes to trash, it's the first time I try to build a Ctrl from scratch, so I will learn many things Wink

[Updated on: Tue, 06 March 2012 22:06]

Report message to a moderator

Re: New graph packages [message #35617 is a reply to message #35616] Tue, 06 March 2012 23:40 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Quote:

.. and neither PlotCtrl nor ScatterCtrl fit my needs (which are quite simple).

We would be glad to implement what you need. Just describe it or put some samples or screenshots about it.

Quote:

So I hope I can come up with something that can easily be merged with ScatterCtrl.

Of course any additions and proposals are very Smile acknowledged. Meanwhile from your point of view could we follow with the proposals as I included them in previous post?:
Quote:

- Review coding style to be more like standard U++
- Extract DataSource to a new parallel package
- Include the documentation


There are some new things I would like add to these packages. However I would like to know before if you want anything to change, mainly in the public methods. This way the classes could be used immediatelly.


Best regards
Iñaki
Re: New graph packages [message #35619 is a reply to message #35616] Wed, 07 March 2012 08:02 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Didier wrote on Tue, 06 March 2012 15:17


So I hope I can comme up with something that can easily be merged with ScatterCtrl

Anyway, even if it finally goes to trash, it's the first time I try to build a Ctrl from scratch, so I will learn many things Wink


Well, creating Ctrl from scratch certainly has its educational value.

Long term, I wish there was only one graphing package, which should evolve from current ScatterCtrl. So let us hope your code will be easy to merge Smile

Meanwhile, if you want your code public, please commit it to sandbox (not bazaar).

Mirek
Re: New graph packages [message #35622 is a reply to message #35619] Wed, 07 March 2012 09:18 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Mirek

Quote:

...which should evolve from current ScatterCtrl

Where should evolve ScatterCtrl?. Now it is in a "limbo"...


Best regards
Iñaki

[Updated on: Wed, 07 March 2012 09:20]

Report message to a moderator

Re: New graph packages [message #35623 is a reply to message #35622] Wed, 07 March 2012 09:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
koldo wrote on Wed, 07 March 2012 03:18

Hello Mirek

Quote:

...which should evolve from current ScatterCtrl

Where should evolve ScatterCtrl?. Now it is in a "limbo"...


Sense we are adopting it soon to upp.src... I wanted to make one more pass through it before that, but maybe even that is not necessarry. That said, I might need it in my production code, so perhaps will happen anyway. And after that, I it is not dead code, so it will evolve more Smile
Re: New graph packages [message #35628 is a reply to message #35623] Wed, 07 March 2012 22:24 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Quote:

Well, creating Ctrl from scratch certainly has its educational value.


Mainly for fun Razz

Quote:

Long term, I wish there was only one graphing package, which should evolve from current ScatterCtrl. So let us hope your code will be easy to merge Smile


Several parts of ScatterCtrl can be separated (which I did for needs):

  • SeriesPlot
  • MarkPlot
  • DrawingFunctions
  • DataSource

I will use them "as is" if possible
So if Koldo can do a clean Separation of these parts from the ScatterCtrl merge could be trivial

Currently I have introduced a GridAxisDraw class that draws the axis and also Grid. The main point is to make grid/axis look extendable and also make grid steps extendable (through class derivation). For ex: maybe I need the steps have certain periodicity or for log a different representation.
This class also contributes to the coordinate conversion ==> this way we could click on the axis, modify ranges/scale ==> and grid/points tied to this axis (and only these points get rescaled)
NB: the coordinate conversion is not owned by this class, another helper class is in charge of this.

Quote:


Meanwhile, if you want your code public, please commit it to sandbox (not bazaar).


When I have something that I find "publishable" I will do it.

[Updated on: Wed, 07 March 2012 22:26]

Report message to a moderator

Re: New graph packages [message #35632 is a reply to message #35628] Thu, 08 March 2012 12:57 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

I have begun clarifying (not simplifying) a little bit the mathematics and changing names of some confusing variables (like "l" and "h"). In addition now there will be different left/right and top/bottom margins.

As it is useful for you I will separate in different files, classes:
- SeriesPlot
- MarkPlot
- DrawingFunctions

And DataSource in a different package.

In addition I will try to separate in different classes:
- GridAxisDraw including grid texts
- LegendDraw for graph legends (following PlotCtrl suggestion)

This way Scatter classes will be even more flexible...


Best regards
Iñaki
icon14.gif  Re: New graph packages [message #35644 is a reply to message #35632] Fri, 09 March 2012 15:17 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hi Koldo,

Quote:

As it is useful for you I will separate in different files, classes:
- SeriesPlot
- MarkPlot
- DrawingFunctions
You're class separation fit perfectly with my code Smile

Except for one thing:
	static Color GetNewColor(int id);
	static String GetNewDash(int id);
	static MarkPlot *GetNewMarkPlot(int id);

These methods need to go public.


Looking closer at the SeriesPlot and MarkPlot classes, I think
it could be a good idea to add a
virtual void SetScale(int  scale) {}
method in SeriesPlot and MarkPlot classes.
This would enable children classes to have premultiplied values if needed.

This could be very useful to speed up the of drawing complex marks or line styles since 'SetScale()' would get called only once per drawn series (and not for each point drawn).

Re: New graph packages [message #35652 is a reply to message #35644] Fri, 09 March 2012 23:27 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Koldo,

I needed to separate another part to make it common: the one that manages the series list.

To do that, I used CRTP (Curiously Recurring Template Pattern) and added a SeriesGroupClass.

I extracted only the common parts, all specif methods like :
  • SetDataPrimaryY()
  • SetSequentialX()
  • ...
were left in ScatterDraw.

I modified ScatterCtrl svn:4671 (see attached file)
==> all works fine in ScatterCtrl_demo.

With this I have exactly the same interface for:
  • data managing
  • line style plot
  • mark style plot


NB: I also had to do some other minor changes:
Color GetNewColor(int id);
String GetNewDash(int id);
MarkPlot *GetNewMarkPlot(int id);
were moved to DrawingFuntions
and
Scatter::Refresh()
was made public

Do you agree to take these changes in account ? Rolling Eyes

I think all common parts ( at least in version 4671 ) are axtracted...



Re: New graph packages [message #35662 is a reply to message #35652] Sun, 11 March 2012 18:16 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

I have tried to understand your changes unsuccessfully. It is difficult for me to follow the changes in the files.

This functions:
Color GetNewColor(int id);
String GetNewDash(int id);
MarkPlot *GetNewMarkPlot(int id);

are already protected because they are only used in ScatterDraw classes and subclasses, so apparently they do not need to be out.

About SetScale(), AFAIK I see all drawing functions get scale only once per drawn series.

It is very interesting to have exactly the same interface for:
  • data managing
  • line style plot
  • mark style plot

Please include a proposal of the declarations of this functions.

Refresh() is now public.


Best regards
Iñaki
Re: New graph packages [message #35667 is a reply to message #35662] Sun, 11 March 2012 19:50 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hello Koldo,

Quote:

I have tried to understand your changes unsuccessfully. It is difficult for me to follow the changes in the files.

The changes I made are not functionnal modifications.
The idea is to move the common code from class A to a new template class: B.
The original class (A) then inherits from B: class a : public B {};
==> Class A therefore ahs the same methods as before, except for one (big) difference:
The return type of the methods : B::x() can only be of type B and not A Confused
Usually in Upp method calls are chained: we write : x0().x1().x2()

So if I do
class a : public B {};
==> the method chaining is then broken Crying or Very Sad

To prevent this, we can use CRTP in order to have correct return types
CRTP


Better than long text here is an example:
-------------------- Case 1 : the original code
class OriginalClass {
	public:
	OriginalClass() {}
	OriginalClass& fctA() { .....; return *this; }
	OriginalClass& fctD() { .....; return *this; }
};


we can write :
OriginalClass inst;
isnt.fctA().fctB();
but all is contained in 1 class Confused


-------------------- Case 2 : naive separation (does not work)
class BaseClass {
	public:
	BaseClass() {}
	BaseClass& fctA() { .....; return *this; }
};
class DerivedClass : public  BaseClass {
	public:
	DerivedClass() {}
	DerivedClass& fctD() { return *this; }
};

==> we ##CAN NOT## write :
DerivedClass inst;
isnt.fctA().fctB();    ==> compilation error
Crying or Very Sad

-------------------- Case 3 : separation using CRTP
template<class DERIVED>
class BaseClass {
	public:
	BaseClass() {}
	DERIVED& fctA() { return *static_cast<DERIVED*>(this); }
};
class DerivedClass : public  BaseClass<DerivedClass> {
	public:
	DerivedClass() {}
	DerivedClass& fctD() { return *this; }
};


==> We CAN write :
DerivedClass inst;
isnt.fctA().fctB();
==> ScatterCtrl still works
and separation has been made Cool Cool Cool ==> I can reuse it !!!

So please reconsider Uh Oh these changes since I only MOVED code and NOT CHANGED code.

[Updated on: Sun, 11 March 2012 19:55]

Report message to a moderator

Re: New graph packages [message #35670 is a reply to message #35667] Sun, 11 March 2012 21:17 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Sorry, I thought CRTP was a kind of joke instead of a "curiously recurring template pattern" Smile.

A drawback of increasing the degree of class templating is that classes are getting more complex without adding functionality. I think we do not have to forget that.

I will try it again...


Best regards
Iñaki
Re: New graph packages [message #35671 is a reply to message #35670] Sun, 11 March 2012 22:22 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 740
Registered: November 2008
Location: France
Contributor
Hello Koldo,

Quote:

A drawback of increasing the degree of class templating is that classes are getting more complex without adding functionality. I think we do not have to forget that.
Yes I know, but without this, I can't take advantage of you're code, and interface will probably diverge Crying or Very Sad Crying or Very Sad

But if it's really a problem I'll just copy it for now.

[Updated on: Sun, 11 March 2012 22:23]

Report message to a moderator

Re: New graph packages [message #35672 is a reply to message #35662] Sun, 11 March 2012 22:42 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1796
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Hi Koldo
koldo wrote on Sun, 11 March 2012 18:16

This functions:
Color GetNewColor(int id);
String GetNewDash(int id);
MarkPlot *GetNewMarkPlot(int id);

are already protected because they are only used in ScatterDraw classes and subclasses, so apparently they do not need to be out.

Simple usecase where having these methods publicly available would be very helpful:

If there is multiple series, I would call GetNewColor(my_series_id) to assign color after each ordering change (where my_series_id is some unique identification of the series that doesn't depend on it's position in graph). The goal is to keep the colors the same even when some series are removed, added or sorted differently. It helps to keep the graphs easily "readable" Wink

The same holds for GetNewDash and for GetNew_MarkPlot... Please consider making them publicly available, all it will cost you is three declarations in header file Wink

Best regards,
Honza
Re: New graph packages [message #35675 is a reply to message #35671] Mon, 12 March 2012 09:10 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Hello Didier

Yes I know, but without this, I can't take advantage of you're code, and interface will probably diverge
It is difficult to optimize a class to match to something only you knows.

It would be better if you would make public your needs to see how to match code with them.


Best regards
Iñaki
Re: New graph packages [message #35676 is a reply to message #35672] Mon, 12 March 2012 09:12 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
dolik.rce wrote on Sun, 11 March 2012 22:42

Hi Koldo
koldo wrote on Sun, 11 March 2012 18:16

This functions:
Color GetNewColor(int id);
String GetNewDash(int id);
MarkPlot *GetNewMarkPlot(int id);

are already protected because they are only used in ScatterDraw classes and subclasses, so apparently they do not need to be out.

Simple usecase where having these methods publicly available would be very helpful:

If there is multiple series, I would call GetNewColor(my_series_id) to assign color after each ordering change (where my_series_id is some unique identification of the series that doesn't depend on it's position in graph). The goal is to keep the colors the same even when some series are removed, added or sorted differently. It helps to keep the graphs easily "readable" Wink

The same holds for GetNewDash and for GetNew_MarkPlot... Please consider making them publicly available, all it will cost you is three declarations in header file Wink

Best regards,
Honza


Hello Honza

Is perhaps the solution to add some kind of graph KEY or ID as in GridCtrl?


Best regards
Iñaki
Re: New graph packages [message #35678 is a reply to message #35676] Mon, 12 March 2012 10:45 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1796
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

koldo wrote on Mon, 12 March 2012 09:12

dolik.rce wrote on Sun, 11 March 2012 22:42

Hi Koldo
koldo wrote on Sun, 11 March 2012 18:16

This functions:
Color GetNewColor(int id);
String GetNewDash(int id);
MarkPlot *GetNewMarkPlot(int id);

are already protected because they are only used in ScatterDraw classes and subclasses, so apparently they do not need to be out.

Simple usecase where having these methods publicly available would be very helpful:

If there is multiple series, I would call GetNewColor(my_series_id) to assign color after each ordering change (where my_series_id is some unique identification of the series that doesn't depend on it's position in graph). The goal is to keep the colors the same even when some series are removed, added or sorted differently. It helps to keep the graphs easily "readable" Wink

The same holds for GetNewDash and for GetNew_MarkPlot... Please consider making them publicly available, all it will cost you is three declarations in header file Wink

Best regards,
Honza


Hello Honza

Is perhaps the solution to add some kind of graph KEY or ID as in GridCtrl?


Yes, that would solve the situation from the other side Smile It seems little bit more difficult to implement this way, but possibly more versatile.

Honza
Re: New graph packages [message #35680 is a reply to message #35678] Mon, 12 March 2012 12:16 Go to previous messageGo to previous message
koldo is currently offline  koldo
Messages: 3458
Registered: August 2008
Senior Veteran
Quote:

Yes, that would solve the situation from the other side Smile It seems little bit more difficult to implement this way, but possibly more versatile.
Hello Honza

What interface do you propose?. I mean, how would you change AddSeries() functions and other?


Best regards
Iñaki
Previous Topic: New pick/clone notation now merged into trunk
Next Topic: Testing of migrated and upgraded forum
Goto Forum:
  


Current Time: Sat Apr 25 18:48:16 GMT+2 2026

Total time taken to generate the page: 0.01239 seconds