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

Falcorum: Oct 21, 2010

Boz0r posted:

My friend submitted the following code:
code:
std::unordered_map<int, std::shared_ptr<BNode>> map;

...

map.insert({{k,node}});
He writes in Linux and I use Visual Studio 2012. VS won't compile the insert call. Is this a correct method call, and if so, why doesn't it compile in VS?

It's valid syntax, but it uses initializer lists and uniform initialization (both are part of C++11) and VS2012 doesn't support either of those.

# ¿ Sep 29, 2013 12:18

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 14:12

Falcorum: Oct 21, 2010

More a curiosity than a real question but, why is it that the following doesn't give the same results in VS and GCC?

C++ code:

void foo() {}
template<typename T> void bar() {}

template<typename FN>
void qualFoobar(const FN& proc)
{
cout << is_pointer<FN>::value << " " << is_function<FN>::value << " " << is_function<typename remove_pointer<FN>::type>::value << " " << typeid(FN).name() << endl;
}

template<typename FN>
void unqualFoobar(FN proc)
{
cout << is_pointer<FN>::value << " " << is_function<FN>::value << " " << is_function<typename remove_pointer<FN>::type>::value << " " << typeid(FN).name() << endl;
}

qualFoobar(&foo);
qualFoobar(&bar<int>);
unqualFoobar(&foo);
unqualFoobar(&bar<int>);

It returns the following in Visual Studio:

code:

Ptr	Func	FuncWithoutPtr	Typeid
1	0	1		void (__cdecl*)(void)
0	1	1		void __cdecl(void)
1	0	1		void (__cdecl*)(void)
1	0	1		void (__cdecl*)(void)

Whereas in GCC, the 4 are exactly the same. Is this due to VS's lack of two phase lookup or something?

# ¿ Sep 3, 2014 13:52

Falcorum: Oct 21, 2010

Technically, you could get a typesafe stdio now that variadic templates exist. The odds of that happening (at least in a standard way) are pretty slim however.

# ¿ Oct 19, 2014 17:40

Falcorum: Oct 21, 2010

On the plus side, there's a couple reflection proposals for C++17 so in a couple years you might have access to them (or a decade or so if you're using MSVC).

# ¿ Jan 16, 2015 15:06

Falcorum: Oct 21, 2010

Spatial posted:

Woohoo, I made a template function for hierarchical sorting by class member.

Variadic template syntax is preeeeetty bad when you need to do something even mildly complicated. It would be so much easier to use an non-recursive mechanism in many situations. Some kind of "generate" syntax like Verilog maybe.

But finally I can do:
C++ code:
auto comp = makeHierarchicalMemberComparator( &Type::first, &Type::second, &Type::third );
std::sort( container.begin(), container.end(), comp );

If you don't mind using experimental features (and the compiler you're using supports it), constexpr if makes working with variadic templates a fair bit less cumbersome.

# ¿ Jul 1, 2017 23:12

Falcorum: Oct 21, 2010

xgalaxy posted:

Honestly I think knowing what flavor of the month javascript libraries and frameworks to use + all the different ways you can do module imports is more difficult than memorizing how memory management works in C and C++.

It's funny. Javascript people can invent 1000+ ways of importing functions and objects AND implement them and C++ people can't even agree if modules should include macros.

I hate it when my module imports segfault.

# ¿ Jun 3, 2018 19:09

Falcorum: Oct 21, 2010

Has anyone managed to use Visual Studio's experimental module stuff for anything more than a toy sample? I'm often hitting issues with already defined symbols when importing std.core (when not hitting ICEs). Latest issue I ran into included complaining that operator new was ambiguous when allocating a std::string. :v:

Edit: So a lot of the issues I've found seem to boil down to Microsoft's implementation of modules interacting oddly when you're also using headers sometimes. Avoiding a blanket import std.core and #include'ing the standard bits you use seems to help in a lot of situations. Still haven't managed to get things using libfmt to compile without ICEs however.

Falcorum fucked around with this message at 15:23 on Aug 26, 2018

# ¿ Aug 25, 2018 21:37

Falcorum: Oct 21, 2010

After spending ages working exclusively with OpenGL as a hobbyist and then switching to using DirectX professionally, I wouldn't recommend OpenGL to anyone at this point.
Sure, it's "easy" to get something onscreen but as soon as you start looking into more advanced stuff you get hit with a wave of "there's 3 different ways to do this and they're all different flavours of deprecated" in a lot of scenarios. DirectX 11/12/Vulkan are simply massively cleaner and the initial setup verbosity will be more than made up for the less time spent wondering how to use feature X or why it doesn't work as you'd expect.

As an aside, the debugging tools for DX11/12/Vulkan are also a hell of a lot better than OpenGL's (granted, mostly due to extension support often being hit or miss) and you should look into Renderdoc if you're starting graphics programming on PC since it will let you figure out what the hell the GPU is doing more easily.

# ¿ Sep 9, 2018 10:10

Falcorum: Oct 21, 2010

My adventures in C++ modules finally came to an end. Not because the early implementations are sketchy (and oh boy, are they, lots of "why is this causing an ICE" moments, which thankfully I could mostly work around easily), but because build system support is nearly non-existant and I don't feel like dealing with setting up half a dozen libraries manually + this project using modules.

I was using build2 since it has module support, but the final nail in the coffin was when I spent about 2-3h trying to get glfw to build as a project dependency, then had to change some of its code, and when I finally got it building, it was trying to link glfw.lib.lib instead of glfw.lib. Fixing that then caused the linker to error, claiming it was a malformed library file. :shrug:

Edit: The only really annoying bit I found while working with modules was the lack of something like the stuff proposed in the source code info capture paper. Since you can't export macros, you have no real way of doing logging that includes the message origin file and line through modules alone, you have to create a header that exports a macro like that and then gets included along every module that wants to use your logging system for example.

Falcorum fucked around with this message at 17:20 on Oct 17, 2018

# ¿ Oct 17, 2018 17:13

Falcorum: Oct 21, 2010

Absurd Alhazred posted:

To be fair, C++ still doesn't have good strings - only many mediocre ones.

C++ somehow manages to have a string class that's both overengineered and also heavily lacking featurewise.

And then at work, we ended up making a string class that's worse. Strings are hard. :shrug:

Slurps Mad Rips posted:

The modules TS was kind of a poo poo show. Boris (author of build2) disagreed with me on it last year but I raised hell all over and we�re getting merged ATOM/Modules TS proposal, and even he has come around on a few arguments I made (he recently converted to wildcard patterns for source inclusion and was against them for a time). There�s a few other papers at San Diego coming up in November (I�m presenting two) and if we can get at least one of them in life will be easier. Richard Smith is also working on improving the macro situation. Right now with the current proposals, macros affect the preamble (the part where you say module and place all your imports) but to improve life for build systems we might have it so macros aren�t expanded within the preamble.

One of my papers is a recommendation for implementors about treating a directory of files as the focus of a module (we�re going to have the concept of a �module partition� in whatever version we get) so you can just pass a directory to a compiler to get the precompiled module interface out, then use that when compiling for all the object files. Build systems still have to do a bit of work, but it�s less, and compiler vendors don�t have to turn their compiler into a build system.

Macros not being expanded within the preamble seems entirely reasonable. To be honest, right now most of my uses (both at home and at work) for macros are 1) controlling/exposing platform specific code 2) source-code location 3) #include hackery for things like enum to string and simplifying repetitive code. The need for 2 and 3 should be going away soon hopefully with static reflection and library fundamentals 2. 1 seems like a case where attributes would potentially be a good fit but can be solved (somewhat, datatypes are still problematic if you have to expose them) through constexpr-if right now.

Module partitions sounds good as well and seems like it would make the whole thing more in line with other recent module systems.

# ¿ Oct 21, 2018 12:47

Falcorum: Oct 21, 2010

Jabor posted:

Here's how you do it in Java:
code:
Man m = new Man(
  /* heightInFeet= */ 6,
  /* weightInPounds= */ 140,
  /* iq= */ 127);
And then a static analyser runs at compile time and checks that the names in the comments actually match up with the parameter names.

No reason you couldn't do exactly the same thing in c++.

Embedding "code" in comments should be reserved for the coding horror thread.

# ¿ Nov 30, 2018 12:06

Falcorum: Oct 21, 2010

fritz posted:

The 2d graphics guys are talking audio now : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1386r0.pdf

Call me when they propose a physics engine instead.

# ¿ Mar 10, 2019 17:47

Falcorum: Oct 21, 2010

pseudorandom name posted:

Which compilers aren't smart enough to do this for you?

Never expect a compiler to be smart enough to do something for you, and never expect the compiler to not be dumb enough to gently caress things up royally.

We've spent the past 2 weeks at work dealing with sporadic bad code gen issues since we've upgraded to a newer compiler version. :v:

# ¿ Mar 27, 2020 22:22

Falcorum: Oct 21, 2010

taqueso posted:

Is modern STL appropriate for gamedev? Back in the day, there were good reasons to roll your own almost everything. I haven't been paying a ton of attention but it seems like there have been a lot of improvements.

It's mostly ok nowadays, but it has some issues that won't be solved due to ABI (hash map perf), and lacks built-ins that would be useful for gamedev (fixed-size, stack, and bucket containers/allocators for example, as well as guaranteed non-allocating versions of std::function). Most of the current big implementations are also loving horrible to use in debug builds due to iterator overhead (may seem like a small issue, but if you actually need a debug build, you'll appreciate it running at more than 5 FPS).
Basically, you can use it until it becomes an issue, and then write alternatives when it does. There's a few bits that generally won't be obsolete for gamedev purposes: type traits, threading primitives, filesystem, and algorithms depending on whether your hand-rolled containers support the various iterator concepts.

Also, code involving C++20 ranges will never pass code reviews. :v:

Falcorum fucked around with this message at 22:43 on Apr 26, 2020

# ¿ Apr 26, 2020 22:36

Falcorum: Oct 21, 2010

Xarn posted:

After doing the above, it is simpler to just write your own everything, or use 3rd party.

The good news is this won't happen with std::audio, std::network, or std::graphics.

# ¿ May 17, 2020 19:09

Falcorum: Oct 21, 2010

matti posted:

An aggressively optimizing compiler (I'm talking of GNU) is allowed to assume that signed integers never overflow and so may optimize out conditionals that'd check for it beforehand.

Now that I've had time to ponder it a bit more clearly (lol as if) I realize it's not an issue here and I'm home safe I think.

thanks for letting me rubber duck a lil

If you're worrying about compiler optimisations, it's always worth testing and finding out. In general it tends to be the less obvious "the compiler can optimise this" that'll catch you.

Had a fun one where we had classes A1, A2, A3, A4 and the only difference between them was changing what some of the methods did, and since all the methods were inline-able and the class signatures were identical, MSVC just decided to elide all of them except one. That took forever to track down since things still mostly worked except for the occasional crash because it should have accessed one of the other functions.

# ¿ Sep 18, 2020 08:41

Falcorum: Oct 21, 2010

More of a MSBuild question but since this is related to modules, this seemed like the best place for it - anyone using modules and %(RelativeDir) in MSBuild's output dirs by any chance? I've got a project where I'm trying to do that however that results in an error during module dependency scanning complaining TrackerLogDirectory isn't the same for all files (looks like it outputs them to Path\%(RelativeDir), without actually replacing.

I've got the project compiling and linking properly by adding this to the PropertyGroup section, essentially overriding the directory used for .tlog files:

code:

        <TLogLocation>$(MSBuildThisFileDirectory)build\tmp\$(Platform)\$(Configuration)\$(MSBuildProjectName)\</TLogLocation>
        <TLogLocation_ModuleDependencies>$(MSBuildThisFileDirectory)build\tmp\$(Platform)\$(Configuration)\$(MSBuildProjectName)\</TLogLocation_ModuleDependencies>

However this seems to break minimal rebuilds, looking over diagnostics it claims all files are up to date but then the compilation commands differ between the previous and the current run so they get compiled again (as far as I can tell, the 'previous' commands include direct references to dependant IFCs but the 'current' commands don't). I'll probably just remove the need for using %(RelativeDir) in the first place, but I'm wondering if I'm missing anything or if I'm just hitting a bug/NYI path.

edit: Annnnd I've figured it out, TLogLocation_ModuleDependencies has to differ from TLogLocation (probably should have guessed that earlier on :v:

Falcorum fucked around with this message at 17:51 on Oct 30, 2021

# ¿ Oct 30, 2021 17:26

Falcorum: Oct 21, 2010

Does anyone know of a place with actual documentation/information on generating LLVM debug information using its C++ API? I've been writing my own language and while I'm used to LLVM's poor documentation, information on generating debug info seems mostly non-existent besides its doxygen and a single, very brief section in the Kaleidoscope tutorial.

I'm guessing I'll end up having to go through the LLVM sources to figure out how that stuff actually works, but figured I'd ask first. :v:

Falcorum fucked around with this message at 23:23 on Jun 13, 2022

# ¿ Jun 13, 2022 20:36

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 14:12

Falcorum: Oct 21, 2010

Absurd Alhazred posted:

Maybe that person should have called it an "embedding concept" and it would have gotten more votes.

Call it embeddable textual/binary ranges and then you get at least one element of "ranges" that is actually useful and doesn't balloon compile times

Falcorum fucked around with this message at 18:45 on Aug 15, 2022

# ¿ Aug 15, 2022 18:37

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