Re: WinUI 3
On Monday, 15 March 2021 at 17:04:56 UTC, evilrat wrote: On Monday, 15 March 2021 at 16:41:08 UTC, Imperatorn wrote: Could D be used with WinUI 3? https://docs.microsoft.com/en-us/windows/apps/winui/winui3/ Would the win32metadata help? 🤔 I've seen some slides about WinUI 3 future directions and roadmap but haven't tried it yet. Probably it will be PITA to use it right now in anything not .NET because of some core dependencies (IIRC some core stuff is in .NET), but plans have mentions it will be possible to use with ANY language closer to release date somewhere in Q3 2021. But if it can be done using C++/WinRT right now then it is highly likely this will be possible to do it in D as well. As for WinRT stuff there was some tools and bindings done by webfreak. https://github.com/WebFreak001/dwinrt2 and/or https://github.com/WebFreak001/dwinrt WinUI core is WinRT, basically modern COM, no :NET dependencies.
Re: C++ or D?
On Thursday, 31 December 2020 at 07:17:45 UTC, RSY wrote: On Wednesday, 30 December 2020 at 21:03:36 UTC, Paulo Pinto wrote: On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: [...] C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities. It's like the story with the GC You want everyone to like D because it has a GC despite it being not updated in ages, and proved to not scale well You do the same with modules and reflections now, D is clearly better but for some reasons you don't want people to believe that, worse you want people to see them as inferior to the poor C++ one, because you clearly didn't mention any of that poor 1 phase compilation model What is your goal here? you for sure don't want D to take off It would be nice to see D taking off, I just happen not to be blind to the competition. That is the beauty of being an enterprise polyglot consultant, I get to pick what customers want, and they want eco-systems and platforms. Which not only use GC in domains that D fails to, also get to catch up with almost every feature that made D a better choice 10 years ago. Blind advocacy won't get new users.
Re: C++ or D?
On Thursday, 24 December 2020 at 08:36:54 UTC, RSY wrote: On Wednesday, 23 December 2020 at 19:00:14 UTC, evilrat wrote: On Wednesday, 23 December 2020 at 18:03:56 UTC, frame wrote: It's not the problem mentioned but I had to struggle with DLLs and D's Variant-type. The problem is that Variant uses TypeInfo which does not pass DLL boundaries correctly so that int != int in runtime even it's in fact a simple int. If you need to exchange unknown data between a DLL and your application you need to get a workaround and cannot use that elsewhere settled nice feature. But it's a Windows specific issue - it works as expected on other systems. Which is basically same as in C++, despite the fact it does have real working SO/DLL runtime's many large projects have their own RTTI implementation. LLVM has its own RTTI because standard type info is "inefficient", Unreal Engine has its own, IIRC Qt too has its own, etc... Same thing with D Variant, some people say it is "inefficient"... so we ended up having multiple libraries. Not saying anything about how good or bad all this, just the facts. C++ you need to write duplicate code (.h and .cpp) C++ you need to care about header include order C++ you need to forward declare everything you gonna use if it is not included before C++ you need to waste time waiting for compile Fixed with C++20 modules. I am already playing with the experimental support on VC++. C++ you need to fight to get proper reflection Coming in C++23, and partially available already with a mix of type traits and constexpr. I am all good for D vs C++, but one needs to update their knowledge specially when the audience is up to date with latest ISO C++'s capabilities.
Re: low-latency GC
On Sunday, 6 December 2020 at 08:12:58 UTC, Ola Fosheim Grostad wrote: On Sunday, 6 December 2020 at 07:45:17 UTC, Bruce Carneal wrote: GCs scan memory, sure. Lots of variations. Not germane. Not a rationale. We need to freeze the threads when collecting stacks/globals. D is employed at multiple "levels". Whatever level you call it, Go and modern JVMs employ low latency GCs in multi-threaded environments. Some people would like to use D at that "level". Yes, but they don't allow low level programming. Go also freeze to sync threads this has a rather profound impact on code generation. They have spent a lot of effort on sync instructions in code gen to lower the latency AFAIK. They surely do. Looking forward to see D achieve the same performance level as .NET 5 is capable of, beating Google's own gRPC C++ implementation, only Rust implementation beats it. https://www.infoq.com/news/2020/12/aspnet-core-improvement-dotnet-5/ And while on the subject of low level programming in JVM or .NET. https://www.infoq.com/news/2020/12/net-5-runtime-improvements/ Many of the performance improvements in the HTTP/2 implementation are related to the reimplementation from unmanaged C++ code to managed C# code. Lander notes that there "still is this kind of idea that managed languages are not quite up to the task for some of those low-level super performance sensitive components, Rich Lander being one of the main .NET architects, and upcoming Java 16 features, http://openjdk.java.net/jeps/389 (JNI replacement), http://openjdk.java.net/jeps/393 (native memory management). As I already mentioned in another thread, rebooting the language to pull in imaginary crowds will only do more damage than good, while the ones deemed unusable by the same imaginary crowd just keep winning market share, slowly and steady, even if takes yet another couple of years.
Re: GUI library for DMD 2.090 or DMD 2.091
On Sunday, 26 April 2020 at 09:09:04 UTC, Antonio Corbi wrote: On Saturday, 25 April 2020 at 09:30:44 UTC, Paulo Pinto wrote: On Friday, 24 April 2020 at 18:52:55 UTC, Russel Winder wrote: [...] Just curious, how do you handle the whole RC> story in Gtk-rs? For me it made the point that languages with tracing GC or implicit reference counting are much better solution for doing GUI programming. Hi Paulo, I don't know if you are referring to the `clone!` macro described here[1] [1] https://gtk-rs.org/blog/2019/12/15/new-release.html Antonio Hi, this macro is new to me, it did not exist when I tried to have a go at Gtk-rs, so it simplifies not having to write such boilerplate ourselves, but like the author mentions it doesn't make it go away, it just gets hidden behind the macro.
Re: GUI library for DMD 2.090 or DMD 2.091
On Friday, 24 April 2020 at 18:52:55 UTC, Russel Winder wrote: On Fri, 2020-04-24 at 15:50 +, Phrozen via Digitalmars-d-learn wrote: […] @Basile B., thanks for the suggestion. I'll try this library too. Just a bit of confirmation: I am a fan of D and GtkD for desktop UI work. GTK+ is just a UI framework unlike Qt (which is UI and networking, database, etc.) and is fairly straightforward to work with after the initial learning hump – which is the same between GTK+ and Qt. Qt is really C++ and Python only though many languages have bindings to QML. GTK+ has many bindings, C++, Go, Rust, and D to name just the obvious native code languages. C++ (gtkmm) and Go (gotk3) bindings are manuals ones, Rust (gtk-rs) and D (GtkD) bindings are generated from the API specification (GIR files). I believe this makes gtk-rs and GtkD far superior to gtkmm and gotk3. I have done a number of projects in Rust/gtk-rs and D/GtkD. Overall I prefer the code of D/GtkD over Rust/gtk-rs *but* there is much more IDE and editor support for Rust compared to D. This makes Rust code easier to write than the equivalent D code, even if that Rust code is more ugly than the equivalent D code. So whilst I keep wanting to do D/GtkD, I keep getting pulled to Rust/gtk-rs simply because CLion (and Emacs) support for Rust is so much nicer than the D support. I must laud Samael's efforts on the IntelliJ IDEA/CLion D support, it is magnificent, but the project needs more resource to get the CLion D plugin somewhere near as good as the Rust CLion plugin. I am sure VisualStudio fans, indeed any other IDE users, will say the same about their IDE, I am a CLion user so try to push CLion support. Just curious, how do you handle the whole RC> story in Gtk-rs? For me it made the point that languages with tracing GC or implicit reference counting are much better solution for doing GUI programming.
Re: ESR on post-C landscape
On Wednesday, 15 November 2017 at 02:05:27 UTC, codephantom wrote: On Tuesday, 14 November 2017 at 16:38:58 UTC, Ola Fosheim Grostad wrote: It [C]is flawed... ESR got that right, not sure how anyone can disagree. Well I 'can' disagree ;-) Is a scalpel flawed because someone tried to use it to screw in a screw? Languages are just part of an evolutionary chain. No part of the chain should be considered flawed - unless it was actually flawed - in that it didn't meet the demands of the environment in which it was initially conceived. In that circumstance, it must be considered flawed, and evolutionary forces will quickly take care of that. But a programming language is not flawed, simply because people use it an environment where it was not designed to operate. If I take the average joe blow out of his comfy house, and put him in the middle of raging battle field, is Joe Blow flawed, because he quickly got shot down? What's flawed there, is the decision to take Joe Blow and put him in the battlefield. Corporate needs/strategy, skews ones view of the larger environment, and infects language design. I think it's infected Go, from the get Go. I am glad D is not being designed by a corporate, otherwise D would be something very different, and far less interesting. The idea that C is flawed, also skews ones view of the larger environment, and so it too infects language design. This is where Eric got it wrong, in my opinion. He's looking for the language that can best fix the flaws of C. In fact C has barely had to evolve (which is not a sign of something that is flawed), because it works just fine, in enviroments for which it was designed to work in. And those enviroments still exist today. They will still exist tomorrow..and the next day...and the next..and... So language designers..please stop the senseless bashing of C. Why does anyone need array index validation anyway? I don't get it. If you're indexing incorrectly into an array..you're a fool. btw. The conditions under which C evolved, are well documented here. It's a facinating read. https://www.bell-labs.com/usr/dmr/www/chist.pdf Quite fascinating indeed. "Although the first edition of K&R described most of the rules that brought C’s type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions." "Two ideas are most characteristic of C among languages of its class: the relationship between arrays and pointers, and the way in which declaration syntax mimics expression syntax. They are also among its most frequently criticized features, and often serve as stumbling blocks to the beginner. In both cases, historical accidents or mistakes have exacerbated their difficulty. The most important of these has been the tolerance of C compilers to errors in type." "On the other hand, C’s treatment of arrays in general (not just strings) has unfortunate implications both for optimization and for future extensions. The prevalence of pointers in C programs, whether those declared explicitly or arising from arrays, means that optimizers must be cautious, and must use careful dataflow techniques to achieve good results. Sophisticated compilers can understand what most pointers can possibly change, but some important usages remain difficult to analyze." There are quite a few snippets to take from it, but I will finalize with the design goals regarding the spirit of C for ANSI C11 instead. "12. Trust the programmer, as a goal, is outdated in respect to the security and safety programming communities. While it should not be totally disregarded as a facet of the spirit of C, the C11 version of the C Standard should take into account that programmers need the ability to check their work. " http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2021.htm
Re: Windows Universal/Store apps support
On Friday, 29 May 2015 at 10:01:53 UTC, Rikki Cattermole wrote: On 29/05/2015 9:55 p.m., Paulo Pinto wrote: On Friday, 29 May 2015 at 07:41:14 UTC, Rikki Cattermole wrote: On 29/05/2015 7:03 p.m., Paulo Pinto wrote: On Friday, 29 May 2015 at 03:23:39 UTC, Rikki Cattermole wrote: On 29/05/2015 3:57 a.m., Olivier Prince wrote: I searched the forum to find if there is some support for new Windows development technologies and I didn't find anything related (except some rants about WinRT 3 years ago). - Is there any support in D or phobos for developping this kind of applications? No. - Does D support ARM as Windows target? Yes/No. ldc/gdc guys probably are a good place to start. - Are there any plans to support the specific libraries in this respect (something like C++/CX extensions or COM metadata files)? What exactly do you need? WinRT is an evolution of COM with a .NET feel to the API. Basically it is COM where objects also need to implement a new interface, IInspectable, and .NET metadata stored in .winmd files is used instead of COM type libraries. In a way WinRT is the return of Ext-VOS, the original idea behind .NET. Most likely caused by the Longhorn failure to write everything in .NET, as most new Windows APIs have been introduced as COM components since Vista. So any language targeting WinRT, or Universal Apps as they are now known, needs to to support COM alongside the required interfaces for interoperability between languages and be able to consume/produce .NET metadata files. -- Paulo D already supports COM. For .winmd, you should be good to go for -m32mscoff and -m64! Just add LFLAGS="/winmd" Although this really really needs to be tested. As far as I am aware D supports old style COM, not COM with WinRT improvements. I don't get your hint with LFLAGS. https://msdn.microsoft.com/en-us/library/jj157268.aspx So unless this isn't doing what I think it is doing, then yes it is relevant. No guarantees about what it requires for input info regarding e.g. symbols however. Are you aware what are .NET metadata files? I can't say anything about that. Again try the flag. If it doesn't do what I'm expecting it does, no harm. It's just a feature that definitely isn't implemented or supported by the toolchain. Of course, just because it generates the file, doesn't mean that there will be anything of use within it. The compiler provides the required information in C++/CX mode. When using pure C++ with the Windows Runtime C++ Template Library instead[0], it requires an idl file to be given to the MIDL compiler, that is then fed to the linker, like old style COM type libraries. [0] - https://msdn.microsoft.com/en-us/library/windows/apps/hh438466.aspx [1] - https://msdn.microsoft.com/en-us/library/windows/apps/hh973463.aspx
Re: Windows Universal/Store apps support
On Friday, 29 May 2015 at 07:41:14 UTC, Rikki Cattermole wrote: On 29/05/2015 7:03 p.m., Paulo Pinto wrote: On Friday, 29 May 2015 at 03:23:39 UTC, Rikki Cattermole wrote: On 29/05/2015 3:57 a.m., Olivier Prince wrote: I searched the forum to find if there is some support for new Windows development technologies and I didn't find anything related (except some rants about WinRT 3 years ago). - Is there any support in D or phobos for developping this kind of applications? No. - Does D support ARM as Windows target? Yes/No. ldc/gdc guys probably are a good place to start. - Are there any plans to support the specific libraries in this respect (something like C++/CX extensions or COM metadata files)? What exactly do you need? WinRT is an evolution of COM with a .NET feel to the API. Basically it is COM where objects also need to implement a new interface, IInspectable, and .NET metadata stored in .winmd files is used instead of COM type libraries. In a way WinRT is the return of Ext-VOS, the original idea behind .NET. Most likely caused by the Longhorn failure to write everything in .NET, as most new Windows APIs have been introduced as COM components since Vista. So any language targeting WinRT, or Universal Apps as they are now known, needs to to support COM alongside the required interfaces for interoperability between languages and be able to consume/produce .NET metadata files. -- Paulo D already supports COM. For .winmd, you should be good to go for -m32mscoff and -m64! Just add LFLAGS="/winmd" Although this really really needs to be tested. As far as I am aware D supports old style COM, not COM with WinRT improvements. I don't get your hint with LFLAGS. Are you aware what are .NET metadata files? .. Paulo
Re: Windows Universal/Store apps support
On Friday, 29 May 2015 at 03:23:39 UTC, Rikki Cattermole wrote: On 29/05/2015 3:57 a.m., Olivier Prince wrote: I searched the forum to find if there is some support for new Windows development technologies and I didn't find anything related (except some rants about WinRT 3 years ago). - Is there any support in D or phobos for developping this kind of applications? No. - Does D support ARM as Windows target? Yes/No. ldc/gdc guys probably are a good place to start. - Are there any plans to support the specific libraries in this respect (something like C++/CX extensions or COM metadata files)? What exactly do you need? WinRT is an evolution of COM with a .NET feel to the API. Basically it is COM where objects also need to implement a new interface, IInspectable, and .NET metadata stored in .winmd files is used instead of COM type libraries. In a way WinRT is the return of Ext-VOS, the original idea behind .NET. Most likely caused by the Longhorn failure to write everything in .NET, as most new Windows APIs have been introduced as COM components since Vista. So any language targeting WinRT, or Universal Apps as they are now known, needs to to support COM alongside the required interfaces for interoperability between languages and be able to consume/produce .NET metadata files. -- Paulo
Re: GC has a "barbaric" destroyng model, I think
On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote: On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote: That's a repetition of C++ atavism, that resource management == memory management. IStream is a traditional example of a GC-managed object, which needs deterministic destruction, and not because it consumes memory, but because it encapsulates an unmanaged resource, it has nothing to do with memory management, malloc and free. p.s. istream example is bad. what it does is simply highlighting the fact that there is no way to do deterministic management with GC. Other languages manage to do it with scopes (e.g. using/lambda expressions) and phantom/weak references. The only downsize it that it isn't as simple as a C++ destructor. -- Paulo
Re: For those ready to take the challenge
On Saturday, 10 January 2015 at 15:52:21 UTC, Tobias Pankrath wrote: ... The thing is, in languages like Perl, Python, Ruby (to name a few), reusing someone else's code is not only easy, but it is how most people actually write code most of the time. I think he's wrong, because it spoils the comparison. Every answer should delegate those tasks to a library that Stroustroup used as well, e.g. regex matching, string to number conversion and some kind of TCP sockets. But it must do the same work that he's solution does: Create and parse HTML header and extract the html links, probably using regex, but I wouldn't mind another solution. Everyone can put a libdo_the_stroustroup_thing on dub and then call do_the_stroustroup_thing() in main. To compare what the standard libraries (and libraries easily obtained or quasi standard) offer is another challenge. I disagree. The great thing about comes with batteries runtimes is that I have the guarantee the desired features exist in all platforms supported by the language. If the libraries are dumped into a repository, there is always a problem if the library works across all OS supported by the language or even if they work together at all. Specially if they depend on common packages with incompatible versions. This is the cause of so many string and vector types across all C++ libraries as most of those libraries were developed before C++98 was even done. Or why C runtime isn't nothing more than a light version of UNIX as it was back in 1989, without any worthwhile feature since then, besides some extra support for numeric types and a little more secure libraries. Nowadays, unless I am doing something very OS specific, I hardly care which OS I am using, thanks to such "comes with batteries" runtimes. -- Paulo
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Thursday, 8 January 2015 at 17:42:23 UTC, H. S. Teoh via Digitalmars-d-learn wrote: On Thu, Jan 08, 2015 at 11:29:29AM +, Laeeth Isharc via Digitalmars-d-learn wrote: >this conversation is so funny: well what's wrong with this . >It's a >keyword... >Aa Ha ha ha ha , rol. >Seriously, is it so complicated to use a D editor ? I mean >with >syntax color... Man afraid to ask stoopid questions stays stoopid. And compiler error message far from informative. Not everyone is very visually oriented, and sometimes vi is quicker. Vim supports syntax highlighting. But I don't use it either -- I find it distracts from clarity of thought. I use plain vanilla vim in a text-only terminal. T I don't get this, then again I am using syntax highlighting editors since MS-DOS IDEs supported it. -- Paulo
Re: Conditional Compilation for Specific Windows
On Wednesday, 7 January 2015 at 19:48:16 UTC, Jonathan Marler wrote: On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg wrote: On 2015-01-07 19:27, Jonathan Marler wrote: I'm looking at the Windows multicast API. It has different socket options depending on if you are on Windows XP or Windows Vista (and later). Is there a way to tell at runtime which version of windows you are on? Note: I'm specifically talking about runtime because I want the same binary to run on all windows versions so I have to support both and determine which one I am running on at runtime. Use the regular system API's as you would in C. Should be easy to find if you search the web. I've looked up the windows version helper functions (http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx). The problem is that these functions are not defined in DMD's user32.lib. I could use the operating system's user32.lib but it is in COFF format, so I would have to convert my D object files to COFF and then compile using MSVC or GNU GCC for windows (or I could try converting the OS user32.lib to OMF). Or, I could add the functions to DMD's user32.lib but as far as I know this is a private binary managed by Digital Mars that I can't contribute to? Am I wrong? Does anyone else have a solution or an idea on this? Note: I've wanted to use other windows function in the past that were missing from DMD's user32.lib file. A solution to solve this for multiple functions would be ideal, thanks. You could bypass user32.lib by using directly user32.dll via LoadLibrary()/GetProcAddress(). -- Paulo
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Wednesday, 7 January 2015 at 15:02:34 UTC, Laeeth Isharc wrote:
Not true. If you're using a tree structure, you *should* use
pointers.
Unless you're using classes, which are by-reference, in which
case you
can just use the class as-is. :-)
Thanks v much.
I just came to that realization also when I stepped away.
class node
{
string name;
node ref;
}
what's wrong with the code above ? i get an error no
identifier for declarator node. (I have not used classes much,
since structs often seem to be enough for what I need to do
mostly).
ref is a reserved keyword.
--
Paulo
Re: Source code annotations alla Java
On Thursday, 20 January 2011 at 14:04:54 UTC, Steven Schveighoffer wrote: On Thu, 20 Jan 2011 08:47:28 -0500, Justin Johansson wrote: Not long ago the Java Language people introduced the idea of annotations together with an annotation processing tool (apt). Now perhaps the idea of source code annotations is not actually a Java invention per se, however for someone learning D is there any equivalent idiom [of Java annotations] in the D language? Haven't used Java since they added annotations, but I think they are like C# attributes? Yes, this is one case where Java copied back from C#. -- Paulo
Re: Live without debugger?
Am 09.11.2014 um 09:26 schrieb Suliman: I know that a lot of people are using for programming tools like Sublime. I am one of them. But if for very simple code it's ok, how to write hard code? Do you often need debugger when you are writing code? For which tasks debugger are more needed for you? All the time, it is the workaround for exploratoring programming when a REPL is not available. Smalltalk and Borland environments spoiled me in terms of what to expect from developer productivity tooling. I only skip on the debugger for tracing down issues that can only be tracked down in production systems, where plugging a debugger would cause Heisenbugs. As for what I use them: - REPL like interactivity - Visual displaying relationships between processes/tasks - User friendly representation of data structures - Conditional breakpoints depending on expressions and log events - Forcing error conditions without changing existing code - Break on core dump/application crash. -- Paulo
Re: How would you dive into a big codebase
On Wednesday, 22 October 2014 at 02:42:38 UTC, safety0ff wrote: On Wednesday, 22 October 2014 at 01:21:19 UTC, Freddy wrote: Is there any advice/tips for reading medium/big D codebases? Somewhat D specific: I would consider an IDE/editor like Eclipse with DDT that can give an outline of the data structures & functions names in a source file to make the files easier to digest. This would be my approach as well. The code navigation options offered by modern IDEs are way better than the alternatives, specially the semantic navigation "what gets used where". -- Paulo
Re: Beginner ?. Why does D suggest to learn java
On Tuesday, 21 October 2014 at 09:14:08 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 21 Oct 2014 09:01:32 + Kapps via Digitalmars-d-learn wrote: no template magic that's very bad. it's time to stop making people think that templates are inevitably arcane. People think templates are magic, due to their skillset. I see that all the time in the enterprise, when we get people on projects that would already have issues using something like Clipper/VB back in the day. -- paulo
Re: Beginner ?. Why does D suggest to learn java
Am 17.10.2014 um 16:14 schrieb Jessica Rauth: On Friday, 17 October 2014 at 08:44:00 UTC, Paulo Pinto wrote: On Friday, 17 October 2014 at 01:05:37 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 00:52:14 + MachineCode via Digitalmars-d-learn wrote: I don't understand. If at least it were C but java? why not D itself? C is *awful* as "beginner's language". never ever let people start with C if you don't hate 'em. as for D... current version of D can be used, but with some precautions. we now have excellent book by Ali. (it's great, really! i believe that it must be featured on the front dlang.org page!) but java has alot more books and tutorials. not that D is bad for beginners, it's just has a smaller userbase. and all that things with "classes are reference types and structs are not", "empty array is not empty array but is empty array" and so on D may be confusing a little. it's good to have some CS background to understood that things. just my cent and cent. Better, go with FreePascal http://www.freepascal.org/ and discover all that those features that many C advocates spread as being close to the machine and other C only features, aren't exclusive of it. Alongside support for real modules, OO and genericity. Then with a head clean of bad C influences, jump into D. -- Paulo One of the problem when starting out with FPC resides in the fact that's a completely different family of language (Ada, Pascal, Modula vs the C family), syntax and philosophy (for example in the RTL). Another one is that usually people use it in combination with Lazarus and as the RAD concept is no shit, people start building some applications very fastly. Then when they come to another lang. eg D or Cpp they take a big slap in the face. The fact is that Obj. Pascal and Delphi often give a wrong appreciation of its own skills and abilities. Although I am biased to the Pascal family of languages, this has been done in real world for a couple of decades. When I joined the New University of Lisbon as a student in 1994, I was lucky that the professor heading the programming languages section, had a similar opinion as me in terms of programming languages. The first year students had introduction to programming with P2C/GNU Pascal in the first semester, followed by C++ with gcc in the second semester. There was no C, at all. It was expected that any student compent enough to use C++, would be able to code in straight C if asked to do so. On my last year at the university (1998/9), I one of the teachers giving those lab classes to students. By then, we were using Delphi and Visual C++ instead. The students didn't had much problems switching languages. They got to learn that using pointers doesn't need to be the dragon that C makes out to be. That there was a way to deal with strings, arrays and reference parameters without impact in the whole application. The most curious got to learn how to disable bounds checking. They learned how to write modular applications without having to prefix all their identifiers. They also learned that C wasn't the only way to touch the machine at all levels. You talk about genericity but the genericity in Object Pascal is currently almost inexistant and doesn't provide a good idea of what "template-meta-programming" is. Actually this looks more like a patch to the lang. and some simple things just like casting a generic type or global generic functions simply don't work at all. While D2 has been written with this idea, FPC will never be good with TMP. Even in the commercial version (Delphi XE7) they start to add some kind of patchs eg with a compiler instrasic which is equivalent to D "static if" (which means that the lang. is not designed for that at all). I just referenced it, because I saw it mentioned a few times in Delphi documentation, but never came to use it. Since 2000 that I don't do anything in the Pascal world of languages, besides collecting Oberon related stuff. -- Paulo
Re: Beginner ?. Why does D suggest to learn java
On Friday, 17 October 2014 at 01:05:37 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 00:52:14 + MachineCode via Digitalmars-d-learn wrote: I don't understand. If at least it were C but java? why not D itself? C is *awful* as "beginner's language". never ever let people start with C if you don't hate 'em. as for D... current version of D can be used, but with some precautions. we now have excellent book by Ali. (it's great, really! i believe that it must be featured on the front dlang.org page!) but java has alot more books and tutorials. not that D is bad for beginners, it's just has a smaller userbase. and all that things with "classes are reference types and structs are not", "empty array is not empty array but is empty array" and so on D may be confusing a little. it's good to have some CS background to understood that things. just my cent and cent. Better, go with FreePascal http://www.freepascal.org/ and discover all that those features that many C advocates spread as being close to the machine and other C only features, aren't exclusive of it. Alongside support for real modules, OO and genericity. Then with a head clean of bad C influences, jump into D. -- Paulo
Re: Using std.container.BinaryHeap like C++
Am 18.08.2014 14:49, schrieb monarch_dodra: On Monday, 18 August 2014 at 06:50:08 UTC, Paulo Pinto wrote: On Sunday, 17 August 2014 at 21:09:04 UTC, monarch_dodra wrote: On Sunday, 17 August 2014 at 18:54:27 UTC, Paulo Pinto wrote: Hi, I was wondering if it is possible to use the BinaryHeap store like the C++'s make_heap/pop_heap/push_heap functions. I would like to port to D some A* C++ code I have which rearranges the priorities on the underlying store, followed by another make_heap() call on the vector used as store. Doing the same in D by calling again heapify() does not seem to provide similar behavior. Just curious about it, as I don't plan to invest too much time on it. Thanks, Paulo AFAIK, D's BinaryHeap works just like C++'s make_heap/pop_heap/push_heap, except that it provides an actual object you can interface with, which has font, removeFront, removeAny and insert. What exactly is the difference in behavior you are seeing? Just different results that can be attributed to implementation details, or fundamental differences? It doesn't seem to like I change the store contents directly under its feet and recalling heapify again on the same store, like I am doing in C++'s heap. Sometimes I get a different sequence of data or just a crash. I still need to make the D code reflect my latest C++ changes, as the C++ code is what really matters in this hobby project, there is where my focus has been lately. The D version is more of a "playing around" thing. As I said, I curious what the behavior is supposed to be. Thanks, Paulo Weird. The behavior should be the same as C++'s. As I said, the difference is that D gives you a "handle" object. This object assumes you *don't* modify it's store under the hood, but as long as you don't use the heap after a store modification, you should be fine. Do you have a minimal test case? Actually, that is exactly what I am doing. :) The store contains the open list of nodes to visit, and when new paths are found, I re-parent the nodes which leads to a different cost, thus I re-generate the heap. The D code is still not up to date with what I am doing on C++ and the code I had before lost it somehow while jumping around computers. But both projects are on Github. C++ https://github.com/pjmlp/AStarDemoCpp/blob/master/AStarDemo/AStarSolver.cpp D https://github.com/pjmlp/AStarDemoD/blob/master/src/solver.d -- Paulo
Re: Using std.container.BinaryHeap like C++
On Sunday, 17 August 2014 at 21:09:04 UTC, monarch_dodra wrote: On Sunday, 17 August 2014 at 18:54:27 UTC, Paulo Pinto wrote: Hi, I was wondering if it is possible to use the BinaryHeap store like the C++'s make_heap/pop_heap/push_heap functions. I would like to port to D some A* C++ code I have which rearranges the priorities on the underlying store, followed by another make_heap() call on the vector used as store. Doing the same in D by calling again heapify() does not seem to provide similar behavior. Just curious about it, as I don't plan to invest too much time on it. Thanks, Paulo AFAIK, D's BinaryHeap works just like C++'s make_heap/pop_heap/push_heap, except that it provides an actual object you can interface with, which has font, removeFront, removeAny and insert. What exactly is the difference in behavior you are seeing? Just different results that can be attributed to implementation details, or fundamental differences? It doesn't seem to like I change the store contents directly under its feet and recalling heapify again on the same store, like I am doing in C++'s heap. Sometimes I get a different sequence of data or just a crash. I still need to make the D code reflect my latest C++ changes, as the C++ code is what really matters in this hobby project, there is where my focus has been lately. The D version is more of a "playing around" thing. As I said, I curious what the behavior is supposed to be. Thanks, Paulo
Using std.container.BinaryHeap like C++
Hi, I was wondering if it is possible to use the BinaryHeap store like the C++'s make_heap/pop_heap/push_heap functions. I would like to port to D some A* C++ code I have which rearranges the priorities on the underlying store, followed by another make_heap() call on the vector used as store. Doing the same in D by calling again heapify() does not seem to provide similar behavior. Just curious about it, as I don't plan to invest too much time on it. Thanks, Paulo
