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

Atria: A toolkit for modern C++ development from Ableton

abletonag.github.io

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Atria: A toolkit for modern C++ development from Ableton

#21

Post by mratzloff »

arximboldi wrote: post #5
rburhum wrote: post #2

First reaction: "Header only - This is great!" Then I read: "Dependencies boost". OK, moving on...

Interesting... There are not many parts depending on boost and we could make it entirely optional [1] (it would be still be nice for people wanting to use atria::variant::match in combo with boost::variant, optionally). Could you elaborate on why boost is a total no-go for you? https://github.com/AbletonAG/atria/search?utf8=%E2%9C%93&q=b...

In my opinion, Boost should only ever be a dependency for end-user applications, never libraries, unless the library is specifically aimed at Boost users.

Re: Atria: A toolkit for modern C++ development from Ableton

#23

Post by nadams »

lookbothways wrote: post #9
justinvoss wrote: post #8

Earlier quoted context omitted.

Honest question from someone who hasn't done C++ in a very long time: why is "header only" a good thing?

From the popular (in game development circles, at least) stb libraries: >Why single-file headers? >Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.) >There's also a common problem in Windows where a library was built ag…

> Windows doesn't have standard directories where libraries live.

Visual Studio certainly does:

Microsoft Visual Studio 11.0\VC\include

Many people argue don't put libraries there - well then you are back to the original problem. Just as long as you don't overwrite a provided library - there are no issues. And if you do overwrite it - you get a rolled up newspaper and start beating the person who overwrote it.

Re: Atria: A toolkit for modern C++ development from Ableton

#25

Post by lookbothways »

nadams wrote: post #23
lookbothways wrote: post #9

Earlier quoted context omitted.

From the popular (in game development circles, at least) stb libraries: >Why single-file headers? >Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.) >There's also a common problem in Windows where a library was built ag…

> Windows doesn't have standard directories where libraries live. Visual Studio certainly does: Microsoft Visual Studio 11.0\VC\include Many people argue don't put libraries there - well then you are back to the original problem. Just as long as you don't overwrite a provided library - there are no issues. And if you do overwrite it - you get a rolled up newspaper and start beating the person who overwrote it.

It's a different directory for every version of Visual Studio (and obviously mingw doesn't use it), ergo it's not a standard directory like /usr/include

His point is that it's arguably simpler to tell people to copy a single source file to their project's source tree, than it is to help them find the include dir for whatever compiler they happen to be using. And that it's probably easier to have to manually update this file when the library is patched, than it is to coordinate manual library updates across an entire team without the use of a package manager.

Re: Atria: A toolkit for modern C++ development from Ableton

#26

Post by chetanahuja »

arximboldi wrote: post #5
rburhum wrote: post #2

First reaction: "Header only - This is great!" Then I read: "Dependencies boost". OK, moving on...

Interesting... There are not many parts depending on boost and we could make it entirely optional [1] (it would be still be nice for people wanting to use atria::variant::match in combo with boost::variant, optionally). Could you elaborate on why boost is a total no-go for you? https://github.com/AbletonAG/atria/search?utf8=%E2%9C%93&q=b...

Adding my vote to the anti-boost camp. The library is huge and is pretty much an all or nothing affair. The gp's point about header-only and depending on boost being complete polar opposite characteristics is on point

Re: Atria: A toolkit for modern C++ development from Ableton

#27

Post by RotsiserMho »

arximboldi wrote: post #5
rburhum wrote: post #2

First reaction: "Header only - This is great!" Then I read: "Dependencies boost". OK, moving on...

Interesting... There are not many parts depending on boost and we could make it entirely optional [1] (it would be still be nice for people wanting to use atria::variant::match in combo with boost::variant, optionally). Could you elaborate on why boost is a total no-go for you? https://github.com/AbletonAG/atria/search?utf8=%E2%9C%93&q=b...

I would just like to say that I love boost. I believe it leads credibility to a project such as this to know that the wheel wasn't reinvented. I seriously don't understand why there's such an aversion to it. Most of it is header-only and the especially useful bits are tiny.

Re: Atria: A toolkit for modern C++ development from Ableton

#28

Post by rburhum »

arximboldi wrote: post #5
rburhum wrote: post #2

First reaction: "Header only - This is great!" Then I read: "Dependencies boost". OK, moving on...

Interesting... There are not many parts depending on boost and we could make it entirely optional [1] (it would be still be nice for people wanting to use atria::variant::match in combo with boost::variant, optionally). Could you elaborate on why boost is a total no-go for you? https://github.com/AbletonAG/atria/search?utf8=%E2%9C%93&q=b...

I have used boost for several big projects with an extended code base and it always creates various issues with the build. If you use it extensively, you will realize that certain parts are not header only; you will need to link it with libraries (think threads or filesystem libraries).

I use C++ for portability accross several platforms and boost always seems to have a completely different naming convention in each platform. Upgrading between versions e.g. 1.48 to 1.51 will very likely require code changes since it is not uncommon to break API contracts across versions.

I have amazing C++ developers with decades of experience that would quit on the spot if I forced them to use boost - and I wouldnt blame them.

I can rant forever.

New versions of C++ have things that used to make boost essential, but now that later C++ standards support lots of those concepts, I am happily boost-free. Boost is a huge negative, so you would need to be really amazing for me to even consider bringing back a dependency that has only brought me so much pain in the past.

Re: Atria: A toolkit for modern C++ development from Ableton

#29

Post by SamReidHughes »

tacos wrote: post #19
to3m wrote: post #12

Earlier quoted context omitted.

I'm not the same person, but I don't use boost, and I avoid projects that depend on it, because every time I've used boost in the past it's always done dreadful things to the build time. Anything that uses boost always seems to compile at a glacial pace and then takes aeons to link. It's also not much fun in the debugger, should you happen upon it in a call stack or see one of its types in the watch window - but buil…

You have to be careful with what you pull in. But with precompiled headers I'm building a suite of 25 command line apps, all dependent on boost, in 22 seconds on a 2012 MacBook Air. gcc on Windows is similar. Microsoft doesn't even let you share precompiled headers across projects, but it's still building in under 20 seconds. There's a LOT of really idiotic C++ build scripts out there. I really don't know what some p…

How complicated are these command line apps?

Re: Atria: A toolkit for modern C++ development from Ableton

#30

Post by enqk »

yoklov wrote: post #14
lookbothways wrote: post #9

Earlier quoted context omitted.

From the popular (in game development circles, at least) stb libraries: >Why single-file headers? >Windows doesn't have standard directories where libraries live. That makes deploying libraries in Windows a lot more painful than open source developers on Unix-derivates generally realize. (It also makes library dependencies a lot worse in Windows.) >There's also a common problem in Windows where a library was built ag…

Worth noting that only the first two points there are relevant here, since these are not single file libraries. Also, the STB libraries work massively differently from C++ header only libs (#define STB_FOO_IMPLEMENTATION, for example). Also, fwiw Sean Barrett also has gone on record as saying that he's not really a fan of C++ before. I'm struggling to find a specific link, but it's not really a secret. (As a side not…

STB libraries are C not C++. Sean Barrett prefers C, basically.

The header-only approach from Sean Barrett is quite a bit different than the header-only approach from C++:

In C++ it means you will be pulling all the code all the time when importing a header.

In C you will get the prototypes for the library. And in only one of the file you will #define STB__IMPL

Anyhow STB libraries are a joy to work with, I urge anyone to try them

Post reply on HN