Re: Is garbage detection a thing?
On Sunday, 29 November 2020 at 19:09:07 UTC, Mark wrote: Looking at Ada now. I found: Ada is not good for me. It has no augmented assignment. It's just that I want DRY because I use very verbose variable names Using a reasonable naming convention should be much easier than looking for a perfect custom language. Well, another variant is zig, which was supposed to be C but safe.
Re: Is garbage detection a thing?
Recovering from memory errors at run time is unreliable. I should add that I have more like a romantic view of software release cycles where testing is done until the software is in a very, very sophisticated and stable state. More than usual. Not that I want to solely rely on such an approach. It should still try to recover from failures, and recovering should be trained like fire fighting is trained. But there should be no smokers in the building, so to speak.
Re: Is garbage detection a thing?
Elimination of memory problems is much more valuable than detection. Recovering from memory errors at run time is unreliable. I'm not sure but I have a gut feeling that I am just in a position that is not good to defend. I want small software that fails hard on weak causes, and the industry wants software that fails soft on strong causes. I cannot win any argument and will, as hobbyist who likes elegant code, face frustration after frustration, admittedly in all digital products, not only compilers. I'm sure you're right. Elimination of memory problems is what must be provided. I agree. The advantage of D is that all options are open. This allows the following approach: ... ... This makes starting a project in D a safe choice, in multiple meanings of the word. — Bastiaan. Thanks! :) Well, in the end, there should be a way like this.
Re: Is garbage detection a thing?
The reason this distinction is important, and the reason I bring up graph theory, is that liveness is impossible to prove. Seriously: it's impossible, in the general case, for the GC to prove that an object is still alive. Whereas it's trivial to prove reachability. My motivation was actually just that I wanted a very small compiler with no libraries, because I got a bit tired of big things with little defects. But the liveness is a thing I would like to say something about: I don't want a compiler that tries to prove it for me. The reason is that if I did manual memory management and created a use-after-free bug, then my personal world would be still very good. It's just that the industry isn't happy when releasing banana software is a serious problem? In the case of the use-after-free I would say that my software needs correct memory state and correct logic. The logic so to speak is what I actually wanted to implement in the first place. If the program is perfect and works in all situations, how could it do this with bugs in the memory management? It can't. So, I didn't really think often about it, but when Rust came out, there was some trend into this direction, and my feeling was: I can follow it, it looks good, but can I still just use C? The way it works would just be that I have correct out-of-bounds and use-after-free/double-free detection and race condition detection if my software is supposed to be chaotic server or browser software (?), both things at runtime. Given that it is true (?) that software cannot do a task correctly when it does part of it (memory management) incorrectly. More or less it was an idea to get what Rust and Swift try to do without all the language features. C with less language constructs would be nice. It's just that the processors are bad for me, for what I'm trying to do. Intel offers MPX. It's good I guess. But why does Visual C++ implement it like an easter egg. Why have they now added ASAN as experimental feature that immediately fails. They do things I don't really like, because the industry needs it like this, but not me. And at the high level, there's bloat and fancy colors. I want just a toolkit to create exactly what can be created, and if I do it wrong it should fail hard. And I'm trying to make it so that I don't write assembly, if that is possible and good in my situation. I'd say, I have just not understood the whole thing and maybe should try a different hobby, or finally create the thing I'm looking for, which turns out to be an endless story. It's just that a few hours ago I had the hope that the holy grail would exist. I had found the solution to almost every problem in Golang. And then after one year my hobby just broke down, because Go outputs wrong line numbers. It's no good compiler when it does that. I'd rather quit my hobby than accept it. Thanks a lot for your explanation! Really kind regards, you helped me to understand it.
Re: Is garbage detection a thing?
On Sunday, 29 November 2020 at 16:05:04 UTC, Mark wrote: Hi, can I ask you something in general? I don't know anyone whom I could ask. I'm a hobbyist with no science degree or job in computing, and also know no other programmers. I have no good understanding why "garbage collection" is a big thing and why "garbage detection" is no thing (I think so). In order to detect garbage, you need extensive run-time instrumentation, the difficulties of which you have indicated yourself. In addition comes that detection depends on circumstance, which is an argument against the debug/release strategy you proposed. There is no guarantee that you’ll find all problems in the debug build. Garbage collection also comes at a runtime cost, but strategies exist to minimise those, and in addition a GC enables valuable language features. One such strategy is to minimise allocations, which improves performance in any memory management scheme. [...] What I don't understand is, when today there exist tools for C++ (allocator APIs for debugging purposes, or Address-Sanitizer or maybe also MPX) to just detect that your program tried to use a memory address that was actually freed and invalidated, why did Java and other languages not stop there but also made a system that keeps every address alive as long as it is used? Elimination of memory problems is much more valuable than detection. Recovering from memory errors at run time is unreliable. One very minor criticism that I have is: With GC there can be "semantically old data" (a problematic term, sorry) which is still alive and valid, and the language gives me the feeling that it is a nice system that way. But the overall behavior isn't necessarily very correct, it's just that it is much better than a corrupted heap which could lead to everything possibly crashing soon. At least in D, you can avoid old data to hang around for too long. See core.memory. Or maybe I could use the safe-c subset in D? But I believe it uses garbage collection. I know nothing about it, sorry. @safe D is not a sub-set, indeed it uses garbage collection. Fact is that there are very few domains where this is a problem. Not all garbage collectors are equal either, so if you think garbage collection is bad in one language, this may not directly apply in another. In D the garbage collector is even pluggable, various implantations exist. Have you seen the GC category on the blog?https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/ BetterC is a subset of D, it does not use garbage collection. You may be interested in current work being done in static analysis of manual memory management in D: https://youtu.be/XQHAIglE9CU The advantage of D is that all options are open. This allows the following approach: 1) Start development without worrying about memory. Should collection cycles be noticeable: 2) Profile your program and make strategic optimisations https://youtu.be/dRORNQIB2wA. If this is not enough: 3) Force explicit collection in idle moments. If you need to go further: 4) Completely eliminate collection in hot loops using @nogc and/or GC.disable. When even this is not enough: 5) Try another GC implementation. And if you really need to: 6) Switch to manual memory management where it matters. This makes starting a project in D a safe choice, in multiple meanings of the word. — Bastiaan.
Re: Is garbage detection a thing?
On Sunday, 29 November 2020 at 16:05:04 UTC, Mark wrote: I have no good understanding why "garbage collection" is a big thing and why "garbage detection" is no thing (I think so). Because it's just as expensive to do garbage detection as automatic garbage collection. So if you're going to go to the work of detecting when something is garbage, it's basically free to detect it at that point. today there exist tools for C++ (allocator APIs for debugging purposes, or Address-Sanitizer or maybe also MPX) to just detect that your program tried to use a memory address that was actually freed and invalidated, Note that address sanitizer is significantly slower than most ‘real’ GCs (such as are used by java, or others). why did Java and other languages not stop there but also made a system that keeps every address alive as long as it is used? Then the debug build would use a virtual machine that uses type information from compilation for garbage detection, but not garbage collection. Address sanitizer does exactly what you propose here. The problem is this: Testing cannot prove only the presence of bugs; never their absence. You may run your c++ program a thousand times with address sanitizer enabled and get no errors; yet, your code may still be incorrect and contain memory errors. Safety features in a language--like a GC--prevent an entire class of bugs definitively. One very minor criticism that I have is: With GC there can be "semantically old data" (a problematic term, sorry) which is still alive and valid, and the language gives me the feeling that it is a nice system that way. But the overall behavior isn't necessarily very correct, it's just that it is much better than a corrupted heap which could lead to everything possibly crashing soon. The distinction here is _reachability_ vs _liveness_. So, GC theory: A _graph_ is type of data structure. Imagine you have a sheet of paper, and on the sheet of paper you have a bunch of dots. There are lines connecting some of the dots. In graph theory, the dots are called nodes, and the lines are edges. We say that nodes A and B are _connected_ if there is an edge going between them. We also say that A is _reachable_ from B if either A and B are connected, or A is connected to some C, where C is reachable from B. Basically, if you can reach one point from another just by following lines, then each is reachable from the other. A _directed_ graph is one in which the edges have directionality. Imagine the lines have little arrows at the ends. There may be an edge that goes A -> B; or there may be an edge that goes B -> A. Or there may be both: A <-> B. (Or they can be unconnected.) In this case, to reach one node from another, you have to follow the arrows. So it may be that, starting at A, you can reach B; but you can't go the other way round. The _heap_ is all the objects you've ever created. This includes the objects you allocate with 'new', as well as all the objects you allocate from the stack and all your global variables. What's interesting is that we can think of the heap as a directed graph. If object A contains a pointer to object B, we can think of that the same as way as there being an edge going from node A to node B. The _root set_ is some relatively small number of heap objects that are always available. Generally, this is all the global variables and stack-allocated objects. The name _reachable_ is given to any object which is reachable from one of the root set. It is impossible for your program to access an unreachable object; there's no way to get a pointer to it in the first place. So it is safe for the GC to free unreachable objects. But we can also add another category of objects: _live_ vs _dead_ objects. Live objects are ones which you're actually going to access at some point. Dead objects are objects that you're never going to access again, even if they're reachable. If a GC could detect which reachable objects were dead, it would be able to be more efficient and use less memory...hypothetically. The reason this distinction is important, and the reason I bring up graph theory, is that liveness is impossible to prove. Seriously: it's impossible, in the general case, for the GC to prove that an object is still alive. Whereas it's trivial to prove reachability. Now, it is true that there are some cases where an object is dead but still reachable. The fact of the matter is that in most such cases, the object becomes unreachable shortly thereafter. In the cases when it's not, it tends to be impractical to prove an object is dead. The extra work that it would take to prove deadness in such cases, if it were even possible to prove, would make it a not worthwhile optimization. And when I have tested all runtime cases of my compiled software, which runs slow, but quite deterministically, I will go on and build the release
Re: Is garbage detection a thing?
On Sunday, 29 November 2020 at 16:35:26 UTC, Mark wrote: Maybe I should just install Linux. But ... the drivers... My Thinkpad just doesn't like any Linux. I run out of ideas. In the first place all I wanted to do is make some music. Kind regards You could try a linux image in VirtualBox or VMware, to more easily evaluate if linux + ASAN matches your expectations or if it's another dead-end. Regards, Daniel
Re: Is garbage detection a thing?
Looking at Ada now. I found: Ada is not good for me. It has no augmented assignment. It's just that I want DRY because I use very verbose variable names, and in the past I had a real world case (game in Lua) where I became frustrated when I had to repeat the names. I understand that NASA or so will repeat their variable names. They get paid. ;) Kind regards
Re: Is garbage detection a thing?
I could use AddressSanitizer indirectly by using Go. But their Oh wait, it was ThreadSanitizer that Go uses, right? I failed at talking. I would probably use ASAN under Linux, because that is the right thing to do? Looking at Ada now.
Re: Is garbage detection a thing?
On Sunday, 29 November 2020 at 16:21:59 UTC, Daniel N wrote: On Sunday, 29 November 2020 at 16:05:04 UTC, Mark wrote: Thanks a lot for reading, and sorry for a lot of text that is off-topic and is not related to D. Sounds like what you want is ASAN? You can use it with plain C or D(LDC). https://clang.llvm.org/docs/AddressSanitizer.html I could use AddressSanitizer indirectly by using Go. But their compiler gave me wrong line numbers for errors and I have not yet overcome this psycholocicaly, to be honest. They have a fixed version, which is a WIP which is already using generics. So I went on and saw that Visual C++ now features AdressSanitizer. It showed faulty behavior very soon, a false positive AFAIR. It's in experimental stage. /d2MPX is out of the early development stage but it's no prominent feature. I went on with Nim, which then gave me wrong line numbers for error messages. I'm not counting wrong, they really do, both Golang and Nim gave me errors that triggered me. ;) I began a little C compiler project based on c4, knowing that I would be very old when this should ever be finished. Actually I am looking for a good compiler for Windows or maybe macOS, and looking at JAI, too. Maybe I should just install Linux. But ... the drivers... My Thinkpad just doesn't like any Linux. I run out of ideas. In the first place all I wanted to do is make some music. Kind regards
Re: Is garbage detection a thing?
Maybe Ada.
Re: Is garbage detection a thing?
On Sunday, 29 November 2020 at 16:05:04 UTC, Mark wrote: Thanks a lot for reading, and sorry for a lot of text that is off-topic and is not related to D. Sounds like what you want is ASAN? You can use it with plain C or D(LDC). https://clang.llvm.org/docs/AddressSanitizer.html
Re: inout(shared) as a thing?
On 2/7/18 5:19 AM, Nicholas Wilson wrote:
I was reading
https://github.com/rikkimax/stdc-signatures/blob/master/stdc/graphic/image.d#L54
as part of
https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md and it
struck me that the duplication of `IFoo` and `ISharedFoo` might be made
redundant `with inout(shared)` as `inout` (->`inout(const)`? so that one
can write `inout(shared,const)`. obviously no need to deprecate plain
inout) is to mutable/const/immutable.
I think this would work for "declarations" like
interfaces/signatures/contraints, I'm not so sure about implementations
as the acquisition of ownership needs to occur to take place in order to
avoid data races.
Maybe inout(shared=(T t){...}) where (T t){...} is a lamda (or some
other builtin) that ensures that t (or this) is owned by by the
executing thread. could also have inout(shared=synchronized),
inout(shared=synchronized(a)) where a is a variable in scope (e.g.
parameter, member,...), inout(shared=atomic) or some wrapper that
atomically loads t or this. Just throwing out ideas.
I don't think this would work on the return value of functions.
Thoughts? Worthy of a DIP?
I'm thinking it doesn't work.
Not because it wouldn't be sound from the standpoint of the type system,
but because there is no "possibly shared" type constructor similar to
const. If you are inside an inout(shared) function, how do you properly
deal with the data? At the moment it's custom based on what your overall
structure looks like. Sure, there are atomics for small shared data
types, and at that level, you could conservatively just atomically load
and store data. But what about shared aggregates? Those require locking
at the right places, and there is no compiler-defined way to do it --
you have to write it yourself. There's just no way to do a "maybe
shared" implementation for it.
-Steve
Re: Is there such a thing?
On Tuesday, 3 March 2015 at 17:17:18 UTC, Taylor Hillegeist wrote: CStyleFunction=Foo ReturnType sint32 /ReturnType Parameter Float64=MyFloat /Parameter /CStyleFunction That's WSDL. It works fine for simple data types. The problem is what to do with complex data types.
Re: Is there such a thing?
On Tuesday, 3 March 2015 at 10:37:49 UTC, Kagamin wrote: On Saturday, 28 February 2015 at 17:06:58 UTC, Dicebot wrote: On Friday, 27 February 2015 at 19:49:37 UTC, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... C is pretty much a standard for cross-language ABI Object files have no language-level compatibility, only linker-level compatibility. You can get function arguments wrong, and linker won't tell you. So, I don't thing C is very easy to pull data from, In fact i would guess the only way this would work is if the compiler produced standard data format like JSON or XML or YAML if you like that kind of thing. And then transformed it to native code. CStyleFunction=Foo ReturnType sint32 /ReturnType Parameter Float64=MyFloat /Parameter /CStyleFunction I think YAML would look nicer... I also know that some languages have certain capabilities. And this is a lot more complex of problem. But I hear about people making automatic binding generators and all sorts of 1 off tools, I just don't understand why there doesn't seem to be common standard solution.
Re: Is there such a thing?
On Saturday, 28 February 2015 at 17:06:58 UTC, Dicebot wrote: On Friday, 27 February 2015 at 19:49:37 UTC, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... C is pretty much a standard for cross-language ABI Object files have no language-level compatibility, only linker-level compatibility. You can get function arguments wrong, and linker won't tell you.
Re: Is there such a thing?
On 2015-02-28 18:06, Dicebot wrote: C is pretty much a standard for cross-language ABI You still need a way to define the bindings. -- /Jacob Carlborg
Re: Is there such a thing?
On Friday, 27 February 2015 at 19:49:37 UTC, Taylor Hillegeist wrote: On Friday, 27 February 2015 at 07:26:06 UTC, Jacob Carlborg wrote: On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... On Windows that standard it is called COM for OO languages, stdcall/pascal for procedural ones and BCL for those targeting .NET. -- Paulo
Re: Is there such a thing?
On Saturday, 28 February 2015 at 17:24:57 UTC, Paulo Pinto wrote: On Friday, 27 February 2015 at 19:49:37 UTC, Taylor Hillegeist wrote: On Friday, 27 February 2015 at 07:26:06 UTC, Jacob Carlborg wrote: On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... On Windows that standard it is called COM for OO languages, stdcall/pascal for procedural ones and BCL for those targeting .NET. -- Paulo Sorry, should have written CLS (Common Language Specification) for those targeting .NET.
Re: Is there such a thing?
On Friday, 27 February 2015 at 19:49:37 UTC, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... C is pretty much a standard for cross-language ABI
Re: Is there such a thing?
On Friday, 27 February 2015 at 07:26:06 UTC, Jacob Carlborg wrote: On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things...
Re: Is there such a thing?
On 2015-02-27 20:49, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... I think that's a completely different topic. -- /Jacob Carlborg
Re: Is there such a thing?
On Fri, Feb 27, 2015 at 09:00:56PM +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-02-27 20:49, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... I think that's a completely different topic. [...] http://xkcd.com/927/ :-P T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Re: Is there such a thing?
On Friday, 27 February 2015 at 21:15:10 UTC, H. S. Teoh wrote: On Fri, Feb 27, 2015 at 09:00:56PM +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-02-27 20:49, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... I think that's a completely different topic. [...] http://xkcd.com/927/ :-P T Yes, But in this case there is like 300 non-competing non-standards.
Re: Is there such a thing?
On Sat, Feb 28, 2015 at 12:35:56AM +, Taylor Hillegeist via Digitalmars-d wrote: On Friday, 27 February 2015 at 21:15:10 UTC, H. S. Teoh wrote: On Fri, Feb 27, 2015 at 09:00:56PM +0100, Jacob Carlborg via Digitalmars-d wrote: On 2015-02-27 20:49, Taylor Hillegeist wrote: I just think its a shame that all over the place people are compiling code in different programming languages, and although all the .o files are compatible with each other there isn't a standard cross language way of defining a binding. But that would be making people agree on things... I think that's a completely different topic. [...] http://xkcd.com/927/ :-P T Yes, But in this case there is like 300 non-competing non-standards. And soon there will be 301 non-competing non-standards. ;-) T -- Question authority. Don't ask why, just do it.
Re: Is there such a thing?
On 2015-02-26 20:53, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? I think it's better to use a package manager to handle this. It will also automatically download the necessary files. Also it will help (hopefully) you to find the libraries you need. -- /Jacob Carlborg
Re: Is there such a thing?
On Thu, 26 Feb 2015 22:10:15 +, Taylor Hillegeist wrote: One of the listed uses for a unit was if the developer wanted to hide his ip but allow others to use the code. Does D have a way of doing this? you can compile static library and provide autogenerated .di file. compiler will strip out all unnecessary parts from it. signature.asc Description: PGP signature
Re: Is there such a thing?
On Thursday, 26 February 2015 at 19:53:54 UTC, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? IIRC, Pascal unit files work that way. No interface source file is required to use them.
Re: Is there such a thing?
On Thursday, 26 February 2015 at 21:37:46 UTC, Marc Schütz wrote: On Thursday, 26 February 2015 at 19:53:54 UTC, Taylor Hillegeist wrote: So, In languages like .net they have dll's that contain not only bytecode but also the necessary headers to make them usable in any .net language. I was curious if this kind of thing has ever been attempted for static libraries? basically some type of universal header + static library = Everything Needed to use in project file. of course they would be targeted for a certain platform but would be really easy to grab/use. And if the header could be agreed upon any compiled language could use the library which would be a huge benefit. Perhaps i'm incorrect in my assumptions. Let me know what you think about the idea? IIRC, Pascal unit files work that way. No interface source file is required to use them. That Looks pretty close to exactly correct: http://www.freepascal.org/docs-html/user/userse11.html It was still two files but it looks like the .ppu was analogous to a c header. like the compiler striped out all the necessary declarations. Very interesting... But I don't think it makes it easier to link to with d. The idea is pretty cool though. I wonder if other compilers do the work of creating sources with the logic striped out for use as a header only. One of the listed uses for a unit was if the developer wanted to hide his ip but allow others to use the code. Does D have a way of doing this?
Re: About the coolest tech thing I've ever seen...
On Wednesday, 16 April 2014 at 20:04:38 UTC, Nordlöw wrote: This make me proud of being an engineer: http://www.wimp.com/powerquadcopters/ I wonder what type system they used when modelling the algorithms ;) Excuse me for posting this a bit of topic...I just had to share this experience with you all brilliant people. This was a very popular video from last year, with millions of views, here's a better link: http://www.youtube.com/watch?v=w2itwFJCgFQ Here's another one I liked, lit quad-copters moving in formation against a night sky: http://www.youtube.com/watch?v=ShGl5rQK3ew
Re: is there such a thing as a static function template that isn't inside of a class?
On 2011-07-16 23:34, Christopher the Magnificent wrote:
I see this code AT THE TOP (MODULE) LEVEL of one of Michel Fortin's
D/Objective-C bridge source files and I'm trying to wrap my head around it.
/** Wrap an object instance within an object of this class. */
static Object
objcCreateWrapper(T)(id instance)
{
// Retain the Objective-C instance prior wrapping it.
// It needs to be done prior wrapping so that
// invariants holds
// after the constructor is called.
objc.msg.send!(id)(instance, selector!(retain));
// Create new Wrapper.
return new T(instance);
}
At issues is the keyword static in front of the template function.
This is not inside of a class, so static does not seem to make sense
with what I know about D. Can anyone explain this to me?
--Christopher
I'm guessing it has no affect on the code, possible it used to be a
static method in a class.
--
/Jacob Carlborg
