Earlier quoted context omitted.
What about putting common template parameters into an external template in a binary libray?
Na, we will just remove this template nonsense.
I guess preprocessor macros are much better alternative. /s
Obvious things C should do
291–300 of 310 posts
Re: Obvious things C should do
#292Earlier quoted context omitted.
Na, we will just remove this template nonsense.
I guess preprocessor macros are much better alternative. /s
Probably yes. Macros are about equally bad than templates in my experience (although C++ people will disagree, I do not see much difference). But mostly I plan to just let the compiler specialize the functions during optimization. I haven't looked at this specific problem though.
Re: Obvious things C should do
#293Earlier quoted context omitted.
I guess preprocessor macros are much better alternative. /s
Probably yes. Macros are about equally bad than templates in my experience (although C++ people will disagree, I do not see much difference). But mostly I plan to just let the compiler specialize the functions during optimization. I haven't looked at this specific problem though.
For one, templates can be stepped through on the debugger without additional effort, offer type checking, don't execute parameters multiple times, and don't require additional parenthesis and curly braces to protect their misuse.
Re: Obvious things C should do
#294I tried D last year. As I recall it, there's at least one obvious things from C that D should add:
Switches can't seem to figure out that I have a case for every value of the enum I'm switching on, so I need a pointless default: assert(0);
I didn't check if this also breaks me getting warnings if I add new values to the enum but not the switch, but I imagine it does
Re: Obvious things C should do
#295Earlier quoted context omitted.
Probably yes. Macros are about equally bad than templates in my experience (although C++ people will disagree, I do not see much difference). But mostly I plan to just let the compiler specialize the functions during optimization. I haven't looked at this specific problem though.
For one, templates can be stepped through on the debugger without additional effort, offer type checking, don't execute parameters multiple times, and don't require additional parenthesis and curly braces to protect their misuse.
Debuggers can expand macros, and you can also look at the pre-processed output or even compile that (you can't the expanded form with templates). But I agree that if it becomes more complicated this is not very good. But you know, this does not matter too much to me as I will neither use complicated macros nor templates. And simple macros are just fine.
Re: Obvious things C should do
#296I feel that much of the point of C is that it's easy to implement. Substantially increasing its scope doesn't seem like the best idea. Perhaps they could do something akin to Scheme and have a "small" and "large" version of the specification.
That is long gone, when looking at C23 and the myriad of compiler extensions.
Re: Obvious things C should do
#297C++ has all of these except forward referencing declarations(though Importing Declarations requires modules which nobody uses yet). I'm not sure why forward reference declarations is needed nowadays(or if it really is from a language standpoint). C could probably copy C++'s constexpr & static_assert stuff to get the first 2.
Office team does use them.
There is Vulkan based modules library.
fmt has modules support.
Me and several others already use modules in some extent.
That is a bit more than nobody.
Re: Obvious things C should do
#298C++ has all of these except forward referencing declarations(though Importing Declarations requires modules which nobody uses yet). I'm not sure why forward reference declarations is needed nowadays(or if it really is from a language standpoint). C could probably copy C++'s constexpr & static_assert stuff to get the first 2.
Nobody uses C++ modules because they are clumsy to use. D's are easy. Note: anyone is free to copy D's module design. It's the best one out there. > I'm not sure why forward reference declarations is needed nowadays The article gives reasons. Although they aren't necessary , they are deleterious to code layout which becomes a slave to the declaration order rather than aesthetic order. > C++'s constexpr is still laggi…
Office has been migrating to modules, there are talks on the matter, and blog entries,
https://devblogs.microsoft.com/cppblog/integrating-c-header-...
https://devblogs.microsoft.com/cppblog/integrating-c-header-...
https://devblogs.microsoft.com/cppblog/integrating-c-header-...
Re: Obvious things C should do
#299The most obvious thing c should do is... evolve. Even Fortran seems to have added object-oriented constructs, all kinds of new types and concurrent and parallel programming
There has been an object-oriented evolution of c, it's called c++ ;)
What? Nah C++ is some template based language. The real object-oriented evolution of C is Objective-C. ;)
Re: Obvious things C should do
#300Earlier quoted context omitted.
Yup. D is the source for a number of recent features in other languages. The reason I embarked on D is because C and C++ were too reluctant to move forward.
Do you think you will keep moving forward for the next decade or will you merge when c/cpp becomes similar enough to D ? Maybe your group still has tons of ideas that need their own space to grow.
The biggest advance would be Microsoft adopt D.