Re: A Briefer Syntax for Using Concepts
I believe Concepts lite in C++ works around this by allowing a
syntax like this:
void foo(InputRange{T} range1, InputRange{T2} range2)
vs.
void foo(InputRange range1, InputRange range2)
If they are the same type.
I believe the objection is that the proposed syntax can't tell
the
difference between:
void foo(R)(R range1, R range2) if (isInputRange!R)
and
void foo(R,S)(R range1, S range2) if (isInputRange!R &&
isInputRange!S)
I.e. in the first case, the two ranges must be the same type,
whereas in
the second case they can be different types as long as they are
both
input ranges.
T
Re: More radical ideas about gc and reference counting
feels like writing C++ with C# syntax. Ahem. C++ has RAII k thanks. C++ > C# Proof.
Re: More radical ideas about gc and reference counting
Here is an alternative: 1. classes are unique by default, they cannot be shared. No GC or RF required, and covers 90% of objects. 2. To share, retype as GC, the requirement being that it does not have a destructor.
Re: DIP60: @nogc attribute
Also possible in C# with structs, interop annotations and unsafe blocks. And now you aren't using the language, but a (very) poor subset of a language that doesn't even support templates. C++ exposes SSE/AVX intrinsics, C# does not. That is not correct. 1 - Nowhere in the ANSI/ISO C++ are SSE/AVX intrinsics defined, those are compiler extensions. So equal foot with the C# EMCA standard; Duh, but every C++ compiler exposes this, so it is defacto standard. C++ has plenty of non-standard standards, such as #pragma once. 3 - .NET Native and RyuJIT have official support for SIMD instructions, GPGPU support is also planned I see on MS website an article about having a vector data type. While interesting that isn't the same as exposing the actual instructions, which will limit potential gains. The aricle http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-married.aspx Additionally .NET native will be MS only--
Re: DIP60: @nogc attribute
I am really looking forward to .NET Native becoming widespread. Then this type of comparisons (C# vs C++) will be quite different. I don't think it will make a major difference. Taking a GC based language and giving it a native compiler doesn't automatically make it performance competitive with C++(see Haskel and D(without dumping GC) on anything besides micro bench marks). C# is still GC based, still makes heavy use of indirection(See Herb Sutters recent talk on arrays). C++ exposes SSE/AVX intrinsics, C# does not. Many programs don't use these, but if you have a few hot spots involving number crunching, they can make a major difference. My current project spends about 80% of its CPU time in SSE amenable locations, some template magic mixed with SSE intrinsics, and now those spots run 4x faster. You might be thinking auto vectorization can compete, but I've yet to see the one in VS2013 accomplish much of anything. Also I doubt very much that an auto vectorizer can squash branches, which is very possible with intrinsics. True branches and vectorized code don't mix well...
Re: DIP60: @nogc attribute
Well, most of the new games (Unity3D) are done in C# nowadays and people live with it even though game development is one of the biggest C++ loving and GC hating crowd there is. Unity3D the engine is written primarily in C++, not C#. The Unity editor and gameplay code is written in C# because that type of code is generally not performance sensitive.
Re: DIP60: @nogc attribute
I know it does, but users employing @nogc still have to manage memory somehow. Let's add hooks to the runtime and implement some GC alternatives, and then see what demand is like ;-) They use noGC and smart pointers/manual ala C++. You seem to be suggesting that people who don't want GC, actually secretly want GC. Just to let you know, that isn't the case. A global one size fits all approach to memory management is far from optimal.
Re: Heartbleed and static analysis
Teoh-- Some C++ code bases get that way. I once worked on a codebase that was originally C, then added C with classes, and then had C++ metaprogramming bolted on top(custom and incomplete implementations of half of boost, including MPL). While it wasn't the best, I personally did not have a huge issue with understanding it. My coworkers, on the other hand, had serious problems understanding the metaprogramming, so I always had to deal with that code(I did not write it). If I could come onto the project and understand it, is it really the fault of the language, or the fault of my coworkers for not taking it upon themselves to become informed? Design flaws of C++? It may have a few, but compared to C? I think C++ is far better designed, and far safer. A legit flaw I would label C++ with(aside from missing features such as modules etc.) is a degree of unnecessary complexity, mostly caused by its evolving design. That is just what happens when you have a 30 year old language, that is mostly backwards compatible with an even older language. Because C++ is more complex it requires more informed programmers to operate than C. If you have a team of informed C++ programmers I feel that it is very possible to produce very quickly, high quality reliable code. That all members can understand(I'd be inclined to say fire anyone that can't grok it, they will just be a liability). But anyway I do not understand why important software is still written in C. It makes me sad:( On Saturday, 12 April 2014 at 22:40:32 UTC, H. S. Teoh wrote: On Sat, Apr 12, 2014 at 10:10:55PM +, froglegs wrote: Why do they write such important code in C to begin with? C is garbage compared to C++. With C++ they wouldn't need to drop down to raw pointers and would never have these problems. [...] C++ is better in theory, but not all that much better than C in practice. The design flaws of the language often makes it worse than C in terms of maintainability. At my day job, we switched a major project from C++ back to C, because the C++ codebase was over-engineered and full of abstractions that nobody understood, patched over multiple times by people who were reassigned to take the place of the original people who left, who didn't understand the original design but had unreasonable deadlines to meet, so as a result they just added hacks and workarounds to get their job done before they got fired. By the time a few years had passed, *nobody* understood what the system even does, and every new code change was a "blindly copy-n-paste from other parts of the code and pray it won't break something else" deal. It was bloated, slow, and riddled with bugs nobody dared to fix, because nobody understood what it does. Certain features were dependent on dtor side-effects, and other such pathological things, and it was maintenance hell. We rewrote the entire thing in C and, in spite of all C's flaws, at least you didn't have dtors performing magic behind your back and class abstractions that nobody understood what it actually does at runtime. I have to say that, in spite of C's shortcomings, at least it was a (relatively) small and self-contained design, and the gotchas were well understood and well-documented, whereas C++ is a monstrous beast full of every pitfall imaginable. Just about every other line of code you write out of habit is almost guaranteed to be wrong in *some* obscure corner case that only 2% of C++ programmers are even aware of. And in a large team project, you can guarantee that *someone* one day will write code that will trigger exactly that one obscure case that will produce a bug nobody can find. In C, when you mess up, most of the time you get a straight segfault, and you have no choice but to fix it before you check in. Well, most of the time, anyway. The same old off-by-1 buffer overrun bugs just keep recurring and recurring -- I just found another yet a few days ago, which has been lurking in there for a *long* time. Probably years. Sigh... But at least it's a well-known and well-understood problem, whereas in C++ it could be any one of 1000 novel combinations of several obscure C++ spec corner cases that interact in complex ways to produce a bug that most mid-level coders don't even understand, let alone have any idea how to debug. If you were to ask me 5-10 years ago which language was better, I'd say C++. Today, I'm not so sure anymore. Both suck. And I'm not sure which one sucks more -- 5 years ago I'd say C, but now I'm leaning towards saying C++. Now if we can only iron out the last 5% of D's wrinkles, it would be a HUGE relief from C/C++ nastiness. (Unfortunately, Pareto's principle dictates that this last 5% is gonna take us 95% of the time. :-P) T
Re: Heartbleed and static analysis
Why do they write such important code in C to begin with? C is garbage compared to C++. With C++ they wouldn't need to drop down to raw pointers and would never have these problems. (of course D guys will say use D, but lets be real, D isn't ready for many obvious reasons)
Re: enum
Oh you D guys, arguing about enums for 187 posts! Find something more interesting to talk about, this is boring:( The only thing about enum class that pisses me off is not being able to index into an array by default.
Re: Numbering compiler error messages?
On Saturday, 29 March 2014 at 15:37:05 UTC, w0rp wrote: I agree with Walter about error numbers being a bad idea. Especially when people prefer the numbers over a description. MySQL has really turned me off the idea of error numbers. When I get an error about MySQL syntax, the message actually reads like this. "Error near... number>" It never tells you what kind of syntax error you made, or *exactly* where it actually happened (The line and column numbers are misleading.). You just get a message "well it broke" and an error number which might as well be the result of a hash function. As a result, I hardly ever look up the error number, and I just make a guess as to what I did wrong. It's usually faster to guess. It's kind of like the effect bug IDs can have on commit messagses, which I mentioned in another thread. If you put some ID you can search for in a message, some people have a tendency to rely on the ID and forget about providing a descriptive message as well. I think a better approach is to just describe the error better. When I use DMD I get some pretty good results already for errors. We just need to patch messages which may be confusing at the moment into being more descriptive. The way Visual C++ does it is that you get *both* and error number and an error message. Having the error number is very useful for googling(yes the complete message will give you hits, but the # is more concise and turns up more hits), and for quickly referring to a given error.
Re: Why is it that no one writes with portability in mind in druntime?
I understand that it is converting a uint32 to a int32. My point is that in C++ you can make this a warning, and then make all warnings errors. So this would not compile in any sane codebase since a int cannot express the full range of a uint. Perhaps D just better errors/warnings if it is unable to capture this... On Monday, 25 November 2013 at 11:51:22 UTC, Jonathan M Davis wrote: On Monday, November 25, 2013 12:14:59 froglegs wrote: >>int len = arr.length; That isn't an error in D? Every C++ code base I've worked in enables max warnings/warnings as errors, this would never compile-- Does it at least trigger a warning? No. It's not a warning, and dmd is not big on warnings (and IMHO warnings you should be abolished, but that's another discussion). Regardless, given how size_t is implemented, the compiler doesn't really even know that it exists anyway. It's aliased to uint on 32-bit systems and ulong on 64-bit systems, so every place that size_t is used, it gets replaced with the type that it's aliased to, and the compiler forgets that it was ever anything else - the same thing happens with all aliases. So, on 32-bit systems, size_t is uint and int len = arr.length; works just fine, because uint implicitly converts to int. Whereas on 64-bit systems, size_t is ulong, and ulong does _not_ implicitly convert to int, so you get an error. So, on 32-bit systems, it compiles just fine, and 64-bit systems you get an error, but no systems will give you a warning. - Jonathan M Davis
Re: Why is it that no one writes with portability in mind in druntime?
int len = arr.length; That isn't an error in D? Every C++ code base I've worked in enables max warnings/warnings as errors, this would never compile-- Does it at least trigger a warning?
Re: Protocols vs Concepts?
b) it is impossible to do partial semantic validation of template body based on concept limitation which is the original motivating reason behind concept designs in C++ (with no success so far) I'm pretty sure I've read that they have it working in a GCC branch for C++ concepts lite, it does validation at compile time.
Re: What’s Wrong with OOP and FP
Go is a boring language, kind of like Dart, I guess Google just sucks at language design? The do use an awful lot of Java, perhaps it has caused irreparable damage
Re: What’s Wrong with OOP and FP
bearophile how much do you love haskell
Re: BigInt -- a challenge for std.allocator
BigInt n = 100; n += 10; ++n; ... and both the 2nd and 3rd lines will result in a reallocation even though there is no need for it, because only n is referencing the memory it wraps. Does BigInt not have overloaded operators for adding normal integers? Is it converting 10 to a BigInt prior to adding it to n?
Re: More on C++ stack arrays
One of my most anticipated C++14 features actually, hope they don't dawdle too much with the TS it apparently got pushed back into:(
Re: The "no gc" crowd
GC works for some cases, but the global one size fits all GC that D uses is no good.
Re: SteamOS, games programming, and D
1. Easy C++ interop(don't want to write C wrappers) 2. An awesome IDE(visual D is not there yet) comparable to Visual C++ w/ Visual Assist 3. none buggy language implementation 4. Easy to disable GC without breaking everything
Re: John Carmack on Eclipse performance
I do like C++, but every time I look what is happening post C++11, tend to be glad to spend most of my time in JVM/.NET land, specially because I deal a lot with teams full of developers with an average skill set. -- Paulo Eh? C++11 makes things easier/better IMO, C++14 also has a few good things in it. Really I'd say the main issue with C++ is how slow they are at adding some of the really important things(no modules until C++17(if then) --) personally I don't give a fig about developers with average skill sets, but even they are better off with newer features like auto, lambda, shared_ptr/unique_ptr
Re: John Carmack on Eclipse performance
You can look at the source for Doom 3, it is written in C with classes more than C++. But that was years ago, and Carmack has taken an interest to functional programming so perhaps they are more up to date nowadays.. although I'm guessing they have a ton of legacy code written in C style and C with classes style.. Perhaps he is using a haskell IDE for eclipse?
Re: new DIP47: Outlining member functions of aggregates
This seems like a waste of time compared to the other complaints Manu brought up(bad IDE/debugger support etc.)
Re: Had another 48hr game jam this weekend...
Yes IDE should be built with the language :) D has bad IDE support that is why I read about D but don't actually use it...
Re: D vs C++11
I'm not convinced D has caught up to C++ yet from a usability standpoint, as the tools are still quite bad(VisualD -not- fun). But the other day I tried out MonoD and it shows promise, auto completion is solid, and it seems to have at least some of the features I've come to expect from using Visual C++ with Visual Assist. Its still behind though, perhaps in another year? Ideally VisualD would support the completion/reflection stuff MonoD has, and that would be a pretty awesome package that I think would attract many more developers.
Re: Rust and D
Go looks like a horrible combination of C and Lua, lacking the speed of C and the power of Lua(and I'd bet LuaJIT beats Go for performance). Not all features are equal, for me, meta programming is such a useful thing that a language better have something damn impressive to replace it(especially a systems programming language). I scanned through the Rust docs and did not see anything that appeared capable of doing so.
Re: Rust and D
The Rust website says this: Generic types yes, only simple, non-turing-complete substitution After seeing that I just assumed the language was worthless and ignored it.. is there something more to this?
Re: C++Now! 2012 slides
For some reason I found these docs really dull, to much rehashing of C++ 11 which is old hat now. The template stuff might be interesting if not for the knowledge that it will take absolutely forever to compile--
Re: Nimrod language
* Can you do metaprogramming with nimrod templates? Are they as powerful as C++/D in this regard? Docs for templates is very short, making me think you can't do much, but perhaps it just isn't covered? *also what is up with lack of unsigned integer types? *not a big fan of forward declaring things, just seems very primitive, something the compiler should do *can you create unnamed procs? +see closures is upcoming, that should be nice
Re: Nimrod language
Like the design, syntax is way better than D But half of what makes a language are the compilers/debuggers/tool
Re: using d dll/lib with msvc program
HINSTANCE LoadME; LoadME = LoadLibrary(L"C:\\Users\\CrashTUA\\Documents\\visual studio 2010\\Projects\\DynamicLib1\\DynamicLib1\\Release\\DynamicLib1.dll"); func dllprintt; dllprintt = (func)GetProcAddress(LoadME,"trololo"); int i = dllprintt(); return 0; And it gives me acces violation... Well did LoadLibrary or did GetProcAddress fail?
Re: using d dll/lib with msvc program
On Sunday, 13 May 2012 at 19:07:41 UTC, crashtua wrote: Is it possible to build dll or lib with dmc to use it in program builded in microsoft c++ compiler? Yes you can download Visual D, build a D DLL with DMD, and call it from a Visual C++ program. Unfortunately you have to use C to communicate between them, and the D IDE experience is pretty bad. -this forum likes to reject posts with nonsense errors... btw
Re: Let's give a honor to dead giants!
One thing I miss, though, is ctags support for D. You don't know how powerful such a simple concept is; it lets you navigate 50,000-line source files without even batting an eyelid. :-) (Just try that in an IDE, and you'll soon get an aneurism from trying to scroll with a 1-pixel high scrollbar...) You need to use a better IDE then, and get a faster computer, and a mouse with a scroll wheel. With Visual Studio + Visual Assist navigating huge solutions is fairly trivial, and extremely fast. VAX can instantly take you to the definition of any symbol with alt-g(not the build in crap in VS, VAX has better capabilities by far), list all references(not just variables with the same name, it actually understands the code), rename any symbol throughout the entire codebase, and a bunch of other things that only a tool which actually understands the code can do. All of these operations are extremely fast btw.
Re: The Downfall of Imperative Programming
I like functional languages, but the only one that seems to have much support is F#. I've used TBB Flow Graph in C++ and found it to be a major improvement over straight parallel algorithms/tasks/message passing etc which seem to be the norm(like in D). Expressing dependencies between separate nodes was super easy. Do any other languages have support for flow based concurrency like C++/TBB?
Re: Precise GC
That sounds cool, perhaps people can have customizable GC for specific applications? Looking forward to D having a precise GC
Re: [OT] Previously: DMD - Windows -> C# in gamedev
Indeed. And this is usually just to mitigate the fact that C++ is so crap at this sort of code. Maybe D will be tolerable, and this breaking out to script won't be necessary? (though I'm dubious) Yeah C++ is a migraine for that type of code:( I think D would be nicer than C++ for gameplay code, but another reason for scripts is the ability to modify the script while the game is running, and just the general lack of compilation time which is soo nice. Perhaps if D gets ported to mono? Though even then I think I'd prefer Lua, since it is quite good at acting as both a language and data description. I don't typically find C/C++ intolerable, or even particularly unpleasant for engine level code as it is, it's the higher level code I'm keen to escape. Yes I agree! I tend to think of the code I work with as having three levels 1) low level - high performance, optimal memory layout/access, alignment concerns, intrinsic, not much abstraction(unfortunately..). C++ works pretty well here(though any improvements are welcome..), certainly I'm not aware of anything else that is better 2) mid level - good performance, fairly optimal memory, no intrinsics, fairly abstract. C++ works OK here, but I think D could be better at this 3) high level - moderate/low performance, GC memory, JIT'd if you are lucky, but possibly interpreted, can reload scripts while program is executing. Neither D nor C++ work here. #1 isn't actually that much code, but the program probably spends the majority of its time executing it, so it is pretty important Also in reply to Walter-- for me the problem with pausing the GC, and then running it at certain times, is that there is actual no time when it is alright for the GC to take any significant amount of time to collect( a couple milliseconds might be acceptable, but can that be guaranteed?). Some games don't have load screens, or levels, but just an endless streaming world.
Re: [OT] Previously: DMD - Windows -> C# in gamedev
The reason I am conviced is that C++ was the last systems programming language with manual memory management. All the languages people are developing as possible C++ replacement do have some form of automatic memory management. Meanwhile smart pointers and a GC API became part of the C++ language standard. In the future, if you want to target Windows 8 Metro games, you will need to use WinRT which requires C++/CX and makes use of reference counting in the language. Apple added GC to Objective-C, which has some problems with existing frameworks, so their next step was to introduce ARC. This is why I think that eventually even games engines will be developed in a language that supports some kind of automatic memory management be it GC or reference counting. Well games often already integrate scripting languages, generally Lua or Mono, which are both GC based. But this is for the game logic, not for the high performance parts of the code. For a GC to be used at the C++/D layer it would need to be 1) optional always, D makes it optional but you loose a solid chunk of the language if you ditch GC, what remains is in some ways inferior to C++(no escaping lambda without GC, /cry) 2) no long pauses ever I think most game engine stuff will continue to be written without GC, as it doesn't really add much if what you are after is raw performance. And C++ does have smart pointers which perform much of what a GC does, but without the long pauses or non deterministic destruction.
Re: DMD - Windows
A great IDE is essential for D to really succeed. Visual D is a solid start but it isn't really usable for a large project yet. - The debugging experience is funky, it can't seem to see many variables - hovering over variables generally doesn't show anything useful - hitting . doesn't pop up possible members - very limited syntax highlighting D might have simplified C++ syntax, but it is still quite complex, not having an IDE that supports the type of things that Visual Studio supports is just painful-- I doubt D has any chance in the game industry without much better VS support. Aside from C++ I also use Lua quite often and even in a light weight scripting language like Lua I much prefer an IDE(Decoda--Manu it works with embedded scripts btw).
Re: SIMD support...
That Cuda is used more is probably true, OpenCL is fugly C and no fun. Microsoft's upcoming C++ AMP looks interesting as it lets you write GPU and CPU code in C++. The spec is open so hopefully it becomes common to implement it in other C++ compilers. SSE intrinsics in C++ are pretty essential for getting great performance, so I do think D needs something like this. A problem with intrinsics in C++ has been poor support from compilers, often performing little or no optimization and just blindly issuing instructions as you listed them, causing all kinds of extra loads and stores. Visual Studio is actually one of the worst C++ compilers for intrinsics, ICC is likely the best. So even if D does add these new intrinsic functions it would need to actual optimize around them to produce reasonably fast code. I agree that the v128 type should be typeless, it is typeless on hardware, and this makes it easier to mix and match instructions.
Re: Reference counted containers prototype
When I go to that link it just says Unknown Paste ID! Don't see any code anywhere.. hum What is wrong with value containers? They work great in C++, a container is such a basic thing that ref counting and whatnot is rarely if ever needed, and in the unlikely event you need to share a container, wrapping it with a smart pointer of some sort is easy enough in C++, let alone D with its better support for type aliasing.
Re: std.container and classes
On Wednesday, 21 December 2011 at 12:50:44 UTC, so wrote: On Wed, 21 Dec 2011 07:37:33 +0200, Andrei Alexandrescu wrote: a great mathematician Name please? I believe he is referring to http://en.wikipedia.org/wiki/Alexander_Stepanov
Re: std.container and classes
I don't really think ref counted struct vs class is fair, because in reality most containers don't need ref counting. I can't think of one instance in C++ where I stuck a container directly in a shared_ptr or anything similar. Also as far I as I can tell making it a class would bloat it with unnecessary data(vtable), and being it is common to have many many instances of these containers, that doesn't sound like such a great thing.
Re: d future or plans for d3
D's pass-down lambdas do not need memory allocation. As far as I remember none of std.algorithm's use of lambda allocates memory. Andrei Oh cool, I like that
Re: d future or plans for d3
C++ "closures" do not allow you to maintain a reference to the context after the function containing said context returns. Instead, C++ allows you to choose between copying the variables into the lambda instance, or referencing them (the references may not "escape"). The compiler may or may not enforce correct uses of reference captures. In contrast, D's approach is both intuitive (does not copy variables) and safe (conservatively allocates on the heap), with the downside of requiring the context to be garbage-collected. Ah, makes sense now, thanks. Still it seems like a case of "you pay for what you don't use", and seems like a real downer for adopting D since you loose the ability to use lambda's without having the GC shoved down your throat(wouldn't be so bad if the D GC was known for performance, but everything I've read indicates it is quite slow).
Re: d future or plans for d3
The class will still have a vptr. The vtable will contain only the type info. No way to disable type info(like in most C++ compilers you can disable RTTI)? I get that GC might want it, but if I disable GC why would I want type info? I saw that D is planning to make the standard containers into classes with final methods, why do this instead of using structs if it bloats each instance of the container? Some aspects of D will _always_ require a GC or they won't work. Array concatenation would be a prime example. I believe that delegates are another major example. I think that scoped delegates avoid the problem, but any that require closures do not. Other things be done but become risky - e.g. slicing arrays (the GC normally owns the memory such that all dynamic arrays are slices and none of them own their memory, so slicing manually managed memory gets dicey). The array concatenation requiring GC I get, but why does a delegate require it? This link says D allocates closures on the heap http://en.wikipedia.org/wiki/Anonymous_function#D I don't really get why, C++ lambda works well(aside from broken lack of template lambda's) and do not require heap usage, even binding it to std::function can generally avoid it if it doesn't exceed the SBO size
Re: d future or plans for d3
I've only recently tried D out, but what I'd like to see.. -GC being truly optional -being able to specify if the standard library should use GC or not, perhaps with allocators -if D is going to have a GC, then a precise, compacting one would be cool, but not if it gets in the way of making the GC optional One thing I'm not sure about, D classes are virtual by default, but if you mark all functions as final does the class still contain a VFP or any other cruft? Also why are class functions virtual by default? My experience in C++ is that I rarely use virtual, so I don't really understand why that is the default.
