New answers tagged

1

Is there a reason why C#/JS require explicitly differentiating a declaration from assignment? There is, you don't want typos to declare new variables, you want them to not work. For example, consider the following Python code: someValue = 42 if someCondition: someVaule = 43; This is clearly a bug caused by a typo, but Python does not prevent you ...


0

You need to learn more programming languages, there is much more than C# & Javascript & C++ & Python. So read Scott's  Programming Language Pragmatics book & SICP (a very good introductory book that would teach you Scheme) In particular, variables in Ocaml, Scheme, Common Lisp, Haskell are quite different than what you believe (or what they ...


3

there are two distinct steps involved, "creating" a variable, and "assigning" a value. Think of it like "building a house" and "renting a house". the house may only be built once, but can be rented an infinite number of times. Different languages handle it differently because some language designers think its a good idea to let a house be built whenever you ...


10

But that's easy - just check if foo was declared earlier And therein lies your problem. In languages like Javascript, it's all too easy to "shadow" a variable that you've already defined earlier without knowing it, and now you've got strange behavior that you can't explain. The problem is exacerbated in Javascript because all variables not otherwise ...


4

There are several benefits, the obvious one is at compile time to ensure that things like function parameters match the values being passed in. But I think you are asking about what is happening at runtime. Keep in mind that the compiler will create a runtime that embeds knowledge of the data types in the operations it performs. Each chunk of data in ...


0

The way concatenative or stack based languages generally use values is actually "read once", the difference being of course that there are no variables, just values on a stack. As you're relaying on the stack most of the time (variables are usually avoided), and values are consumed by the functions ("words") reading them, you have to explicitly duplicate ...


2

You've chosen an unusual architecture. What you are calling a stack machine isn't really what we typically call a stack machine. A stack machine is a type of computer architecture. Since your stack machines cannot execute a program, they aren't an instance of computer architecture, and thus what you are implementing is not properly a stack machine. But, ...


2

A compiler could guarantee that the return this + function chaining pattern has never worse performance than calling multiple methods on the same object, by always rewriting the former pattern into the latter. But I think it would be a relatively complicated rewrite and I'm not sure it would be worth the effort. Especially since I believe the return this ...


3

can it be optimized with no overhead? How? As Telastyn wrote, one approach is to have a compiler providing two function versions. If I were in the role of a compiler designer, I would handle it this way: I would build a compiler with inlining support. Such a tool can obviously optimize the return this statement out when it is not used. and if this ...


1

In theory, yes. C++ has a term for it: copy elision. The C++ standard allows for copy elision. The concept you are asking about, in fact, has its own tla: RVO (return-value optimization). Essentially, the compiler can (but, unfortunately, is not required to) decide on the space where the return value will reside before the function is called. This ...


3

Returning an object of built-in type from a function usually carries little to no overhead, since the object typically fits in a CPU register. The point of this comment from wikipedia isn't that returning the value has no cost. Overhead is additional cost, and the here the cost is in addition to that of the return value mechanism. The article is ...


0

@Groostav, answering rather than commenting so I can say a bit more. Interesting post. Since I asked my question, I made a bit more progress, so have a bit more perspective. I think Id try to initially use something standard like YAML or JSON. Then if you feel you are stretching the boundary of what the config management system can do, only then would I ...


1

If the implementation uses a calling convention that uses the same register to pass the this pointer to a function that it does to return a value from the function, then return this is a zero-cost operation (because the return value is already there).


1

I'm actually in the process of debating exactly this. My issue is that I want to give our users really pretty YAML documents to edit by-hand and then load back into our software --something akin to what CircleCI does with their circle.yml file. We're on the JVM and SnakeYAML is a very nice YAML serializer/deserializer, so I can simply add it to my project ...


3

At least in C#, your desired construct is entirely unnecessary. You can write something like var mylist = new List<string>(new[] {"Hello", "World"}); ... mylist.AddRange(new[] {"Add", "Some", "More", "Items"}); which is about as concise as you can get, while still being perfectly readable. If you really want method chaining in a class, even one ...


10

First off, var list = new List<string>(); list.Add("hello"); list.Add("world"); Is just as, if not more readable than var list = new List<string>().Add("hello").Add("world"); Lines of code is not, in any way a proxy for code's cleanliness or simplicity. Thus my question for this very particular pattern (i.e "return this" for method ...


1

Dart has this feature. So you can do StringList myList = new StringList() ..Add("hello") ..Add("world"); Here we can treat F(expr..m(...)) as syntax sugar for: var _generated_temp = expr; _generated_temp.m(...); F(_generated_temp); You can see Dart also allows setting properties to be chained in the same way: Person myPerson = new Person() ...


6

C++ and Go are designed to compile to native machine code. Both have a phase during building where separate modules are linked together to produce a single combined module. Once this has been done, a complete list of all available objects is available. Therefore, the easiest way to initialise any object that requires initialisation is to scan that list, ...


1

My ideas on why lazy initialization may be preferrable in .NET: Eager init can be quite hard to debug I don't know about now, but earlier, when I had problems with static init in C++, it was a nightmare and I rather went away from using static in some cases. Static init dependencies can be a headache even in C#, luckily they are much easier to debug and ...


2

For what it's worth, this actually has a semi-practical use. In the scenario you have set up, you can only use objects of type A or B via the interface defined by A. The function B::f is only callable via virtual dispatch, not directly. For example: B * pb = new B {}; A * pa = pb; pa->f(); // fine, calls B::f via virtual dispatch pa->A::f(); ...


1

It's absolutely intentional. Changing the visibility must (at most) change whether your code compiles or doesn't compile. It must never, ever change what the code does. If B::f() were public, then you would expect B::f() to be called. The fact that you made b::f() private cannot change this, according to the rule above; it is only allowed to change whether ...


4

C is a low-level language, nearly a portable assembler, so its data structures and language constructs are close to the metal (data structures have no hidden costs - except padding, alignment and size constraints imposed by hardware and ABI). So C indeed does not have dynamic typing natively. But if you need it, you could adopt a convention that all your ...


8

You hit on one of the only reasons this is useful: mapping external data structures. Those include memory-mapped video buffers, hardware registers, etc. They also include data transmitted intact outside the program, like SSL certificates, IP packets, JPEG images, and pretty much any other data structure that has a persistent life outside the program.


3

In my opinion, the main reason this feature is not available due to the language designers not being required to implement it or not seeing point in doing that since this can be already achieved with lambdas in a sane manner. The feature is most probably technically possible, since all expressions can be written as lambdas The adoption would mean that each ...


1

We already know that the expression tree generation mechanism is able to generate an expression tree for any arbitrary expression, because it's able to generate an expression tree for any arbitrary expression within a lambda. So it's clear that technical limitations are not the problem. The most likely answer is that it was used only set up for automatic ...


2

I don't know if they're a core golang dev, but Aram Hăvărneanu answered this question here: The structure of an import path is not part of the language specification, so it has to be a string [...] to allow flexibility and to avoid locking in some semantics forever. I agree with you: I think the majority of programmers won't need those non-standard ...



Top 50 recent answers are included