Reputation
4,422
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
8 18
Newest
 Good Answer
Impact
~428k people reached

  • 0 posts edited
  • 0 helpful flags
  • 188 votes cast
2d
comment Why encapsulate container variables?
It's too bad this question was closed as a duplicate, since objects which encapsulate containers are often a special case. If an object is specified to do everything a bunch of fields could do (including assigning arbitrary values to fields in arbitrary order, without side-effects, and having every read request yield the last value written), I would say regard the exposure of public fields as a good way to make that expectation clear.
2d
comment Why is chaining setters unconventional?
VB.NET also has a usable "With" keyword which creates a compiler-temporary reference so that e.g. [using / to represents line break] With Foo(1234) / .x = 23 / .y = 47 would be equivalent to Dim temp=Foo(1234) / temp.x = 23 / temp.y = 47. Such syntax does not creating ambiguity since .x by itself can have no meaning other than to bind to the immediately surrounding "With" statement [if there is none, or the object there has no member x, then .x is meaningless]. Oracle hasn't included anything like that in Java, but such a construct would fit smoothly in the language.
Feb
1
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@JanHudec: Fair point that unless the last reference is getting overwritten there's no need to go into the tree. The point I'd meant to make was that code which overwrites a reference in Java or .NET doesn't need to worry about the internals of the target of that reference but C++ code does; I neglected to consider that since it the scan only happens once per object lifetime, it's not a performance drain on ref-copies that don't end an object's lifetime, but it can still add complexity.
Feb
1
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@JanHudec: How efficiently do C++ and Rust handle immutable trees or other such structures? In a scanning GC framework, the time to copy a reference to an immutable tree with N nodes can be O(1). Is that true with any smart-pointer types in C++ or Rust?
Feb
1
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
...that nothing trashes it before foo's last attempt to access it using the passed reference. Omitting the reference-count updates would usually be safe, but I don't know how often it can be statically verified as being safe.
Feb
1
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@JanHudec: In Java or .net, given foo(someObject.someField), a compiler can simply read the field and pass it with no other overhead; even if that field held the last reference to an object and gets overwritten by foo (using a reference to someObject stored elsewhere), metadata will allow the GC to know about the copy of reference that was created by the function call. By my understanding, C++ would have to either atomically update the reference count before and after the call, or else hope that if someObject.somefield held the last surviving pointer to an object...
Feb
1
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@JanHudec: In a GC framework, references to shared immutable objects may be manipulated without any locking or extra overhead provided that the GC can freeze everything long enough to determine what references exist. The amortized overhead of stopping everything for the GC will in many cases be less than the overhead required to acquire locks every time a reference is copied or overwritten.
Jan
31
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@JanHudec: It seems a shame that no language seems to include clear concepts of both "owned" and "unowned" objects. C++ does a good job of handling objects with clear owners, but has some difficulty efficiently handling owner-less objects in multi-threaded code (since even things like pointer assignments require thread synchronization) but GC languages fail to provide concepts of object ownership.
Jan
30
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@JanHudec: I've not used Python much; you're saying it can support C++-style RAII? That would be cool. Too bad there's no way (so far as I know) to distinguish between "I want to update a property I expect something to have" versus "I want to create a new property"; it my limited experience, as with JavaScript, typos are prone to yielding programs that are valid but wrong, rather than compilation errors.
Jan
30
comment Benefit of non-volatile access to volatile objects being undefined?
The problem isn't with the language that people actually use--it's with the failure of the standard to acknowledge reality. If some particular platform has a weird hardware reason why a non-qualified access to a volatile variable should have some consequence beyond being unsequenced relative to other volatile accesses, I see no reason such a platform shouldn't be allowed to have a conforming C compiler if that quirk is documented, but there's a huge gap between that and saying that compilers can do whatever they want without having to document anything.
Jan
30
comment Benefit of non-volatile access to volatile objects being undefined?
Unfortunately, the authors of the Standard are often extremely loath to say what compilers "should" do, with the consequence that even in cases where programmers and compiler writers would historically have agreed that certain behaviors should be defined when practical, and where the vast majority compilers for non-weird platforms have historically defined them absolutely consistently, some modern compiler writers feel no obligation to abide by such behaviors.
Jan
30
comment Benefit of non-volatile access to volatile objects being undefined?
The Standard need not go so far as to say "the behavior is Undefined". It could just as easily (and IMHO more usefully) say that accesses which are not volatile qualified are unsequenced relative to volatile-qualified accesses of other memory locations. On some implementations, accessing volatile locations in the wrong sequence may invoke Undefined Behavior, and on such platforms mixing volatile-qualified and non-qualified accesses would have that as a likely natural consequence, but if an implementation doesn't care about the sequencing of accesses there's no reason the compiler should.
Jan
30
comment Benefit of non-volatile access to volatile objects being undefined?
@MSalters: On the other hand, given how vague the Standard is with regard to volatile variables, accessing a location both with and without the volatile qualifier should be no less implementation-defined than access to volatile-qualified variables in the first place. A conforming implementation may specify (and many do!) that certain volatile variables may only be accessed in certain ways, and any other accesses will invoke Undefined Behavior. I see no reason why such license would not extend to describing what happens if a variable is sometimes accessed as volatile sometimes and not.
Jan
30
comment Benefit of non-volatile access to volatile objects being undefined?
@MSalters: One of the biggest tragedies of the C language is the failure of the Standard to recognize a category of behavior which combined aspects of Unspecified and Implementation-defined behaviors: implementations MUST list any possible consequence, and SHOULD do so as specifically as practical, but MAY list "Undefined Behavior" as a consequence. I'd posit that most forms of UB should have been thus qualified, and the language would be vastly more useful had that been done.
Jan
29
comment Benefit of non-volatile access to volatile objects being undefined?
Some compiler writers don't need a particular "reason" to take advantage of Undefined Behavior. If they can determine that the Standard imposes no requirements on the behavior of a certain code path, they'll assume it cannot occur, regardless of whether there would otherwise be any real difficulty executing the code on that path.
Jan
29
comment Benefit of non-volatile access to volatile objects being undefined?
I fully recognize that it would make sense to have a rule that specifying that if a variable is accessed by a pointer that is not volatile-qualified the access may be reordered with regard to accesses of other volatile variables, and I recognize that in many cases such reordering could cause problems that would end up invoking UB, but if program behavior would be well-defined if a global variable were not declared variable, is there any reason why making the variable volatile should cause the program to invoke UB if nothing actually required that it be volatile?
Jan
29
comment Why can't arrays be passed as function arguments in C?
Given that C originally didn't have prototypes, was there any compelling reason to allow void foo(int bar[34]); as an alternative form of void foo(int *bar); rather than simply having it not mean anything until the language gained the ability to pass non-primitives by value? I can see a good reason to allow passing an array to a function expecting a pointer, but that wouldn't require that parameters declared as array types would have to work the same way.
Jan
29
comment Why do C arrays not keep track of their length?
@delnan: Separating out things that can accept slices from things that can't, and requiring things that can accept slices to receive two pieces of information would slightly impair the efficiency of things that can accept slices, but would improve the efficiency of things that can't since a compiler would know that array1[4] and array2[3] couldn't alias.
Jan
29
comment Why dynamic memory allocation functions in C returns void*?
@BartvanIngenSchenau: It's too bad that C reused the "void" term from functions rather than adding an "untyped memory chunk" type which would allow the free casting of void*, but could also be read and written like "char*". That would allow code to exploit platforms whose minimal addressable unit is smaller than 8 bits and avoid the need to cast untyped memory pointers to char* before using them.
Jan
29
comment What do other languages offer when it comes to infrastructure technology that could indicate its advantage over C in the future?
@RobertHarvey: Modern C is an unsafe language because even in cases where C language constructs would appear to map to machine instructions, there is no guarantee that their corner cases will match those of the machine instructions. Standard C doesn't define all the operations needed for systems programming, but most implementations effectively extended C to include them by design if not by documentation. Unfortunately, modern compilers seek to eliminate such extensions from the language, but fail to provide any alternatives.