Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » PR, media coverage, articles and documentation » Some Shocking Facts You Probably Didn't Want to Know about U++ Framework...
Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55412] Mon, 09 November 2020 12:29 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
New CodeProject article is now online:

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

If you like it, do not forget to vote!

Mirek
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55414 is a reply to message #55412] Mon, 09 November 2020 16:16 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
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... Laughing

Best regards,
Oblivion


Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55415 is a reply to message #55414] Mon, 09 November 2020 16:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Oblivion wrote on Mon, 09 November 2020 16:16
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... Laughing

Best regards,
Oblivion


If only I'd had written this 10 years ago... Smile

Mirek
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55417 is a reply to message #55412] Mon, 09 November 2020 17:24 Go to previous messageGo to next message
Xemuth is currently offline  Xemuth
Messages: 387
Registered: August 2018
Location: France
Senior Member
Hello Mirek,

Thanks for this article, I learned so many things (and of course gived it 5 stars !)

Finally, I who have worked a lot with very little or not typed languages ​​(e.g. javascript / vba) I have the feeling that the U++ vision is very modern. It makes me happy to know that I spent my firsts years in the development on this gem and I'm super excited to read there is still so much to learn about it.

Special mention to :
Quote:
that going from Vector to Array is mostly the act of rewriting "Vector" to "Array"
Oh god, that's so true and appreciable, I dont count the times I swaped from one to another !

About theIDE part : I think (from my humble beginner point of view) you summarized the most interesting features of TheIDE, don't bother anymore with external libs, get the package and it will work !

[Updated on: Mon, 16 November 2020 15:56]

Report message to a moderator

Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55420 is a reply to message #55412] Mon, 09 November 2020 20:46 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
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?

Thanks and best regards,

Tom
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55421 is a reply to message #55417] Mon, 09 November 2020 20:48 Go to previous messageGo to next message
Didier is currently offline  Didier
Messages: 680
Registered: November 2008
Location: France
Contributor
Very Very good article.

It should be directly in U++ documentation as it contains several coding guidelines to work well with U++
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55422 is a reply to message #55421] Mon, 09 November 2020 21:10 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
This has been an unconventional explanation but one that cannot leave indifferent anyone with extensive experience in programming and C++.
Really great job Mirek!


Best regards
Iñaki
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55424 is a reply to message #55420] Mon, 09 November 2020 22:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Mon, 09 November 2020 20:46
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
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55425 is a reply to message #55424] Tue, 10 November 2020 10:03 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Mon, 09 November 2020 23:05

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


Absolutely nothing to apologize.

Actually, I have already worked my way around this by serializing type ID and then object. However, I went the harder way by using Vector<BaseClass*> instead of Array<BaseClass> since, at the time, I did not know about the possibility to store inherited classes in an Array.

Thanks and best regards,

Tom
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55429 is a reply to message #55425] Tue, 10 November 2020 15:24 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello,

I added the link to the article in articles section of Tutorial site. So, you can easily return to it if you forget about this announcment. I would like to thank Mirek for this outstanding job - from the PR point of view it is big thing. I hope I would join - right now I am working to make internal documentation better.

Mire do you think about simplifying title - for me it seems too long. What about:
Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... ->
Shocking Facts You don't Know about U++ Framework...
or even
Shocking Facts about U++ Framework...

Simple and easier to remembered. In the title we should use the same principle as we use in context of our code - KISS.

Klugier


U++ - one framework to rule them all.

[Updated on: Tue, 10 November 2020 15:24]

Report message to a moderator

Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55431 is a reply to message #55429] Tue, 10 November 2020 15:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 10 November 2020 15:24
Hello,
Mire do you think about simplifying title - for me it seems too long. What about:


It is intentional. It could have been "Introduction to U++", but where is fun in that?

Mirek
icon10.gif  Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55440 is a reply to message #55412] Tue, 10 November 2020 22:53 Go to previous messageGo to next message
wimpie is currently offline  wimpie
Messages: 46
Registered: March 2013
Location: holland
Member
Well this put a big smile on my face! And informative in the mean time too Very Happy

And I learned something about myself.. I'm not a real programmer! Laughing (already knew that)

really nice write-up. Keep up the good work!


Regards,

Wimpie


p.s. still laughing about the title Smile

Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55464 is a reply to message #55440] Fri, 13 November 2020 17:23 Go to previous messageGo to next message
jimlef is currently offline  jimlef
Messages: 90
Registered: September 2020
Location: US
Member
Have just received this article in my inbox - and of course 5 stars all the way Smile Congratulations on the great press!
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55489 is a reply to message #55412] Sun, 15 November 2020 09:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I have found

https://www.reddit.com/r/cpp

and tried to post a link there. If you are reddit active, you can consider upvoting...

Mirek
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55502 is a reply to message #55489] Tue, 17 November 2020 00:30 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello Mirek,

I see that your comment on the reddit caused controversy Smile 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 Smile
- custom allocator is not selling point - we should sell it that our GUI is super responsive thanks to that Smile 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


U++ - one framework to rule them all.

[Updated on: Tue, 17 November 2020 00:35]

Report message to a moderator

Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55503 is a reply to message #55502] Tue, 17 November 2020 00:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 17 November 2020 00:30
Hello Mirek,

I see that your comment on the reddit caused controversy Smile 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 Smile
- custom allocator is not selling point - we should sell it that our GUI is super responsive thanks to that Smile 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


Absolutely, that was a flop. udeploy would be great. The article style was wrong idea, posting it on reddit even worse. There is always something to learn... Smile

Mirek
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55504 is a reply to message #55502] Tue, 17 November 2020 00:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 17 November 2020 00:30
Hello Mirek,

- custom allocator is not selling point - we should sell it that our GUI is super responsive thanks to that Smile 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.



U++ allocator was not even mentioned. And in fact, it might be a great idependent piece of code.

As for allocator modes within U++, it is already ready because on MacOS you cannot overload global new/delete. So the library can already be configured in a mode that is using regular new/delete and U++ allocator for internals where possible.

Once again, if somebody would step in and provided regular ecosystem libraries, that would be excellent news. That OTOH does not mean I am going to abandon theide...

Mirek
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55505 is a reply to message #55504] Tue, 17 November 2020 01:09 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
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++...

Before start thinkg of udeploy. I would see that we will create CommandLineArgumentParser class for U++ ecosystem (should be in uppsrc). This will be similar concept to QT Parser or cxxopts. We need to make sure that our connsole apps API looks great. We do not want to have similar problem to this one.

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

Klugier


U++ - one framework to rule them all.

[Updated on: Tue, 17 November 2020 01:32]

Report message to a moderator

Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55506 is a reply to message #55505] Tue, 17 November 2020 10:10 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 17 November 2020 01:09
Hello Mirek,

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


That was always green light. I have even changed important aspects in the past, .icpp is no longer required. I just do not have energy (and mood) to do that myself.

Quote:

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...


Produce static libraries then.... You can also simply export everything, there are methods for that. But I would rather do statics, in the past there was stigma associated with that, but I feel like that is now gone. In any case, it would be a good first step.

The real problem with this is how to destroy U++ modularity... E.g. how will you handle MySQL? SSL?

Quote:

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


No, Moveable is the UB. And probably not for much longer as this kind of UB is "established industry practice" now, Bloomber, Facebook and Electronics Arts template libraries are doing exactly the same thing and there are proposals to make it legal.

Mirek
Re: Some Shocking Facts You Probably Didn't Want to Know about U++ Framework... [message #55509 is a reply to message #55505] Wed, 18 November 2020 12:22 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 17 November 2020 01:09
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++...


I was thinking about it and I believe the whole issue can be simpified immensely by adding a couple of flags to umk!

Simply put, upgrade ide/Builders to be able to produce a .lib file as the end product and we are halfway there, right?

Mirek
Previous Topic: Layout Designer has been documented (TheIDE)
Next Topic: 2nd price!
Goto Forum:
  


Current Time: Thu Mar 28 22:05:20 CET 2024

Total time taken to generate the page: 0.01593 seconds