C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›639 »

feedmegin: Jul 30, 2008

I guess my point is, if I want to write, like, grep or something I can do that right now in standard C++ using nothing but the standard and it will work on all standards-compliant platforms now, in the past, or on the future. It should work on VMS or z/OS or FutureOS3000. I can't do that with this library, because afaics it fundamentally depends on doing platform-specific stuff for it to be useful for pretty much anything. For that reason, useful though it might be, I don't see why it belongs in the standard rather than being, like actual Cairo, a third party library. Especially before, for example, incorporating something like boost::filesystem; standard C++ currently doesn't even know what a directory is! I mean I know there is a TS for that too, but that sort of thing kind of seems higher priority to me than a barely-useful 2d graphics API.

feedmegin fucked around with this message at 23:24 on May 24, 2016

# ? May 24, 2016 23:12

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 19:01

Xerophyte: Mar 17, 2008; This space intentionally left blank

std::filesystem is in C++17 so presumably the committee agrees with you.

I guess I think that:
1: A 2d graphics library is more useful than you give it credit for, and it is a distinct thing from a format IO library like OpenImageIO or FreeImage and a UI library like Qt (which is admittedly a lot more than UI). OpenGL doesn't have gif support or window events either, and it's pretty useful.
2: Ultimately Herb Sutter is not our bitch and can work on whatever library he likes and submit whatever standard proposals he wants. I doubt I'd use Cairo++ much, but I doubt I'd use TransactionalMemory++ either. So what?

# ? May 24, 2016 23:48

csammis: Aug 26, 2003; Mental Institution

feedmegin posted:

I mean I know there is a TS for that too, but that sort of thing kind of seems higher priority to me than a barely-useful 2d graphics API.

I'm not about to defend everything the committee does or doesn't do but it's really not fair to anyone involved to pick on one particular thing and get bent out of shape because some people spend some amount of their time to make a proposal. Committee meetings take six long days with dozens of people. Hundreds of different topics are talked about at those meetings. Some things get discussed and put up for a vote in five minutes and other things take five days with no real forward progress. I really think you're overestimating how much time the 2D proposal is taking away from anything else.

If you seriously think it's a waste of time and should be abolished from future discussions then you should join up on the groups and go to meetings and etc. and participate in the process. If enough people do this it actually does work, albeit slowly. A couple years ago there was a database SG (13?) that looked to me like was going to be a waste of time. There was talk on the group about how it didn't belong in the standard. I had the chance to go to Issaquah and I was prepared to speak my piece about it but in fact the SG got disbanded in the freaking opening plenary. AFAIK the group leader hadn't been involved in some time and with all the chatter no one wanted to step in and defend it. Democracy at work :v:

# ? May 25, 2016 00:13

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Xerophyte posted:

Regardless of how good an idea you think this is, "2D image" includes a lot less bagage than "window" or "JPG". It makes some sense that if there's 2d graphics in the standard library then it will be agnostic to both specific UI concepts and file formats since very few assumptions can be made about either.

Personally I've used the Haskell bindings of Cairo to implement a turtle graphics/logo interpreter. Sure, I also had separate libraries for taking my pixel buffer and outputting it to my application window or a file format on disk, but it's pretty useful to be able to generate the pixel buffer without any specific use in mind.

I'm not saying it's the most critical feature I can imagine but if Herb Sutter wants to make a reasonable 2d graphics library for the standard library then more power to him. It'll probably see more use than the irregular modified cylindrical Bessel functions.

hey there's at least a research group who'll use those (https://arxiv.org/pdf/1308.0348.pdf), but the 2d graphics lib is a waste of time for everyone involved. isn't it just a terrible C++ port of Cairo?

e: it seems like its closer in spirit to canvas (which is useful actually) but apparently herb is concerned about not having a graphical hello world? what person goes through the torture of C++ for their first language anymore?

Malcolm XML fucked around with this message at 00:39 on May 25, 2016

# ? May 25, 2016 00:29

Xerophyte: Mar 17, 2008; This space intentionally left blank

Malcolm XML posted:

hey there's at least a research group who'll use those (https://arxiv.org/pdf/1308.0348.pdf), but the 2d graphics lib is a waste of time for everyone involved. isn't it just a terrible C++ port of Cairo?

I'm not saying the numerical computing stuff in C++17 is bad, sometimes you need a nice cylindrical or spherical basis function. Sometimes you need to programmatically draw things, also. Both strike me as fairly niche and can be done with third party libraries, but if there's a decent proposal to add support in the standard library, why not? It's not like the 2D primitive drawing operations are in constant flux or ill-defined or otherwise resistant to standardization.

Incidentally, reading the <drawing> proposal it seems Herb does want to add general I/O support to the standard at a later date, which honestly has me more skeptical since those seem like things that would be hard to standardize.

# ? May 25, 2016 00:51

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

Xerophyte posted:

I'm not saying the numerical computing stuff in C++17 is bad, sometimes you need a nice cylindrical or spherical basis function. Sometimes you need to programmatically draw things, also. Both strike me as fairly niche and can be done with third party libraries, but if there's a decent proposal to add support in the standard library, why not? It's not like the 2D primitive drawing operations are in constant flux or ill-defined or otherwise resistant to standardization.

Incidentally, reading the <drawing> proposal it seems Herb does want to add general I/O support to the standard at a later date, which honestly has me more skeptical since those seem like things that would be hard to standardize.

I feel like it's all dancing around the issue that distributing c++ libraries is painful as gently caress and there isnt a good crossplatform package manager

Then we don't have to rely on the STD committee to use libraries

# ? May 25, 2016 14:46

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

code:

template <typename T>
class MyArrayView {
  // Implicit conversion constructor
  MyArrayView(const std::vector<T>& v) {
    ...
  }
  ...
};

template <typename T>
MyArrayView<T> DoSomething(MyArrayView<T> view) {
  ...
}

void whatever() {
  std::vector<int> vec;
  ...
  // error: no matching function for call to 'DoSomething'
  // note: candidate template ignored: could not match 'MyArrayView' against 'vector'
  MyArrayView<int> view = DoSomething(vec);

  // fine
  MyArrayView<int> view = DoSomething<int>(vec);
}

Is there some different syntax I can use in declaring/defining DoSomething() so that I can leave out the template parameter in the call? (in this case, "<int>").

In my current case I can change the parameter to a const vector<T>&, but I can imagine wanting the ArrayView parameter for other things in the future.

# ? May 25, 2016 23:19

Sex Bumbo: Aug 14, 2004

You can do something lovely like this:

code:

template <typename T>
MyArrayView<T> MakeArrayView(const std::vector<T> & v) {
    // ...
}


  MyArrayView<int> view = DoSomething(MakeArrayView(vec));

This is probably way worse. I don't know. Sorry.

# ? May 25, 2016 23:59

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

Sex Bumbo posted:

You can do something lovely like this:

Yeah, that's another way to make it work, calling the implicit constructor explicitly, but that's basically what I'm trying to skip. I feel like the compiler should have enough information to figure out it can construct an ArrayView from a vector and pass that as the argument, but maybe I'm missing something.

# ? May 26, 2016 01:11

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

You're trying to convert a const std::vector<int> & to a MyArrayView<T> for some T. The implicit conversion which makes that work is defined on MyArrayView<int>, but the compiler cannot actually perform lookup into MyArrayView<T>, because technically MyArrayView is permitted to have completely different members for every specialization. It is not really a reasonable rule in general for the compiler to guess that you might mean the specialization with the same template argument list as std::vector<int>.

They actually did something similar to this in C++17 with template argument deduction for constructors, where I believe the compiler does lookup in the primary template to find a signature it can match against. I'm pretty sure a similar approach could work here, if it doesn't catch this case already.

# ? May 26, 2016 01:29

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

That Turkey Story posted:

A lot of people complain about what the committee does and doesn't do, but it's really the C++ community's responsibility to participate. That some people put work into bringing a graphics API to the standard library does not mean that the committee is focused on that. I don't know anyone who is participating in that effort. There is, however, an active Reflection group which will likely cover enum introspection, although none of that work is slated for C++17 and is still very early on. If you care enough, write a proposal and show up to a meeting to present it (or find someone online to champion it at a meeting). It costs nothing to do this, and a simple paper like that doesn't take much effort to put together. A lot of the meetings are in the US if that's where you're from. There is a meeting in Washington in the fall.

This is completely true, and I was mostly just making a glib joke.

# ? May 26, 2016 01:35

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

rjmccall posted:

You're trying to convert a const std::vector<int> & to a MyArrayView<T> for some T. The implicit conversion which makes that work is defined on MyArrayView<int>, but the compiler cannot actually perform lookup into MyArrayView<T>, because technically MyArrayView is permitted to have completely different members for every specialization. It is not really a reasonable rule in general for the compiler to guess that you might mean the specialization with the same template argument list as std::vector<int>.

They actually did something similar to this in C++17 with template argument deduction for constructors, where I believe the compiler does lookup in the primary template to find a signature it can match against. I'm pretty sure a similar approach could work here, if it doesn't catch this case already.

That makes total sense, thanks!

# ? May 26, 2016 02:18

everythingWasBees: Jan 9, 2013

Is there any good guides/advice to help somebody who's somewhat comfortable with C++ to learn C? Or should I just be considering the opposite of what C to C++ guides say.

# ? May 26, 2016 04:48

nielsm: Jun 1, 2009

Hubis posted:

This is completely true, and I was mostly just making a glib joke.

Glib?
GLib?

(I can definitely understand wanting to make jokes about the latter.)

# ? May 26, 2016 07:58

yippee cahier: Mar 28, 2005

everythingWasBees posted:

Is there any good guides/advice to help somebody who's somewhat comfortable with C++ to learn C? Or should I just be considering the opposite of what C to C++ guides say.

Here's a recently popular guide to modern C, with useful links to other guides or references: https://matt.sh/howto-c

A lot of people are going to tell you to pick up K&R, but if you basically know the language already the rest of it's going to be a little dated.

# ? May 26, 2016 16:44

taqueso: Mar 8, 2004

everythingWasBees posted:

Is there any good guides/advice to help somebody who's somewhat comfortable with C++ to learn C? Or should I just be considering the opposite of what C to C++ guides say.

There are quite a few guides like that if you google 'C for C++ programmers' though I'm not sure which are good ones. I clicked on a few and noticed they were aimed at C89. Nothing wrong with that exactly, but some niceties you are used to from C++ show up in later C standards. It actually might not be too bad to look at a C89 for C++ thing plus a "what's new in Cxx" doc.

You are going to know a lot of C already, it's more about what isn't available that you are used to. I don't think you will have too much trouble with the low level syntax stuff. I like the book C Interfaces and Implementations, it shows how to write C that is decoupled and maintains separation of concerns.

Specific things that come to mind: Strings are much more of a headache. You will need to find a data structure library or write your own as needed, none of that is built in.

# ? May 26, 2016 17:01

Eggnogium: Jun 1, 2010; Never give an inch! Hnnnghhhhhh!

I have a precompiled header that is generated from header foo.h. Somehow, even though my make rule for the PCH only lists foo.h as a prereq, make is smart enough to recursively parse all the included headers in foo.h and all their included headers, etc. It then makes these headers also prereqs for the PCH.

My question is, is this functionality documented anywhere? Or where can I find it in make's source? I have one header that is deep in the tree that doesn't trigger the PCH to be regenerated and I want to understand why.

# ? May 27, 2016 20:30

Sex Bumbo: Aug 14, 2004

I don't think it has anything to do with being a pch. Any normal source file needs to list its header dependencies somehow, dependencies that aren't specified in the makefile because that would be ridiculous.

http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

Maybe make it list all the dependencies its testing?

# ? May 27, 2016 20:43

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Make doesn't parse headers. gcc and clang can spit out makefiles which list the dependencies for each header as part of the build, and can either include all headers (-MD) in that, or all non-system headers (-MMD). You generally want the latter as checking if all of the system headers have changed can be really slow and is normally pointless, so it is likely that the one header that is not triggering rebuilds is being considered a system header.

# ? May 27, 2016 21:19

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Sex Bumbo posted:

I don't think it has anything to do with being a pch. Any normal source file needs to list its header dependencies somehow, dependencies that aren't specified in the makefile because that would be ridiculous.

http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

Maybe make it list all the dependencies its testing?

Unless it's cooperating with the compiler � la gcc's -MD, header dependencies do need to be specified in Makefiles. There's no real alternative, make doesn't have enough information to compute correct dependencies itself.

# ? May 27, 2016 21:20

Eggnogium: Jun 1, 2010; Never give an inch! Hnnnghhhhhh!

Sex Bumbo posted:

I don't think it has anything to do with being a pch. Any normal source file needs to list its header dependencies somehow, dependencies that aren't specified in the makefile because that would be ridiculous.

http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

Maybe make it list all the dependencies its testing?

I was running it verbose and I was seeing them show up as dependencies. It just wasn't saying why they were dependencies when they weren't listed anywhere in the makefile.

Plorkyeran posted:

Make doesn't parse headers. gcc and clang can spit out makefiles which list the dependencies for each header as part of the build, and can either include all headers (-MD) in that, or all non-system headers (-MMD). You generally want the latter as checking if all of the system headers have changed can be really slow and is normally pointless, so it is likely that the one header that is not triggering rebuilds is being considered a system header.

Subjunctive posted:

Unless it's cooperating with the compiler � la gcc's -MD, header dependencies do need to be specified in Makefiles. There's no real alternative, make doesn't have enough information to compute correct dependencies itself.

Ah thank you! -MMD is being passed. That makes so much more sense that the compiler is doing this. I was worried I was about to have my entire understanding of how make works obliterated in an instant.

# ? May 27, 2016 23:36

VikingofRock: Aug 24, 2008

Speaking of makefiles, what is the modern way to build stuff? Do most people use CMake, Autotools, handwritten makefiles or something else entirely? Let's say that the program is large enough that a build tool like make is nice, but not enterprise-scale by any means.

# ? May 29, 2016 16:40

Ralith: Jan 12, 2011; I see a ship in the harbor
I can and shall obey
But if it wasn't for your misfortune
I'd be a heavenly person today

CMake is slightly less terrible than everything else just because it's very mature. I've spent a lot of time trying to make the latest crop of fancier stuff (tup, bazel, meson, etc) work for me and it never quite pans out--none of them have really grown much past their authors' use case. CMake's incredibly wacky language is pain, but at the end of the day it works.

# ? May 29, 2016 20:45

Joda: Apr 24, 2010; When I'm off, I just like to really let go and have fun, y'know?; Fun Shoe

CMake seems to be the one standard most GNU-based or cross-platform IDEs agree on at least. A lot of them do have their own systems (like QMake for QtCreator,) so the CMake side doesn't receive much love in terms of manageability within the environment, although with my limited experience it is the one purely text-based project management system I've had the best time with and it works for basically anything.

# ? May 30, 2016 00:23

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

You can also use it to generate projects for basically every IDE out there, including VS and Xcode.

The scripting language is really amazingly bad, and you have to write way more of it than you probably ought to, and the model itself is sometimes weirdly limited in ways that might only matter to C compiler writers; but it's absolutely the best option available for a cross-platform build system.

# ? May 30, 2016 01:36

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Is cmake really that much better than a makefile or series of target-specific makefiles that include the core makefile?
My experience has been that even just being a user who wants to build something that used cmake it's relatively a gigantic pain in the butt vs. old-school Bernstein-style makefiles. I can't imagine that creating that mess is significantly easier than constructing makefiles.

# ? May 30, 2016 03:14

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Make is quite a bit easier than cmake, but then you just have a makefile and not ide/ninja/etc support.

# ? May 30, 2016 04:49

Hyvok: Mar 30, 2010

roomforthetuna posted:

Is cmake really that much better than a makefile or series of target-specific makefiles that include the core makefile?
My experience has been that even just being a user who wants to build something that used cmake it's relatively a gigantic pain in the butt vs. old-school Bernstein-style makefiles. I can't imagine that creating that mess is significantly easier than constructing makefiles.

CMake works for Windows and Visual Studio and whatever.

In my opinion CMake has been one of the best things I've learned to use related to C++. It is not perfect but much better than creating makefiles for all different platforms.

# ? May 30, 2016 08:01

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

I'm building an open-source application with Qt. There's a bunch of useful stuff in KDE that I'd like to use (KItemModels and KItemViews, specifically). If I want to comply with their licensing (LGPL I believe), am I allowed to just copy/paste the source files in my project with proper attribution or am I really forced to have everyone build the KDE frameworks themselves?

The reason I ask is that these libraries I want to use are fairly self-contained. It's a big hassle to get KDE to build on Windows and OS/X, when I could just compile the classes as part of my app and be done with it.

# ? Jun 2, 2016 10:19

feedmegin: Jul 30, 2008

Sagacity posted:

I'm building an open-source application with Qt. There's a bunch of useful stuff in KDE that I'd like to use (KItemModels and KItemViews, specifically). If I want to comply with their licensing (LGPL I believe), am I allowed to just copy/paste the source files in my project with proper attribution or am I really forced to have everyone build the KDE frameworks themselves?

The reason I ask is that these libraries I want to use are fairly self-contained. It's a big hassle to get KDE to build on Windows and OS/X, when I could just compile the classes as part of my app and be done with it.

It's the Library GPL for a reason. You can ship the KDE libraries with your project as binaries. You can probably make your own little library with the KDE stuff in it and link against that, too, as long as you release the source/makefiles/etc. You can't just bung the source into your application and still keep it closed source.

Edit: v0v fine now it's the Lesser GPL. It didn't start out being called that, though!

feedmegin fucked around with this message at 13:09 on Jun 2, 2016

# ? Jun 2, 2016 11:44

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

feedmegin posted:

It's the ~~Library~~ Lesser GPL for a reason.

# ? Jun 2, 2016 11:55

OddObserver: Apr 3, 2009

feedmegin posted:

It's the Library GPL for a reason. You can ship the KDE libraries with your project as binaries. You can probably make your own little library with the KDE stuff in it and link against that, too, as long as you release the source/makefiles/etc. You can't just bung the source into your application and still keep it closed source.

Almost. The sane way is to ship them as a DLL (and provide tarball of your version to the library somewhere on your site). Statically linking is actually permitted as long as you provide object files for your app(!), which I am not sure anyone ever did, for obvious reasons.
Here is how it's intended to work --- though really details of compliance, etc., are best left to lawyers:
http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

# ? Jun 2, 2016 12:43

Doc Block: Apr 15, 2003; Fun Shoe

If your application is GPL or LGPL (OP said it's an open source application), then I don't see why you couldn't just put the class files in your project and call it a day.

"Users" will still be able to swap out the KDE stuff with a newer version or whatever since the source will be available, etc

edit: has anyone ever actually swapped out a .DLL or .framework or whatever of an LGPL library that shipped with a closed-source application?

Doc Block fucked around with this message at 15:08 on Jun 2, 2016

# ? Jun 2, 2016 15:05

ExcessBLarg!: Sep 1, 2001

Sagacity posted:

I'm building an open-source application with Qt. There's a bunch of useful stuff in KDE that I'd like to use (KItemModels and KItemViews, specifically). If I want to comply with their licensing (LGPL I believe), am I allowed to just copy/paste the source files in my project with proper attribution or am I really forced to have everyone build the KDE frameworks themselves?

There's a few options.

Since your application is open-source, you can copy the KDE source files into your project like any source file you'd write. To do so, though, the rest of the code has to be under a license compatible with the LGPL v2.1+ (e.g, the LGPL itself, the GPL, the 2/3-clause BSD license, MIT, etc.) and your application as a whole must be distributed under the terms of an appropriate version of the LGPL or GPL. Specifically when you copy the source files from the KDE project, you can modify them as necessary, but you must retain the copyright header and license statement in each source file. You'll also want to include a copy of the license itself (usually called COPYING.LIB in the upstream project).

However, if your application were proprietary (closed-source) or was released under an LGPL-incompatible license then it gets a bit more complicated. The easiest thing to do is to make sure that whatever KDE code you use, you use from unmodified KDE shared libraries. Then you can effectively distribute your application any way you want, and include the necessary pre-built KDE libraries alongside your application binaries so long as you make the KDE library source code available under the terms of the LGPL. Note that you can distribute binary versions of the KDE libraries so that users don't have to compile it themselves. You don't even have to compile it yourself if that's an issue.

Doc Block posted:

edit: has anyone ever actually swapped out a .DLL or .framework or whatever of an LGPL library that shipped with a closed-source application?

Sure. People have done it if they want to use the library as a point to instrument or modify the application, for research purposes, reverse engineering, or whatever. Also library bug fixes. Hell, people have DLL-swapped closed-source libraries for bug fixes too.

Usually you would use the version of the library that ships with the app if you can, but there's times when swapping it out is useful.

# ? Jun 2, 2016 15:47

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Doc Block posted:

edit: has anyone ever actually swapped out a .DLL or .framework or whatever of an LGPL library that shipped with a closed-source application?

Many years ago I replaced Opera's ogg+theora/vorbis-only gstreamer build with a fully-featured one.

# ? Jun 2, 2016 16:02

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

say you have GenitalInterface, and two classes (Toilet and Urinal) that take ownership of unique_ptr<GenitalInterface> in their constructor. I am not able to change those classes to give up ownership. I now need to use a single instance of an implementation of GenitalInterface.

Is some poo poo like this the only way? feel like I'm forgetting something that makes this simple.

code:

class UnownedGenitalInterface : GenitalInterface {
 public:
  explicit UnownedGenitalInterface(GenitalInterface* gi) : gi_(gi) {}
  ~UnownedGenitalInterface() = default;

  int Piss(const string& whatever) override {
    return gi_->piss(whatever);
  }
  // continue forwarding to 'gi' for every loving call in the interface.
  // ...

 private:
  GenitalInterface* gi_;
};

...

// Penis implements GenitalInterface
Penis penis;
Toilet toilet(std::make_unique<UnownedGenitalInterface>(&penis));
Urinal urinal(std::make_unique<UnownedGenitalInterface>(&penis));

this is loving stupid. I want to remove ownership from the toilet/urinal, but can't.

# ? Jun 2, 2016 20:50

Sex Bumbo: Aug 14, 2004

Can you make the deleter just noop or do something else?

# ? Jun 2, 2016 21:01

Illusive Fuck Man: Jul 5, 2004; RIP John McCain feel better xoxo ð ð; Taco Defender

oh duh yeah that should work. I've never needed to use a deleter before so I forgot it was a thing

edit: either I don't understand how to use deleters, or this doesn't work. Can't convert unique_ptr<abcd, MyNoOpDelete> to unique_ptr<abcd, std::default_delete<abcd>>

Illusive Fuck Man fucked around with this message at 21:37 on Jun 2, 2016

# ? Jun 2, 2016 21:03

leper khan: Dec 28, 2010; Honest to god thinks Half Life 2 is a bad game. But at least he likes Monster Hunter.

Doc Block posted:

If your application is GPL or LGPL (OP said it's an open source application), then I don't see why you couldn't just put the class files in your project and call it a day.

"Users" will still be able to swap out the KDE stuff with a newer version or whatever since the source will be available, etc

edit: has anyone ever actually swapped out a .DLL or .framework or whatever of an LGPL library that shipped with a closed-source application?

Because the GPL is a legal virus that you may not want your code infected with? You can't just copy pasta code like that without thought.

# ? Jun 2, 2016 21:10

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 19:01

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

ExcessBLarg! posted:

Since your application is open-source, you can copy the KDE source files into your project like any source file you'd write. To do so, though, the rest of the code has to be under a license compatible with the LGPL v2.1+ (e.g, the LGPL itself, the GPL, the 2/3-clause BSD license, MIT, etc.) and your application as a whole must be distributed under the terms of an appropriate version of the LGPL or GPL. Specifically when you copy the source files from the KDE project, you can modify them as necessary, but you must retain the copyright header and license statement in each source file. You'll also want to include a copy of the license itself (usually called COPYING.LIB in the upstream project).

Hmm, I'm planning to license the code under MIT but I'd like the application itself to also fall under MIT.

If I understand it correctly, to avoid having to license my application as LGPL:
* I'd then have to provide a separate project with the copy/pasted code that generates a .dll/.so with the KDE stuff I can link my application with. So it'd still be a copy/paste but the LGPL would be restricted to that separate project
* Or, alternatively, just build the KDE frameworks myself and redistribute the binaries under the proviso that I don't change them so anyone could in theory compile the libs for themselves
* Or, final option, just use a "find_package KF5" in my CMakeLists.txt along with some build instructions

Does that make sense?

# ? Jun 2, 2016 21:25

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›639 »