Re: Atila Neves: "C IS NOT MAGICALLY FAST, PART 2"
On Tuesday, 19 July 2016 at 10:07:11 UTC, Atila Neves wrote: On Tuesday, 19 July 2016 at 02:54:37 UTC, Saurabh Das wrote: Posted on Atila's blog yesterday: https://atilanevesoncode.wordpress.com/2016/07/18/c-is-not-magically-fast-part-2/ So, about D vs C++ there... last night for reasons I forget I tried replacing std::string with const char* in the C++ version, and then it got faster than D. I don't know why. At first I thought std::string was being copied instead of being moved, but some static_asserts made me doubt that. Either way, there's no good reason I can think of for C++ to magically speed up for const char*. Hmm :( Atila C++ Swap may be specialized for POD.
Re: Some questions on latest work
On Tuesday, 26 April 2016 at 01:04:21 UTC, Bill Hicks wrote: On Monday, 25 April 2016 at 21:20:04 UTC, Bienlein wrote: [...] To be frank, if you are using D for anything more than a throwaway hobby project, I have to tell you, D is a failed language, so stop wasting your time. The people who think that one day D is going to replace or threaten C++, or for that matter any other programming language, are delusional. No offense to all those who have spent great amount of time contributing to D, but people need to accept reality. [...] 1) This rant has nothing to do with OP's questions. It does not help him. 2) I'm not sure what you are so angry about. D seems to be making slow but steady progress. Its a community driven project, and its free. If you would rather use C++ or Rust, you know where to find them.
Re: A comparison between C++ and D
On Wednesday, 9 March 2016 at 22:05:28 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 9 March 2016 at 20:41:35 UTC, bigsandwich wrote: Right, I used to this sort of thing in C++ prior to C++11. I think not having an RAII wrapper for lambdas similar to std::function<> is an oversight for D, especially for people averse to GC. That little bit of syntactic sugar makes a huge difference. std::function<> is a lot more than syntactic sugar, it is a runtime-heavy construct. From http://en.cppreference.com/w/cpp/utility/functional/function : «Class template std::function is a general-purpose polymorphic function wrapper. Instances of std::function can store, copy, and invoke any Callable target -- functions, lambda expressions, bind expressions, or other function objects, as well as pointers to member functions and pointers to data members.» I don't think you want this... Yes, I do. std::function<> uses type erasure to store a "function". If its small enough, its stored internally, otherwise it goes on the heap. It uses RAII to manage the lifetime of the lambda. D is using the GC for managing the lifetime. D doesn't have a way of doing this without the GC.
Re: A comparison between C++ and D
On Wednesday, 9 March 2016 at 20:14:13 UTC, Adam D. Ruppe wrote: On Wednesday, 9 March 2016 at 18:26:01 UTC, bigsandwich wrote: [...] You can easily do it yourself with a struct. That's all the c++ lambda is anyway, a bit of syntax sugar over a struct. [...] Right, I used to this sort of thing in C++ prior to C++11. I think not having an RAII wrapper for lambdas similar to std::function<> is an oversight for D, especially for people averse to GC. That little bit of syntactic sugar makes a huge difference.
Re: A comparison between C++ and D
On Wednesday, 9 March 2016 at 01:18:26 UTC, maik klein wrote:
Direct link: https://maikklein.github.io/post/CppAndD/
Reddit link:
https://www.reddit.com/r/programming/comments/49lna6/a_comparison_between_c_and_d/
If you spot any mistakes, please let me know.
C++ as well as D have anonymous functions. C++: [](auto a, auto
b){ return a + b;} , D: (a, b) => a + b or (a, b){return a + b;}.
As far as I know capturing other variables requires the GC in D.
In C++ you can explicitly capture variables by copy, ref or move.
Lambda functions in D can not return references. C++17 will also
make lambda functions available with constexpr. Lambda functions
can also be used at compile time in D.
Is this really true? Couldn't the closure be stored internally
somewhere like std::function<> does in C++?
Re: Kinds of containers
On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote: On Friday, 23 October 2015 at 11:03:37 UTC, Andrei Alexandrescu wrote: [...] Sure. We have a problem when it come to collection in the fact that type qualifier do not turtle down as one would expect. [...] Its not just type qualifiers. Containers of derived types have the same problem. This is also a problem in C++.
Re: Read text file fast, how?
On Sunday, 26 July 2015 at 14:36:09 UTC, Johan Holmberg wrote: On Sat, Jul 25, 2015 at 10:12 PM, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: [...] My C++ program was actually doing C-style IO via stdio.h. I didn't think about the distinction C/C++ when reporting the earlier numbers. [...] It would be interesting to see numbers for the stdio.h code in D since it should be easy to translate and would rule it issues with compiler vs library.
Re: [OT] compiler optimisations
On Friday, 24 April 2015 at 07:04:10 UTC, Ola Fosheim Grøstad wrote: On Friday, 24 April 2015 at 02:33:19 UTC, ketmar wrote: On Thu, 23 Apr 2015 19:05:06 -0700, Walter Bright wrote: On 4/23/2015 5:37 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Yes, it is because of modular artithmetics which is a D design flaw. Out of the innumerable posts you write, I can't recall one which didn't assert that whatever D does is wrong. that's 'cause he don't talking about features done right. ;-) Oh, but I have!! I've pointed out that the vision for D1 was right, but D2 ruined it by adding cruft without fixing the flaws... ;-) Walter got A LOT right in his original _vision_ as represented on his original website for D1: - Taking current practice for C++ and building a better syntax for the most common patterns. - Clearly stating that a programming language should encourage you to write code that is aesthetically pleasing on the screen and make that easy. - Clearly stating that language semantics should be so simple that you didn't need a long specification for it. - Clearly stating that performance was imperative as a goal for the language and that D would not aim to replace higher level languages like C#. I can applaud to this, anyone who has exposed themselves to the annoyances of C++ can applaud to this! And D1 was a step in the right direction. A good start. The vision was lost on the way to D2, and most unfortunately the market for programming languages is a Winner Takes It All market. D2 is only a marginal improvement on C++, and worse in some areas. That can't win. I find it worrying that the evangelical D users are perceiving D as a compiled scripting language and claim it is similar to Python... D semantics are not at all like Python. That can't win. I find it worrying that the people who say they want to use D as a system programming language are into games, yet the projected vision for the D leadership now is to make it a web programming language that should ship with vibe.d. That can't win. I find it worrying that so many people attracted to D system level programming are into games, yet game development needs are ignored. That can't win. D is lucky that Rust is annoying, Go is marginal, and Nim is unknown, so people are stuck with ugly look C++ code. There is a need to move towards something beautiful, and that's not in Andrei's vision, but in the original D1 vision + the improvements proposed by Bearophile, Timon Gehr and others. Or swing 100% to Andrei's direction and improve significantly on meta programming by adding pattern matching and partial evaluation, so that you have something significantly better than C++. …but move... Remember: It's a winner takes it all game. I get so tired of non game devs spouting off about what they think gamedevs do. Let me give you a clue, we are aware of the internet. We do process strings and JSON. Not only that but we usually do this stuff in C++, and it often sucks to write. There is really only a small fraction of game code that tends to look like low level C. There are people who spend all their time writing this kind of code, but there are tons of other programers doing other things. Farming this work out to C# isn't a realistic option at runtime, and at tool time it requires maintaining bindings. That's part of the reason D is attractive to me as a gamedev. I WANT all those high level features, I want them to be performant, and I want the ability to write low level code when necessary. D1 just doesn't cut it.
Re: What are the worst parts of D?
Reading this thread makes me a little sad, because all of the wish list stuff seems to be about features that VS already has, and the I use every day :( For example, the idea of stepping through lines of code (i.e. individual statements) is a convenient simplification, but really, in modern programming languages there are multiple levels of semantics that could have a meaningful concept of stepping forward/backward. Only for C#, I would love to see this for native code: http://msdn.microsoft.com/en-us/library/h5e30exc%28v=vs.100%29.aspx On Thursday, 25 September 2014 at 05:30:56 UTC, Walter Bright wrote: On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote: printf debugging FTW! :-P There's more than that, but yeah. Most of my types I'll write a pretty printer for, and use that. No conceivable debugger can guess how I want to view my data. For example, I can pretty-print an Expression as either a tree or in infix notation. autoexp.dat can do this in the debugger: http://msdn.microsoft.com/en-us/library/zf0e8s14.aspx I don't agree with that. I think symbolic debuggers should be improved so that they *can* become useful with high level abstractions. For example, if debuggers could be made to understand templates and compile-time constants, they could become much more useful than they are today in debugging high-level code. The fact that they aren't should be telling. Like maybe it's an intractable problem :-) sort of like debugging optimized code. http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/
