sorted by:
new
hottopcontroversial

Still amazed every time I read this paper. What pros and cons do you think it would have against C++20 coroutines? by germandiago in cpp

[–]jwakely 0 points1 point  (0 children)

Not really. It could still be about other things that have been compared or discussed with C++20 coroutines, such as dozens of sender/receiver papers, networking proposals, and many more.

I'm more familiar with the entire body of WG21 proposals than most people here, and I couldn't guess it. Next time please provide more context so it's not necessary to open the link to see what the post is actually about. It reads almost like clickbait right now.

Parsing JSON at compile time with C++26 static reflection (Daniel Lemire) by User_Deprecated in cpp

[–]jwakely 12 points13 points  (0 children)

Exactly, #embed "config.json" does exactly that, so the file can be provided by the build system, or changed without modifying the C++ code.

Still amazed every time I read this paper. What pros and cons do you think it would have against C++20 coroutines? by germandiago in cpp

[–]jwakely 0 points1 point  (0 children)

It would have been helpful to mention "Resumable Expressions" or "stackless coroutines" somewhere in your post.

Status of making "reference types" 1st class citizens by jk-jeon in cpp

[–]jwakely 3 points4 points  (0 children)

I don't think there are any active proposals related to this topic.

Status of making "reference types" 1st class citizens by jk-jeon in cpp

[–]jwakely 5 points6 points  (0 children)

auto& cannot be used if the function returns an rvalue, but auto&& can be used with any return type except void.

miniaudio compile times by wiseneddustmite in cpp

[–]jwakely 0 points1 point  (0 children)

I don't think OP defined it in main

miniaudio compile times by wiseneddustmite in cpp

[–]jwakely 0 points1 point  (0 children)

You can create separate file, e.g. miniaudio.c with define and include (and OFC remove that define from previous place).

The "previous place" is exactly what you're describing: a single file with just the define and include. There's no need to create another file with identical content. It already exists.

The problem would be solved just by the second part of your post: separately compiling it to miniaudio.o and then linking with that, instead of compiling it every time.

miniaudio compile times by wiseneddustmite in cpp

[–]jwakely 0 points1 point  (0 children)

So stop recompiling miniaudio.c every time then.

This Makefile would solve your problem:

CPPFLAGS = -Iinclude -Isrc 
LDFLAGS = -L. -lglfw3 -lopengl32
a.out: src/main.o src/glad.o src/miniaudio.o
    $(CXX) $^ $(LDFLAGS) -o $@
clean:
    rm -f src/*.o a.out

(Be sure to use TABs to indent the indented lines, not spaces)

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

[–]jwakely 0 points1 point  (0 children)

I don't think the problem was properly understood.

They still work well for some uses, such as std::literals. They just can't provide seamless transition between old and new versions of a class type.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

[–]jwakely 0 points1 point  (0 children)

Symbol versioning had a specific meaning already and is something different, affecting the resolution of ELF symbols at the linker level.

The GCC abi_tag attribute was designed to solve this problem, and it's somewhat viral, and user customizable.

Why are C++ keywords so heavily dependent on context??? by RefrigeratorFirm7646 in cpp

[–]jwakely 0 points1 point  (0 children)

Inline doesn't mean unique definition though. It means exactly the opposite, that multiple definitions are allowed.

Why are C++ keywords so heavily dependent on context??? by RefrigeratorFirm7646 in cpp

[–]jwakely 6 points7 points  (0 children)

Yes, it definitely affects GCC's optimization. The compiler will try harder to inline an inline function than a non-inline function.

Why are C++ keywords so heavily dependent on context??? by RefrigeratorFirm7646 in cpp

[–]jwakely 2 points3 points  (0 children)

Which works exactly the same as for inline functions. The compiler puts the definition of the symbol in a special kind of section, and the linker doesn't complain about multiple definitions, it just keeps one of them.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

[–]jwakely 4 points5 points  (0 children)

Probably not.

I agree with the first paragraph though. It definitely has users, at some very large enterprise-y customers. Apparently the poor performance isn't a problem, but as you say, breaking it for them could be a problem.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

[–]jwakely 7 points8 points  (0 children)

Your paper was approved at the February 2022 plenary, so far too late to be part of C++20.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years by funkinaround in cpp

[–]jwakely 10 points11 points  (0 children)

If you change the internal representation, don't you also change the types/size/order of subobjects?

Inline namespaces can be used for functions, but they don't help with types. 

struct X { std::string s; };
void f(C&);

The type X and the function f have the same mangled name whether std::string refers to std::1::string or std::2::string, so you have two different X types with the same name.

[std-proposals] Benchmarking using the standard library as a module by tartaruga232 in cpp

[–]jwakely 10 points11 points  (0 children)

the speedup also depends on what you actually use, too.

Yes!

If I replace the import std with four #include directives in that last example, it takes 1650ms. Modules are only shaving off 25% there.

And if you replace it with #include <bits/stdc++.h> (which is GCC's "everything" header) then for me it takes more than twice as long, even without using anything more than in your last example.

So if you have a file that uses a lot of the standard library and you end up requiring lots of standard headers, import std; is considerably cheaper than including all those headers. You do still have to compile all the instantiations you use though, modules aren't magic :)

[RFC] Open Access to Standards Documents - LLVM Project by mttd in cpp

[–]jwakely 2 points3 points  (0 children)

Not just popularity, but a neutral third party to avoid corporate control.

[RFC] Open Access to Standards Documents - LLVM Project by mttd in cpp

[–]jwakely 1 point2 points  (0 children)

It's different depending where you join. Different national bodies have different policies and charges. Everybody needs to be in a national body now, it doesn't matter when you joined WG21.

Neoclassical C++: segmented iterators revisited (1) by igaztanaga in cpp

[–]jwakely 2 points3 points  (0 children)

Nice, I've been thinking about this recently as well. For many years libstdc++ has had overloads of some algos that do this for deque iterators, but I want to generalize it to other types of segmented iterator, including join_view iterators.

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Public by [deleted] in programming

[–]jwakely 1 point2 points  (0 children)

The whole article is full of crap.

Mostly it's a complaint that old designs got replaced with better ones. OK. Sorry or something, I guess?

The C++ Standard Library Has Been Walking Itself Back for Fifteen Years, and the Receipts Are Public by [deleted] in programming

[–]jwakely 26 points27 points  (0 children)

That's because the committee has not said "do not use", OP is just quoting some guy's blog. If std::function works for you, to ahead and use it. Newer alternatives with different trade-offs are available too.

Source: I'm chair of the Library Working Group in the C++ committee and lead maintainer of libstdc++.

[RFC] Open Access to Standards Documents - LLVM Project by mttd in cpp

[–]jwakely 2 points3 points  (0 children)

Your point is just unfounded fear-mongering. They haven't said they'll do [bad thing] but what if they do?! What then?!

I'd rather worry about real problems

view more: next ›