|
Star War Sex Parrot posted:I don't really find myself mixing C and C++ libraries very much, but I think if you want to use the C STL in C++ you should to include it as <cstdlib>, not <stdlib.h> So stdfax isn't necessary? I never saw it when I used VS 2008. Are .h files necessarily C files? Should I not be creating .h files of my own, is there some other format that would be better?
|
#
?
Nov 6, 2015 21:36
|
|
|
|
| # ? Jun 7, 2024 11:10 |
|
|
22 Eargesplitten posted:Are .h files necessarily C files? Should I not be creating .h files of my own, is there some other format that would be better? C++ header files are often named with .h, sometimes with .hpp. Using .h is traditional and fine, even though you could sperg out and argue .hpp is "better" (which I would do, personally). (I mean, if you open a .hpp, your editor knows how to syntax highlight it!) (And in general, a multi-file C++ project should definitely have header files.)
|
|
#
?
Nov 6, 2015 21:43
|
|
|
stdafx is your project's precompiled header, you stick stuff in there that you're going to want included in every single file. .h is C or C++; most standard headers just leave off the extension. In the end all an include is doing is just text substitution so it doesn't matter what you name them (they don't have a "format") I've heard good things about Qt but I've never actually done any work in it myself. It's probably better to learn Qt than MFC though.
|
|
#
?
Nov 6, 2015 21:45
|
|
|
22 Eargesplitten posted:So stdfax isn't necessary? I never saw it when I used VS 2008. Precompiled headers isn't required no, but Microsoft's C++ project file generator likes to set it up by default, and it's slightly annoying to remove again afterwards. I think they name the precompiled header file "stdafx" because it's supposed to just contain standard library headers, but not sure.
|
|
#
?
Nov 6, 2015 21:56
|
|
|
They named it stdafx.h because pre-release MFC was called AFX and precompiled headers were added to make MFC application compile times not be completely terrible.
|
|
#
?
Nov 6, 2015 22:00
|
|
|
Star War Sex Parrot posted:I don't really find myself mixing C and C++ libraries very much, but I think if you want to use the C STL in C++ you should to include it as <cstdlib>, not <stdlib.h> Both of the stdfoo.h and cstdfoo headers are required to exist in C++, the only difference is that cstdfoo is required to export globals in the std namespace, and stdfoo.h is required to export them in the global namespace. They can also optionally export things in the other namespace (IIRC, libc++ and libstdc++ both have cstdfoo exporting in both std and : 
|
|
#
?
Nov 6, 2015 22:12
|
|
|
Qt is kind of worryingly heavyweight but it works pretty well and is easy enough to use in general. No idea what specific quirks there might be on windows, let alone when trying to use VS.
|
|
#
?
Nov 7, 2015 08:11
|
|
|
Dessert Rose posted:I've heard good things about Qt but I've never actually done any work in it myself. It's probably better to learn Qt than MFC though. It's good! really good! Can't really comment on the graphics/UI part because I'm using it on a platform (BlackBerry Native) which has its own UI framework (Cascades) specifically incompatible with Qt's standard UI, but the whole QObject framework is very powerful and its message-passing makes multithreading and structuring your application into independent components painless. Its various container/data classes are pretty good too, as they're all based on shared copy-on-write storage and they can be copied in O(1) time (very important in pre-rvalue reference C++); the containers are STL-compliant too. Yes, it has its own project file format and several mandatory non-standard build tools, and I never used it in Visual Studio, so I can't comment on how well it integrates with it, but code-wise it's a solid choice MFC is the best choice for Windows and has the best integration with Visual Studio (Visual Studio and MFC are virtually designed for each other), but it's Windows-only hackbunny fucked around with this message at 14:29 on Nov 7, 2015 |
|
#
?
Nov 7, 2015 14:25
|
|
|
hackbunny posted:MFC is the best choice for Windows and has the best integration with Visual Studio (Visual Studio and MFC are virtually designed for each other), but it's Windows-only
|
|
#
?
Nov 7, 2015 19:15
|
|
|
There are Qt 4 and Qt 5 add-ins for VS that automatically handle the extra tooling. It generally works pretty well (I use it at my job where all of the Windows builds of our Qt applications are built with VS2013; I generally prefer MinGW otherwise) and you get the added benefit of not having to torture yourself with Windows-specific frameworks.
|
|
#
?
Nov 7, 2015 19:51
|
|
|
Also, and I guess this is getting way too complex for OP, you can use CMake to set up your project. It has support for Qt and will automatically generate Visual Studio .vcxproj and .sln files that invoke all the right Qt tools during build.
|
|
#
?
Nov 9, 2015 09:56
|
|
|
roomforthetuna posted:Counterpoint: MFC is loving awful and it's less painful to just use the old WINAPI C API for Windows stuff than to let MFC force your project into the hideous macro-ridden shape it prefers. Counter-counter point: all StashAugustine is trying to do is jam together a simple UI for a class project so presumably he/she doesn't care about the hand-waving generated macros aspects of MFC. Visual Studio makes it relatively painless to make a new MFC project and get you going in the dialog designer. I'm guessing that learning the Win32 windows API from RegisterClass/Ex to CreateWindow/Ex and all that good poo poo is not on the class syllabus.
|
|
#
?
Nov 9, 2015 15:19
|
|
|
What is a nice and sane C++ concurrency library? This means higher level than <thread>, <mutex> et al. and less macroy than OpenMP pragmas. Bonus points if it runs on Windows as well as on Linux.
|
|
#
?
Nov 9, 2015 16:19
|
|
|
csammis posted:Counter-counter point: all StashAugustine is trying to do is jam together a simple UI for a class project so presumably he/she doesn't care about the hand-waving generated macros aspects of MFC. Visual Studio makes it relatively painless to make a new MFC project and get you going in the dialog designer. I'm guessing that learning the Win32 windows API from RegisterClass/Ex to CreateWindow/Ex and all that good poo poo is not on the class syllabus. And I say this as someone who learned the MFC way first, so it's not like I was just clinging to what I was used to. Switching to WinApi was a relief. Though to be fair, it might be partly my preference for drop-down menus that you can't snap off your program and put somewhere else. WinApi menus behave old school by default, MFC menus you have to dig through documentation and find out how to turn off all the sparkly modern bullshit if you don't want it.
|
|
#
?
Nov 9, 2015 16:34
|
|
|
Why would I be getting an internal compiler error on a piece of code I've compiled with the exact same compiler hundreds of times before? I'm using g++ 4.9.something on MinGW64. On my current project I'm suddenly getting errors on an include of <vector> that seems to refer me to their implementation of initialiser lists. It's telling me to file a bug report to the mingw team, but I'm not sure how it can suddenly become bugged from one day to the next. My code base is literally the same as I succesfully compiled on the same system just two days ago.
|
|
#
?
Nov 9, 2015 17:00
|
|
|
Xarn posted:What is a nice and sane C++ concurrency library? This means higher level than <thread>, <mutex> et al. and less macroy than OpenMP pragmas. Joda posted:Why would I be getting an internal compiler error on a piece of code I've compiled with the exact same compiler hundreds of times before? I'm using g++ 4.9.something on MinGW64. On my current project I'm suddenly getting errors on an include of <vector> that seems to refer me to their implementation of initialiser lists.
|
|
#
?
Nov 9, 2015 17:40
|
|
|
Xarn posted:What is a nice and sane C++ concurrency library? This means higher level than <thread>, <mutex> et al. and less macroy than OpenMP pragmas. Maybe check out Intel TBB? It's not to everyone's tastes, but I recall being generally happy with it.
|
|
#
?
Nov 9, 2015 17:45
|
|
|
Ralith posted:Maybe something clobbered your environment variables? Far as I can tell they point to the versions of g++ and gcc they always have. I did try and redirect them to a fresh mingw download and now it works though, so I dunno. I might have accidentally edited the C++ standard libraries or something.
|
|
#
?
Nov 9, 2015 18:22
|
|
|
Sagacity posted:Also, and I guess this is getting way too complex for OP, you can use CMake to set up your project. It has support for Qt and will automatically generate Visual Studio .vcxproj and .sln files that invoke all the right Qt tools during build. Honestly CMake is great, it took me maybe an hour to get it working, and it's definitely worth spending that hour learning CMake instead of makefiles. Builds look much nicer, you can autogenerate Xcode, VS and I assume Eclipse project files, the format isn't nearly as brain damaged... Much like learning Qt and C++ in the first place, learning CMake will allow you to apply your knowledge across all platforms instead of tying yourself to one or two.
|
|
#
?
Nov 9, 2015 20:20
|
|
|
Dessert Rose posted:Honestly CMake is great, it took me maybe an hour to get it working, and it's definitely worth spending that hour learning CMake instead of makefiles. I favor the "Eclipse CDT4 - Ninja" generator, even on OS X – I find the Xcode generator is pretty much trash. Perhaps it's because Xcode's native build system is..."unique". CMake seems pretty arcane and obtuse at times, but even so, the developer experience with it is well ahead of everything else I've tried for C++ (aside from developing for Apple platforms on a Mac).
|
|
#
?
Nov 10, 2015 00:31
|
|
|
Build system chat: I ultimately just gave up and hand-rolled a python script to produce ninja files. Maybe Bazel will become good someday. Tup's pretty neat in a gimmicky kind of way, but it relies heavily on magic and is basically just one guy and he makes some weird design decisions.
|
|
#
?
Nov 10, 2015 02:50
|
|
|
Could you go into more detail on what Bazel's lacking? (Half of my code at work builds in blaze, so I've been considering it for my home projects. ATM, I'm using jam.)
|
|
#
?
Nov 10, 2015 08:31
|
|
|
It doesn't play well with dependencies from the host system (because you can't sanely call pkg-config or similar) and as far as I can tell it's not realistic to vendor all your dependencies the way Google does with Blaze (because they'll have non-Bazel build systems and you really don't want to maintain your own build system of third party code). This leaves you with a build system that's only useful for projects without significant dependencies, and for projects without significant dependencies you can probably get away with a simple shell script anyway. It's also really awkward to use anything but the exact toolchain configuration that some engineer at Google assumed everybody would always want, because it relies on these great big sparsely-documented toolchain definition files. For example, I like to use clang 3.7 with libc++ on linux, but by default Bazel will have none of that. In general, doing anything off the beaten path (say, calling out to custom tools) rapidly lands you in territory with little if any documentation. Note also that the beaten path is almost entirely Java-related. My understanding is that they're working on fixing the first issue, at least, so maybe someday it'll be the cmake killer we all want, but it's not there yet and Google might just decide to abandon the effort before it gets close. Even ignoring all those issues, though, it's still a huge enterprisey java project with bad startup times and tons of its own dependencies and so forth. Not really what I want in a fundamental build tool. Ralith fucked around with this message at 09:13 on Nov 10, 2015 |
|
#
?
Nov 10, 2015 09:10
|
|
|
Ralith posted:Even ignoring all those issues, though, it's still a huge enterprisey java project with bad startup times and tons of its own dependencies and so forth. Not really what I want in a fundamental build tool. bazel and other heterogenous build systems are beastly because they solve problems that you don't really encounter in personal development. google at least has the simplicity of only building HEAD of a single omni-repository.
|
|
#
?
Nov 10, 2015 14:18
|
|
|
Bazel probably won't ever become useful for things where you don't completely control the build environment. The set of problems that portable build systems try to solve and the set of problems that things like Bazel try to solve are almost entirely disjoint.
|
|
#
?
Nov 10, 2015 19:41
|
|
|
It's worth noting that completely controlling the build environment is generally a great idea, especially for larger projects. It's just that right now, say, Nix (or even just a pile of shell scripts) does a better job of that than Bazel for anyone who isn't Google.
|
|
#
?
Nov 10, 2015 20:07
|
|
|
I'm trying to implement a program using restricted transactional memory, but I'm consistently getting an 'illegal instruction (core dumped)' error when running any program using the _xbegin() call. I'm working off've the stuff here, using g++ 4.9, and compiling like so:code:code:
|
|
#
?
Nov 10, 2015 20:13
|
|
|
What CPUs are you testing on?
|
|
#
?
Nov 10, 2015 20:19
|
|
|
my local machine is: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz I'm also testing on some servers my school provides which have: AMD Opteron(tm) Processor 6172
|
|
#
?
Nov 10, 2015 20:30
|
|
|
Subjunctive posted:Maybe check out Intel TBB? It's not to everyone's tastes, but I recall being generally happy with it. TBB is what I definitely plan on checking out, but I was looking for alternatives. Ralith posted:What exactly do you want it to do for you? Give a reasonably simple task oriented interface... IE being able to chain tasks, not having to explicitly manage threads for simple async stuff.
|
|
#
?
Nov 10, 2015 20:37
|
|
|
JawKnee posted:my local machine is:
|
|
#
?
Nov 10, 2015 20:40
|
|
|
well poo poo. Not sure where my professor expects me to test this stuff then.
|
|
#
?
Nov 10, 2015 20:41
|
|
|
Neither of those CPUs support the TSX instructions. You need to use CPUID to detect if they're available on your CPU before you try to call them. e: ^^^ You need a machine with one of the new Skylake processors -- Core 6xxx. Depending on stepping, some of the Core i5-5xxx models may have it. ullerrm fucked around with this message at 20:45 on Nov 10, 2015 |
|
#
?
Nov 10, 2015 20:42
|
|
|
Ralith posted:It's worth noting that completely controlling the build environment is generally a great idea, especially for larger projects. It's just that right now, say, Nix (or even just a pile of shell scripts) does a better job of that than Bazel for anyone who isn't Google. For purely internal software, absolutely. For anything intended to be built and run by third parties on their machines it's not really an option.
|
|
#
?
Nov 10, 2015 22:59
|
|
|
With Visual Studio's weird file specifying a file to hold header imports thing, is there a recommended compiler other than VS? From the sound of it, Microsoft is encouraging some weird stuff that nobody else does with that file.
|
|
#
?
Nov 11, 2015 00:04
|
|
|
JawKnee posted:well poo poo. Not sure where my professor expects me to test this stuff then. Support for TSX emulation is provided as part of the Intel Software Development Emulator.[11] There is also experimental support for TSX emulation in a QEMU fork.[12]
|
|
#
?
Nov 11, 2015 00:13
|
|
|
The only thing remotely unusual about visual studio's use of a precompiled prefix header is that it's set up by default in new projects. It's trivial to turn off and all mainstream compilers support it.
|
|
#
?
Nov 11, 2015 00:13
|
|
|
Plorkyeran posted:The only thing remotely unusual about visual studio's use of a precompiled prefix header is that it's set up by default in new projects. It's trivial to turn off and all mainstream compilers support it. MSPCH is a strange beast, but the least unusual thing about it is that it exists. The most unusual part? Probably #pragma hdrstop.
|
|
#
?
Nov 11, 2015 02:06
|
|
|
Plorkyeran posted:For purely internal software, absolutely. For anything intended to be built and run by third parties on their machines it's not really an option.
|
|
#
?
Nov 11, 2015 02:32
|
|
|
|
| # ? Jun 7, 2024 11:10 |
|
|
Speaking of build stuff, why is it that the Unix-like solution to static libraries is still to throw all of the .o files into an archive instead of doing something like running it through the linker to generate a new ELF file and nuke all of the ODR redundancies?
|
|
#
?
Nov 12, 2015 01:50
|
|
