Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Ceylo

Pages: 1 2 3 [4] 5 6 ... 69
46
SFML development / Re: C++ standards
« on: January 10, 2018, 11:35:28 pm »
Sorry I was not very clear in my previous post but you're right. When saying "take latest versions supported by the main compilers you work with" I actually meant "take latest versions supported by the main compilers you and your users work with".

I guess this addresses your comment :)

Edit: implicitly this also means that if you user use a compiler version that don't support the standard you'd like to use, but the latest version of that compiler does, just ask them to update their compiler.

47
SFML development / Re: C++ standards
« on: January 10, 2018, 11:00:31 pm »
This is funny to see here more or less the same discussion that we had at my workplace :D

What I'd recommend:
- take latest versions supported by the main compilers you work with, only considering their very latest version. You're talking about future so it's not the time to even consider non-latest compilers. And deduce standard C++ you case use from that
- don't ask yourself if you need latest usable standard, just use it, you don't want to spend again time to decide whether standard should be upgraded if you could have done it 3 years earlier for the same price
- don't bother defining too many rules, you'll see over time how it feels, just try to keep code simple and be smart. So for example you don't need to define when auto should or shouldn't be used because: either way it doesn't make such a big difference in most cases so wearing your keyboard out isn't worth it :) , and whether it's appropriate really depends on contexts that you can't possibly all predict now

48
SFML development / Re: sf::NonCopyable and =delete
« on: January 10, 2018, 10:44:47 pm »
To add my non-constructive ( ;D ) opinion to this old thread:

I'm for using what C++ natively provides because:
- creating sf::Copyable is reinventing the wheel, it's not because you disagree with the standard for what's best that you should do it your own way. A 10 pages argument to explain that it's shorter to read is not worth the benefit of using standard already known stuff.
- modern C++ developers will know these operators, and as years pass, more and more will be used to that standard rather than non_copyable class
- by doing it yourself you prevent yourself from using more subtle cases like: non-copyable & non-movable, movable but non-copyable, plus the possible noexcept specifier on these methods, and eventually the differences that can be introduced with deleting copy constructor but keeping  copy assignement operator available, even if it's probably an unneeded corner case in SFML's usage
- you may miss benefits from C++ evolutions that can make use of the deleted or available operators, which precisely define the allowed behavior, while a sf::NonCopyable would over-specify what's actually needed just because it'd need to be usable commonly in SFML.

50
General / Re: Font will not load from file while injected
« on: January 05, 2018, 11:51:19 pm »
You should check what is the current working directory at the time of loading the font, it’s not necessarily the directory of your executable.

51
General discussions / Re: How is SFML going?
« on: January 05, 2018, 10:16:46 am »
It's just hard to get people working and involved on it because time isn't infinite, and too much good ideas are stopped because of this minimalistic spirit.
So is it because of time or because you disagree with SFML’s spirit or for another reason that you didn’t help on https://en.sfml-dev.org/forums/index.php?topic=22480.0 ?

Asking about this specific feature because it seems to be the highest priority among big topics for SFML dev team (at least I guess that’s what « current focus » means).

52
General discussions / Re: Why is SFML split with 1 dll file per module?
« on: January 05, 2018, 10:05:02 am »
Don't forget that a SFML module is not just a shared library, it also brings with it a bunch of system dependencies. Maybe some people don't want to install all the audio libs if they don't use audio (there's even a request to add options to disable codecs within the audio library, to reduce the amount of dependencies to what's strictly needed). Or maybe people simply can't compile the graphics module because they have no display (and thus no X & GL libs), but they don't care since they only use audio and network.
Ok indeed. Do you know the percentage of users that want to use only some parts of SFML? Especially how many don’t want audio or graphics/window, since this is where there are most dependencies?

53
General discussions / Re: Why is SFML split with 1 dll file per module?
« on: January 04, 2018, 11:53:12 pm »
Because not everyone needs all the modules all the time. 80% of the SFML projects probably never use the network module.
So ? It doesn’t matter if you don’t use everything and have everything for the same price. What’s the advantage in having minimalist binaries when the whole package is 2.5MB?

What's the real downside of having it split "physically"? Is linking or shipping one library really that that much simpler?
More complicated than needed. Why care about which module you link against? Why should you need to care about the link order? Why should your app need to have 5 or 6 dynamic library files installed or shipped (for systems that favor dynamic libs) when it actually depends on a single API?

54
General discussions / Why is SFML split with 1 dll file per module?
« on: January 04, 2018, 10:16:56 pm »
Hello,

I’m wondering why each SFML module is represented by a distinct dynamic library file? Rather than a single SFML.dll.
I understand the semantic separation by related features, but this only requires separation by modules in documentation and in the API. When doing a new release, all modules are shipped together with the newer version, there is no independent versionning. Also all the modules account for less than 2.5MB so I see no need to sometimes ship only part of SFML for lighter distribution. This makes linking against SFML uselessly "complicated" (it’s quite simple already actually but could be simpler), and makes the project structure for SFML developers also more complicated than necessary.

So I’m wondering... why the split in several library files ?

55
No no rpath is working great, no problem on that side :D
My issue is with the paths to all the frameworks I should bundle in my application. As SFML_LIBRARIES doesn’t reference all of them ; it misses the indirect dependencies.

56
General discussions / Re: How is SFML going?
« on: January 04, 2018, 12:50:49 am »
Ok I understand. Focused teamwork would be both interesting from developers (at least I think so) and from SFML’s point of view. From what I understand you need support from Linux and Windows developers and I’m surprised you didnt get help about it since september. I can’t believe there’ve been no such developers active in SFML dev community since that time.

So I’m wondering why you didn’t get support? Nobody is interested in this feature?

57
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: January 04, 2018, 12:41:00 am »
Awesome! Might be my next PR after the 2 current ones if nobody else takes care of it in the meantime :D

58
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: December 30, 2017, 02:11:27 pm »
Done there: https://github.com/SFML/SFML/pull/1335
Still wondering how I can trigger your CI though :) review needs to be finished first? (a bit odd for me as I'm used to running the CI while review is being done at my workplace, to avoid delaying more than necessary)

59
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: December 30, 2017, 01:40:42 am »
I've started doing the changes to support config file generation. At the moment this is working at least for me on macOS with frameworks. I expect it to work on other platforms too because it reuses the definitions of current SFML targets. This implies a LOT of changes though so I would like your feedback before going on.

The current diff: https://github.com/SFML/SFML/compare/master...Ceylo:feature/CMakeTargetExport

Especially I have replaced all the listing of dependencies with calls to target_link_libraries() and target_include_directories() for 3 reasons:
- this avoids redoing what CMake already does (target_link_libraries() and target_include_directories() already handle lists)
- this makes it easier to group the full setup (include+link) of each dependency
- this will allow specifying which dependencies must be public in case of static linking (what SFML_DEPENDENCIES currently does in FindSFML.cmake), same eventually if compile definitions or include dirs must be exported (currently only the root include dir of SFML is exported)

In terms of usage right now (example from sfeMovie):
find_package (SFML 2.3 COMPONENTS graphics window system audio REQUIRED)
target_link_libraries(sfeMovie PRIVATE sfml-graphics sfml-window sfml-system sfml-audio)

I didn't expose yet the fact that sfml-graphics depends on sfml-window and sfml-system. Could be done and would allow writing only
target_link_libraries(sfeMovie PRIVATE sfml-graphics sfml-audio)
Dunno yet if we want that though.

PS: does your CI allow testing branches before the PR is open? This way I can quickly see whether I broke something on other platforms.

60
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: December 29, 2017, 04:22:18 pm »
Oh well, looks like time has passed since the last discussions. :)
Does it mean there is no reason anymore to keep CMake 2.8 ?

Pages: 1 2 3 [4] 5 6 ... 69
anything