TOML for Modern C++
marzer.github.io
TOML for Modern C++
1–10 of 48 posts
Re: TOML for Modern C++
#2I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
Re: TOML for Modern C++
#3I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
It's a header-only library, it would effectively add "using" statements anything that included the library.
Re: TOML for Modern C++
#4I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
Besides the header issue mentioned in the sibling, sometimes the context is important too, for an example from Python, no one would `from os.path import join`— you always use `os.path.join` in its entirety.
Re: TOML for Modern C++
#5I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
Besides the header issue mentioned in the sibling, sometimes the context is important too, for an example from Python, no one would `from os.path import join`— you always use `os.path.join` in its entirety.
[deleted]
Re: TOML for Modern C++
#6I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
You could do that in .cpp files, but it's objectively bad to do so in the header files due to namespace pollution. And now you have an inconsistency between headers and .cpp files..
Re: TOML for Modern C++
#7> C++17
> Works with or without exceptions
Is anyone using C++17 features with exceptions disabled? I thought the “no exceptions” people were generally only using C++ as C-with-classes?
Re: TOML for Modern C++
#8> C++17 > Works with or without exceptions Is anyone using C++17 features with exceptions disabled? I thought the “no exceptions” people were generally only using C++ as C-with-classes?
All of Google's codebase, including Chromium, is OO C++ without exceptions.
https://google.github.io/styleguide/cppguide.html#Exceptions
Re: TOML for Modern C++
#9I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
It's a header-only library, it would effectively add "using" statements anything that included the library.
Ouch. Seems like an unsolvable limitation at this point. Nice catch.
Re: TOML for Modern C++
#10I don't get why C++ programmers like to keep the namespace prefixes around. I'd just add lots of "using ..." statements and make my code more readable. What's the chance of conflicts anyway when you are already dealing with a tiny fraction of the code in the current file?
Besides the header issue mentioned in the sibling, sometimes the context is important too, for an example from Python, no one would `from os.path import join`— you always use `os.path.join` in its entirety.
I agree with your point and I'm just nit picking, but `from os import path` and `path.join` is pretty acceptable too.