This isn't really C, though. It's "Clang C" - which is arguably better than C, and I wouldn't want to be stuck writing non-Clang C, but it should be represented correctly.
The headline has since been fixed to mention Clang or GCC with Blocks.
Emulating Swift's “defer” in C, with Clang or GCC+Blocks
21–30 of 33 posts
Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#22C++ supports this sort of thing directly. It says something about C++ takeup that anyone would bother adding this kludge to C. Many people are scared of C++. The language has become incredibly complex.
C++ templates are Turing-complete. You can do arbitrary computation at compile time. Once this was discovered, ever-fancier templates became a basic part of C++. (Take a look at the huge templates that implement "max" and "min".) Then the C++ standards committee went off into template la-la land, focusing on adding features to make the template system more powerful. After a decade of this, many standard templates are now at the "you are not supposed to understand this" level.
This has scared people off of C++, which is why there's still much work in standard C. So now we're seeing features added to C to solve specific problems, but without an architecture.
"Defer" is troublesome, because dealing with errors in deferred statements is hard. C++ has the same problem with destructors. A "with" clause, which LISP introduce as "with-open-file" and Python also supports, is a better way to do this. Python's combination of "with" and exception handling can handle an error when closing out a resource, and get all the nested resources closed out properly. Few other languages even try to get that right.
Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#23C++ supports this sort of thing directly. It says something about C++ takeup that anyone would bother adding this kludge to C. Many people are scared of C++. The language has become incredibly complex. C++ templates are Turing-complete. You can do arbitrary computation at compile time. Once this was discovered, ever-fancier templates became a basic part of C++. (Take a look at the huge templates that implement "max"…
Not touching on the rest of what you said, but what's so bad about min? Apart from some internal clang stuff, like odd names and macros, it looks okay - I can see what the function is doing.
// min
template
inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
const _Tp&
min(const _Tp& __a, const _Tp& __b, _Compare __comp)
{
return __comp(__b, __a) ? __b : __a;
}
template
inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
const _Tp&
min(const _Tp& __a, const _Tp& __b)
{
return _VSTD::min(__a, __b, __less());
}
#ifndef _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
template
inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
_Tp
min(initializer_list __t, _Compare __comp)
{
return *__min_element(__t.begin(), __t.end(), __comp);
}
template
inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11
_Tp
min(initializer_list __t)
{
return *__min_element(__t.begin(), __t.end(), __less());
}
#endif // _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERSRe: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#24C++ supports this sort of thing directly. It says something about C++ takeup that anyone would bother adding this kludge to C. Many people are scared of C++. The language has become incredibly complex. C++ templates are Turing-complete. You can do arbitrary computation at compile time. Once this was discovered, ever-fancier templates became a basic part of C++. (Take a look at the huge templates that implement "max"…
Not touching on the rest of what you said, but what's so bad about min? Apart from some internal clang stuff, like odd names and macros, it looks okay - I can see what the function is doing. // min template inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const _Tp& min(const _Tp& __a, const _Tp& __b, _Compare __comp) { return __comp(__b, __a) ? __b : __a; } template inline _LIBCPP_INLINE_VISIBILITY _LI…
It used to be
#define min(x,y) ((x) Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#25The canonical method in C is to jump to a named label which hosts some functions to unwind/close any open descriptors or operations. As it involves the use of a goto statement, it drives certain people mad. I wasn't aware of C Blocks.
Clang's blocks produce atrocious code. Look at the disassembly for: int main(){ __block int (^foo)(int x) = ^ int (int x) { if(x versus the GCC: int main(){ int foo(int x) { if(x if you want to see what I'm talking about. CLANG: http://pastebin.com/37A9by4V GCC: http://pastebin.com/RMEDnwxi However, defer does look interesting, and implementing it for GCC is very easy: #define defer_(x) do{}while(0); \ auto void _dto…
Last time I looked at it, BOOST_SCOPE_EXIT_ALL generated similarly atrocious code, which is a shame because you can write a zero-cost construct in C++11 very easily.
Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#26Earlier quoted context omitted.
Not touching on the rest of what you said, but what's so bad about min? Apart from some internal clang stuff, like odd names and macros, it looks okay - I can see what the function is doing. // min template inline _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_AFTER_CXX11 const _Tp& min(const _Tp& __a, const _Tp& __b, _Compare __comp) { return __comp(__b, __a) ? __b : __a; } template inline _LIBCPP_INLINE_VISIBILITY _LI…
It used to be #define min(x,y) ((x)
Which is anything but safe.
Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#27C++ supports this sort of thing directly. It says something about C++ takeup that anyone would bother adding this kludge to C. Many people are scared of C++. The language has become incredibly complex. C++ templates are Turing-complete. You can do arbitrary computation at compile time. Once this was discovered, ever-fancier templates became a basic part of C++. (Take a look at the huge templates that implement "max"…
I think I just see it as different niches. C++ only adds to the code after a certain amount of complexity because there is so much magic its hard to manually translate to assembly in your head (at times). I certainly don't know much about c++ >03; the additions have been.... Probably not worth using over c for the massive probability and ability to contribute easily for small tools.
Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#28`defer` in a nonstandard extension to C implemented by a single compiler.
I like how Hacker News is all about exploring new things and playing with technology.
I don't think that hacker news is all about one thing.
Furthermore, it's fun to play with this, but it is undeniably not c. If you have access to clang everywhere (or gcc w/ blocks) and you're OK with the tradeoffs, have at it. :)
Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#29Re: Emulating Swift's “defer” in C, with Clang or GCC+Blocks
#30Earlier quoted context omitted.
Which is anything but safe.
Can you explain more please?
Because a macro in C/C++ is just text expansion, the given implementation will evaluate its arguments more than once, which will not be obvious at the "call" site and could have unintended consequences if the expressions have side-effects.