Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CopperSpice, a Modern C++ Fork of Qt

copperspice.com

Post reply on HN
Print view View original

51–60 of 104 posts

Re: CopperSpice, a Modern C++ Fork of Qt

#51

Post by cjslep »

pjmlp wrote: post #33
cjslep wrote: post #10

Qt's Contributor Summit just ended, and one of the topics was C++11 support [0]. The key takeaway is Qt 5.6 will start the move away from C++98 towards C++11 support, though not fully C++11 mainly due to the MSVC compiler's limitations. The joy of being cross-platform. That being said, I don't immediately see the value of using CS over Qt. Binary size alone is not generally worth jumping ship from an established comm…

So will Qt stop supporting commercial UNIX compilers and embedded platforms with compilers still stuck in C++98/03/partial 11?

Embedded system support is very much a high profile concern, and is definitely on Lars Knoll's radar. Given their enthusiasm, I would not start any doomsday rumors.

Re: CopperSpice, a Modern C++ Fork of Qt

#52

Post by sqeaky »

scrollaway wrote: post #3

Why? And why 4.8? The 5.x branch is a far better version of Qt. This looks ridiculous. Qt is a massive framework - the work of hundreds, if not thousands, of people - and this seems to be the work of a random dev with zero backing and a 2004-style website with zero content (everything, even the 14-forum completely empty phpbb forum).

The project is large, but superficially seem to have a reasonable approach and documentation. The website looks fine as a simple communication tool and changelog.

Why attack them for their style and not something substantive?

Re: CopperSpice, a Modern C++ Fork of Qt

#53

Post by zanny »

cpp098 wrote: post #26

great! could you explain in detail why you want to replace MOC: "The redesign allowed us to completely remove the Qt Meta-Object Compiler (moc) system. Moc is a code generator and did not support many aspects of C++ including templates, complex data types, static type checking, and relies heavily on string comparisons. Removing moc improves run time performance, reduces the complexity of the build process, and allows…

Just as someone who uses Qt every day... because its kind of a mess? You already have your compiler preprocessor and the moc is an extra step ahead of that. When the language didn't support templating that made the moc necessary, but nowadays you can do signal / slots the Boost way with templates and without a framework-specific preprocessor to mangle the source files into a string comparison nightmare.

Maybe in the purest sense the fact you cannot just do g++ -o kind of sucks. It just makes the whole build process implicitly complicated, and I haven't manually messed with the moc in five years so I've pretty much forgotten the syntax of baking it into homebrew makefiles.

Re: CopperSpice, a Modern C++ Fork of Qt

#55

Post by zanny »

meir_yanovich wrote: post #2

great work! but i wander .. What is the purpose of this ? is the license is still LGPL ? if yes so ...?

> What is the purpose of this ?

Its a fork of Qt by a guy who wants to see how much cleaner you can make the framework using a modern version of the language, it seems.

Maybe it might be merged back upstream at some point to reduce complexity in the parent project, which would be nice.

Re: CopperSpice, a Modern C++ Fork of Qt

#57

Post by seletz »

jryan49 wrote: post #20
seletz wrote: post #4

Hmm. On a (quick) glance, I can't find: - a license - a repository -- I very much like to browse the code, issues, PRs ... - some tutorials -- I often judge projects by whether or not their tutorials work OOTB Unfortunately, that's how I evaluate tools. It's a big red flag for me if one of these things is missing in new projects -- especially when it's a fork (is it?) of something else. Maybe the author(s) can add th…

Seems to be all here: http://www.copperspice.com/docs/cs_overview/index.html

Duh, OK. My bad.

Re: CopperSpice, a Modern C++ Fork of Qt

#58

Post by Qwertious »

[deleted] wrote: post #46
scrollaway wrote: post #44

Earlier quoted context omitted.

That is a phenomenally ridiculous comparison. They are doing procedural textures/audio etc. RAGE is 20GB because it has a massive amount of high resolution textures, meshes and audio. Nothing to do with the libraries they use.

[deleted]

So, now you need your artists to be programmers.

I don't think you quite understand what you're asking. The number one rule for high-quality aesthetics in games is that you let the ARTISTS call the shots, with someone in-between to tell them when that's a terrible idea technically. This would break that horribly.

And that's ignoring the load times, which increases massively if you have to procedurally generate it. And having decent level design, which I GUARANTEE will not often pop up naturally in procedurally-generated environments. Meanwhile, disk space is pretty damn cheap and will save you a bunch of time and money.

Re: CopperSpice, a Modern C++ Fork of Qt

#59

Post by Qwertious »

purerandomness wrote: post #48
coldtea wrote: post #27

Earlier quoted context omitted.

> It's huge - something like 30 MB for "hello world" on Windows. First, 30MB for "hello world" doesn't mean it will get linearly bigger as code grows. Most is one time off overhead. Else something like Kate would be an 1 TB binary. Second, 30MB hasn't been an issue since 2002. Heck, I have 20+ apps, each over 30MB, on my PHONE.

How large do you think is a "Hello World" app that uses .NET?

Well, considering that anything that uses .Net will by definition have .Net as a dependency, at least the size of .Net.

Re: CopperSpice, a Modern C++ Fork of Qt

#60

Post by CountSessine »

cjslep wrote: post #51
pjmlp wrote: post #33

Earlier quoted context omitted.

So will Qt stop supporting commercial UNIX compilers and embedded platforms with compilers still stuck in C++98/03/partial 11?

Embedded system support is very much a high profile concern, and is definitely on Lars Knoll's radar. Given their enthusiasm, I would not start any doomsday rumors.

Another point to remember is that clang is changing the calculus of C/C++ compiler support in embedded. There are a lot of embedded systems (QNX comes to mind) that are switching to clang and getting very modern C/C++ support.
Post reply on HN