https://www.codeproject.com/Articles/5280535/Some-Shocking-F acts-You-Probably-Didnt-Want-to-Kno

Quote:

https://www.codeproject.com/Articles/5280535/Some-Shocking-F acts-You-Probably-Didnt-Want-to-Kno

As usual, well written and very informative!

If only I'd had read this 10 years ago...

Best regards,
Oblivion

that going from Vector to Array is mostly the act of rewriting "Vector" to "Array"

Hi Mirek!

Thanks!! Great article!

Although I started learning U++ 2006, I'm still learning... : An Array can actually hold objects of inherited classes! This was interesting and very useful for my needs. However, I could not figure out how to make serialization/deserialization of this work correctly. Here's my failed test of that:

using namespace Upp;
class A{
public:
	int	a;
	A(){
		a=1;
		Cout() << "A+\n";
	}
	
virtual	~A(){
		Cout() << "A-\n";
	}
	
virtual void Serialize(Stream &s){
		s % a;
	}
	
virtual void Print(){
		Cout() << "A: " << a << "\n";
	}
};

class B: public A{
public:
	int	b;
	B(){
		b=2;
		Cout() << "B+\n";
	}
	
	~B(){
		Cout() << "B-\n";
	}

virtual void Serialize(Stream &s){
		A::Serialize(s);
		s % b;
	}

virtual void Print(){
		Cout() << "B: " << a << ", " << b << "\n";
	}
};


CONSOLE_APP_MAIN{
	Array<A> v;
	
	v.Create<A>();
	v.Create<B>();
	v.Create<B>();
	v.Create<A>();
	
	Cout() << "Printing array...\n";
	for(int i=0;i<v.GetCount();i++) v[i].Print();

	Cout() << "Storing to file...\n";
	StoreToFile(v,GetHomeDirFile("Test.bin"));
	Cout() << "Clearing...\n";

	v.Clear();

	Cout() << "Loading from file...\n";
	LoadFromFile(v,GetHomeDirFile("Test.bin"));
	Cout() << "Loaded from file...\n";
	
	Cout() << "Printing array...\n";
	for(int i=0;i<v.GetCount();i++) v[i].Print();
}

What is the correct way to do this?

Seriously, you cannot... Sorry that I might have created that impression.

I mean, you definitely can solve this, but not with out-of-box Array::Serialize. You need to provide your own serialization there and store the type on saving, load on loading.

In reality, this is not needed very often...

Mirek

Hello,
Mire do you think about simplifying title - for me it seems too long. What about:

Hello Mirek,

I see that your comment on the reddit caused controversy We collected a lot of valuable data. From my point of view - the three main causes why they do not want to use our technology are:
- impossible to write in other IDE's than TheIDE.
- not easy to integrate with other build systems. If I want to add GUI part for existing code (front-end) with U++, this is not possible. Everything needs to be integrated with ecosystem. I know that many people like to work with CMake as a build system, so why not let them work with Upp
- custom allocator is not selling point - we should sell it that our GUI is super responsive thanks to that Anyway, we should think about it and what we would like to do with that.

In my opinion we should focus on U++ as library (only core libraries Console + GUI) and provide it as collection of .so and .dlls. Thanks to that our libraries can be integrated with other build system easily. In this case we should do not bundle allocator - it can works within library, but externally it should be hidden. So, all binaries linking to upp libraries should be in USEMALLOCK mode.

I am thinking about creating tool called udeploy that will compile selected uppsrc libraries and produce folder with shared libraries (.dlls) and headers. udeploy tool should copy headers from packages. In Upp not as a platform mode we should have includes like this:

#include <Upp/CtrlLib/CtrlLib.h>

With the change described above we should get out of the niche, however the investment in this case is huge. This will also allow Upp to be used in bigger projects.

Should, we do something with aggressive keyword in README.md? I see that there are some remarks about it.

Klugier

Hello Mirek,

- custom allocator is not selling point - we should sell it that our GUI is super responsive thanks to that Anyway, we should think about it and what we would like to do with that.

In my opinion we should focus on U++ as library (only core libraries Console + GUI) and provide it as collection of .so and .dlls. Thanks to that our libraries can be integrated with other build system easily. In this case we should do not bundle allocator - it can works within library, but externally it should be hidden. So, all binaries linking to upp libraries should be in USEMALLOCK mode.

Hello Mirek,

Thanks that you gave the green light for upp as a library.

I think we could target it in the next year - this will be massive rework. The main problem is that for dll you need to explicitly said which symbols should be exported...

Backing to allocator - thanks for the clarification. I had to understand something wrongly from the discussion. I think it was UB

Hello Mirek,
Thanks that you gave the green light for upp as a library. I think we could target it in the next year - this will be massive rework. The main problem is that for dll you need to explicitly said which symbols should be exported... I think we will try to participate in GSoC 2021 with only one idea. This seems to be top priority now. I plan to have short break from U++...