I'm definitely a beginner with Conan, and I've only used it with very small projects where pretty much everything is under my control. Loved it! However, this simplicity also makes me kind of unable to appreciate the use and interest of conan profiles. Why can't CMake and Conan talk kindly to each other to pass things like compiler versions and C++ standards versions?
I imagine that the (really cool) project cmake-conan wrapper is dedicated to actually formalize the "talk kindly to each other" part I so boldly abstracted away: but even if I entirely trust it's utterly complex, I still feel there is something I'm really missing here?
As I'm trying to migrate to Conan 2.0, the need to precise host and build profiles confuses me even more (I was doing fine without them for my baby libraries, why is it vital I precise them now and what do they do?). I feel actually a bit scared of Conan 2.0 and a part of me wants to stay away from it so I can stick with cmake-conan wrapper.
Is it possible to explain with (very) simple words why what seems to complexify my (very small) project management is worth the effort? Thank you!
Note: I am new to programming and extremely new to c++.I have seen scouring google for a long time and only things i can come up with are external headers and very complicated code..
I want to do this at school, and there we are provided with Turbo C++. We can't bring any external headers in there, gotta work with whatever i've got.
I want to create a GUI. I want to create something really good for our annual project and i want to create a GUI.
I would like to make as detailed a GUI as possible, but would be satisfied if i can create as much as several text options and clicking on em triggers respective functions (I am sorry if thats not how GUIs work, i never worked with one).
Again help is highly appreciated, i understand most discussions on Stack Overflow are much more complicated than this, i appreciate you taking the time to read and (hopefully) answer a layman question.
I'll suggest a non-technical solution because this is actually largely not a technical problem. Much of your problem is that you have to use Turbo C++. Unfortunately, a number of poorer countries have, for some reason, stuck with extremely outdates software in education. I know because I'm originally from one of the "Turbo countries", and I know that the main technical university there still uses Turbo for undergrad courses.
This is bad. Large projects in school are there to teach you to work on software. A regular programming course should teach you to think like a programmer, and it doesn't matter what language you use. But term projects are supposed to be more practical. The problem is, with Turbo C++, not only will you fail to learn enough, you will learn things that are bad. You'd be writing a 16-bit program that takes effort to even run on modern hardware, while not being able to use the C++ language properly. The compiler is older than the first ISO C++ standard!
If you want to make an impressive project that will stand out in your studies, especially if you later want to continue at a foreign university, I urge you to talk to your professor, explain the situation, and ask if you can use something else for the project. A modern compiler with some framework like Qt. If you can reach an agreement to use something else, it will benefit you.
Otherwise, if you have no choice, get Turbo Vision. There are versions of BC++ packaged with it, or you can find it elsewhere, Turbo Vision is a fairly comprehensive interface framework for the dinosaur era.
First off, the toolchain and operating system you are using is outdated and incapable. And the language support Turbo C++ offers can hardly be called C++ at all; the code you will write will not be C++ code. At best, it will be C with classes code.
All that aside, there was a fairly-capable Text-based User Interface (TUI) library available with Turbo C++ (as well as Borland's Pascal-based toolchains,) called Turbo Vision. You might be able to use that. It generates UIs quite similar to the Turbo C++ IDE itself.
But IIRC, it was not trivial to use, so I advise you to find a book or reference or comprehensive tutorial of some kind. However, since your environment precludes anything that is not available already with TC, I see no option for you other than using Turbo Vision or writing your own, which doesn't sound like something you can do or want to do.
I have some experience with C#/Java, PHP, ASP and all the other web based fuss languages but recently I've been trying to learn the real deal, which to me is C++. I must admit syntax is a bit weird to me, coming from managed environments but I started managing it. I bought some books but most of their examples, which I do understand, but they doesn't really help with the IDE, of course not, since they're not specialized about that.
So either way, I decided I've had enough with theory and simple book jobs so I came up with a "project" to test myself. I thought to myself that It should have some sort of INI parser, but I didn't want to write one myself, the "task" was to implement a 3rd party library/solution. Now from visual studio for C# I know how to add shared DLLs, which is not the problem. After some digging I've found this
http://code.jellycan.com/simpleini/
Cool thing about it is that it is claimed to be cross-platform which should be a win/win. It's open source as well, which is great.
But the question is, how I add it to visual studio so that when I include SimpleINI.h my IDE would compile it as well on each build. One way is to have it compiled as a shared DLL, I think, but I don't really want that :< . I really like the idea of open source and I imagine myself throwing code out there in the wild, in the future and I would like to include all the sources including the libraries, with proper credit.
How do you guys do it? I'd appreciate if you suggest a book or are "step-by-step" guide.
I'm trying to read MXF files (from Avid) into an Objective-C project and analyze some frames from video. Preferably getting them into a CGImage or NSImage.
I've been exploring the mxflib, but find myself at a bit of a standstill. I'm used to the mechanics of the standard video methods within Obj-c, but this package is C++ and not exactly something I'm familiar with.
Does anyone have experience working with this library or another similar one? There's not much information available on the subject (at least not that I can understand). And I'm not quite sure where to begin.
Actually, I'd say you're looking at it from a not so good way, as the mxflib is prepared to handle standard MXF files, not really Avid ones.
In short, for this to work, you need to extend the library as per Avid specs (it can be done!) or go with AMT, for which I understand you need to engage Avid to have it.
Finally, I think you're stuck with C++! ;-)
I'm looking to be able to build GUI applications quickly and painlessly as possible. I'm competent (though not expert, and have no formal training) in C++, but have never used a GUI building toolkit or framework or anything. I am not a professional programmer and am totally inexperienced and ignorant when it comes to building GUI apps. Have spent hours researching trying to figure out what to do; only getting more confused and discouraged though.
Qt and wxWidgets seem like the most popular options for cross-platform apps, though cross-platform isn't necessarily all that important to me; Windows-only is fine if that means the fastest learning curve.
Qt seems cool and the Qt Creator is sweet looking with lots of good demos, except it has its own classes for everything, and I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally. I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
I was thinking Visual Studio would have the smallest learning curve, but when I open a test GUI app, I see a bunch of foreign looking stuff like carats (^) all over the place - I found online that these mean "handles", which I have trouble even understanding the definition or purpose of ("sort of like pointers but not really" is basically how I've read people define them).
I know pretty much nothing about wxWidgets, or how it compares with Qt.
So every option has a big learning curve - and ideally I'd like to know which one minimizes the time you have to spend learning the toolkit/framework itself. Since I'm likely never going to be making money from the programs I create, the time I spend learning a specific toolkit would be pretty costly. I just want to be able to make a functional program using the C++ knowledge I have, but in GUI form. At the moment it seems if I want to make a GUI app, I'd have to spend way more time learning the GUI framework I'd use than writing the functional part of the app itself.
Any input from people wiser and more experienced than me would be appreciated :)
First and foremost, start simple. There's a lot to the subject. If you are finding it hard, don't try and take it in all at once.
Most of the good GUI packages have tutorials. The best advice I can give is that you try each of them, or at least a couple of them. They are the best short introduction you can have to the library you choose and if they are any good they narrow down what you need to absorb at first. That will give you some basis for comparison, because they are each trying to do very similar things (and you will see some of them before you are done), but they have different feels. You will likely find you have a preference for one and that's the one to get serious with. It will also give you a sense of what's hard about GUI programming as separate from the particulars of one package, which, if you have only used one, you won't have seen. Personally I find this sort of knowledge very helpful, because it makes me less intimidated by particulars.
Here's a list of tutorials in one place, though you have likely seen them already:
Qt's tutorial
WxWidgets' tutorial
Gtkmm book. Not quite a tutorial, though there are lots of examples.
.NET tutorials, either for WinForms or for WPF.
Second, it sounds to me that you need to get some in depth understanding of the concepts of GUI programming, not just a particular library. Here there is no substitute for a book. I don't know all of them by a long shot, but the best of the bunch will not just teach you the details of a toolkit, they will teach you general concepts and how to use them. Here are some lists to start with though (and once you have titles, Amazon and Stack Overflow will help to pick one):
List of Qt books
WxWidgets book (PDF version)
There are tons of WPF and WinForms books. I can't make a good recommendation here unfortunately.
Third, take advantage of the design tools (Qt Creator, VS's form building and so on). Don't start by trying to read through all the code they generate: get your own small programs running first. Otherwise it's too hard to know what matters for a basic program and what doesn't. The details get lost. Once you've got the basics down though, Do use them as references to learn how to do specific effects. If you can get something to work in the design tools, then you can look at particular code they generate to be able to try on your own hand-written programs. They are very useful for intermediate learning.
I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally.
I second the comment of GRB here: Don't worry about this. You are going to need to learn a lot specific to the toolkit no matter which toolkit you use. But you will also learn a lot that's general to GUI programming with any of the decent toolkits, because they are going to have to cover a lot of the same ground. Layouts, events, interaction between widgets/controls, understanding timers -- these will come up in any GUI toolkit you use.
However do be aware that any serious GUI package is an investment of time. You will have a much easier time learning a second package if you decide to pick one up, but every large library has its personality and much of your time will be spent learning its quirks. That is, I think, a given in dealing with any complex subject.
I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
You do not need most of the non-GUI classes of Qt to use Qt's GUI properly. There are a handful of exceptions (like QVariant) which you'll need just because the GUI classes use them. I found you can learn those on a case-by-case basis.
Which is the easiest to learn is really going to depend on how you personally learn.
Personally, I've found Qt to be the easiest to learn so far. The GUI classes are rather nice to use, but I've found the non-GUI classes to be excellent, making it easy to avoid a lot of common issues you'd normally get with a more basic API. The documentation is excellent, IMO, as are the books, the examples, etc. It's also being very actively developed, with a few new technologies coming in the near future (like DeclarativeUI).
I've found Visual Studio/Windows API/.Net to be a good bit more complicated to learn. The API documentation on MSDN is rather complicated and not really organized in a manner that I find intuitive.
I've tried learning WxWidgets a few times, but I've never liked the API documentation.
All this is just my personal experience, YMMV of course. I'd say just dabble in all of them and see which one takes you the furthest, it won't hurt to try multiple.
As a person who learned C++ through Qt, I can only say that they work very well together. C++ purists (like I have become) will find lots of things in Qt not to their liking (the moc preprocessor, e.g., and the continued absence of exceptions for error reporting), but looking back, Qt provided a very gentle introduction to C++ for me.
And if you're like me, you throw in a handful of boost libs in each Qt project, because we want to write "real" C++, not the softened thing Qt uses :)
I would suggest wxWidgets. To me, it's pretty intuitive and looks nice.
Code::Blocks was built with it, so check that out to see if you like the graphics.
There are also a slew of bindings for wxWidgets, such as wxPython, wxErlang, and others, so if you decide to switch off of C++, you can take wxWidgets with you.
I also use wxWidgets and use it all the time for Windows-only applications (the only downside is that wxWidgets is notorious for large .exe filesizes, which may or may not be a problem for you). I found it very simple to use from the start, especially when combined with a GUI designer (personally I use wxDev-C++).
I've never used Qt, so I can't speak to its simplicity, but I doubt the difficulty is on a vastly different scale than that of wxWidgets. However, what I can say is that no matter what API you use (wxWidgets, Qt, WinAPI, etc) your code will be "locked into" that particular platform, so don't worry if you feel that learning Qt will lock you into the Qt platform (because the same thing will happen with any of those APIs).
If you're working solely on Windows however, you may want to do a few simple programs with WinAPI first. That way you have a basic understanding of the lowest level of Windows GUI programming before you move onto Qt/wxWidgets. That said, if you're really into cross-platform programming, then don't worry about that and go straight into Qt/wxWidgets.
I can't intelligently comment on the learning curve aspect, but a quick survey of StackOverflow questions shows about twice as many Visual C++ questions as Qt questions. Probably means that there is a larger support group in place for Visual C++. Might make learning it a little easier if there are more folks to help out.
No matter what you pick, I am quite sure it won't be easy and painless.
Having said that, I know that in some schools they use FLTK because they consider it relativelly easy to learn. I have never tried it.
In my everyday work I use WTL which is as close to the system as it gets while still providing some level of abstraction over pure Win32. I am not sure if I would consider it easy to learn, though, especially given the lack of documentation.
I recommend codegear C++ builder (previously known as borland C++ builder) from codegear which comes with a 30 trial. The nicest thing about it is that the GUI provides you with components that you drop onto a form in a WYSIWYG fashion and make functional by adding code to handle the events it fires. It comes with a whole bunch of compontents out of the box and you can add 3rd party components to it too, like the awesome ExpressQuantumGrid from devexpress, or write your own. It's very powerfull if you know what you're doing but intuitive enough that a beginner can write a database CRUD application in about 20 lines of very simple code.
Since nobody has mentioned it yet, for the sake of completeness, have a plug for the Fox toolkit. This is the one I used last time I did any C++ UI work of my own volition. There are also binding for this to Ruby and Python (the latter being many years out of date, though).
In general, the choice of a toolkit for self-directed work comes down to personal preferences for
the layout manager style
the event handler registration style
How native the widget set looks/can be made to look
If cross-platforming is not necessary, try .net + msvs or delphi. easy, all-in-one, no pain.
Qt is the best option for you. It's the easiest to learn, the most elegant and powerful and it is completely free.
Visual C++: This is an IDE, but it comes with its own GUI library called MFC. MFC is an old library with many quirks and it is difficult to learn and use. Many C++ programmers use it on Windows because it comes from MS, it's fast and it's free if you buy Visual C++. Since VC++ is an IDE, you can also use wxWidgets and Qt with it, although in your particular case I would recommend Qt Creator instead.
You seem to have experimented with Managed C++. Don't use that, even MS recommends that you only use Managed C++ as glue between C++ and C#.
wxWidgets: This one was a strong contender up to the day when Qt became free for commercial projects. It was always in the shadow of Qt and it is known that the documentation is not very good and the API is not as easy to learn as Qt's. Cross-platform MFC would be a good way to describe it.
C++ Builder: Borland made too many mistakes with C++ Builder and ended up getting out of the dev tools business altogether. It was a good product and I originally learned Windows GUI programming in one of the first versions, but I won't use it any more. There are better options and it is too expensive.