228 reputation
19
bio website twitter.com/const_float
location Moscow, Russia
age 24
visits member for 2 years
seen 18 hours ago

system programmer

graduate of BMSTU

interested in functional programming


Nov
7
comment Is it good practice to rely on headers being included transitively?
Note that corollary might be easier to achieve when there are separate declaration and implementation headers and/or no code that would define some run-time entities in declaration ones (such as global variables definitions). This is important because requiring "header must never include another header" is unrealistic - you might only want the types.
Nov
5
comment How to deal with no code reviews in my new place when I come from that practice?
For one, there's this modern study: sail.cs.queensu.ca/publications/pubs/msr2014-mcintosh.pdf
Oct
14
comment Is it possible to have a dynamically typed language without duck typing?
Actually the runtime has a choice to check the type signature of the object before trying to access any of its' fields or calling its' methods. That would be "strong dynamic typing". Note, that Python, for example, is partially working this way -- say, it explicitly issues a type error when you try 1 + "1". In Python's case the discipline of checking is pretty much absent and it's up to implementation of user code to check the types if the user (opposed to Python's runtime) finds it useful. Also note that duck typing vs. non-duck typing is alike nominal vs. structural typing (see Wikipedia).
Apr
25
asked To which level Haskell's HDBC is lazy?
Jan
25
comment Why doesn't Haskell have a 'format' function for string interpolation?
Please note that format as proposed in question shouldn't have any arguments, besides the format string. So it's not variadic per se. Also note that the question doesn't talk about general string interpolation with format specification, it proposes using directly the result of show a.
Jan
25
comment Why doesn't Haskell have a 'format' function for string interpolation?
@TomEllis What kind of better abstraction do you have in mind?
Jan
25
revised Why doesn't Haskell have a 'format' function for string interpolation?
Clarification on nature of question
Jan
24
comment Why doesn't Haskell have a 'format' function for string interpolation?
@TomEllis And not using $-interpolation in exchange for printf wouldn't save me from that mistake.
Jan
24
comment Why doesn't Haskell have a 'format' function for string interpolation?
@TomEllis Because it has awful readability, introduces unnecessary operators, and makes it easy to miss the space on either side of the variable substitution (or add unneeded ones).
Jan
24
revised Why doesn't Haskell have a 'format' function for string interpolation?
Fix -I option
Jan
24
awarded  Yearling
Jan
24
asked Why doesn't Haskell have a 'format' function for string interpolation?
Jan
3
comment What's the reason for C standard to consider const-ness recursively?
@MSalters Jogn Bode's quote only refers to attempts to modify objects which have const-qualified types themselves.
Dec
30
comment What's the reason for C standard to consider const-ness recursively?
Why the downvote?
Dec
30
comment What's the reason for C standard to consider const-ness recursively?
I can "break" the optimizer with absolutely standard compliant code by using memcpy. And optimizer has to be conservative because, well, alias analysis in C compilers just isn't quite "working all the time reliably".
Dec
30
comment What's the reason for C standard to consider const-ness recursively?
Then why a non-writable structure is allowed to be overwritten with i.e. memcpy? As for other reasons — ok, it's legacy, but why was it done in such way in the first place?
Dec
30
comment What's the reason for C standard to consider const-ness recursively?
Well. C barely has a sound type system (more like a bunch of corner cases strapped onto each other over the course of years). Besides, the other way to put the assignment to a struct is memcpy(s_dest, s_src, sizeof(S_t)). And I'm pretty sure it's the actual way it's implemented. And in such case even existing "type system" doesn't prohibit you doing that.
Dec
30
comment What's the reason for C standard to consider const-ness recursively?
I'm 90% sure optimizers may not assume that const fields are not written to, because you always can use memset or memcpy, and that would even be compliant to the Standard. (1) can be implemented as, at the very least, additional warning, enabled by a flag. (2)'s rationale is that, well, exactly — there's no way a component of struct can be considered non-writable when the entire structure is writable.
Dec
30
comment What's the reason for C standard to consider const-ness recursively?
@BartvanIngenSchenau edited to add the question stated in the topic in the end of the body
Dec
30
revised What's the reason for C standard to consider const-ness recursively?
Repeated the question in the end