This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
What is the value of a dialog constant DS_RECURSE (link to the official MS documentation required, historical information is welcome) ?
Thanks for attention.
DS_RECURSE doesn't exist. It was a flag in a prerelease version of Windows 95 that was removed before RTM. All the docs that refer to it talk about "Don't use it", which is now very easy to do because you can't use something that doesn't exist.
http://msdn.microsoft.com/en-us/library/aa925154.aspx
The following styles are not supported for the **style** member of the DLGTEMPLATE structure:
...
DS_RECURSE
Not required. Any child dialog box is automatically considered to be a recursive dialog box.
This is the structure:
typedef struct {
DWORD style;
DWORD dwExtendedStyle;
WORD cdit;
short x;
short y;
short cx;
short cy;
} DLGTEMPLATE;
As you see, style is DWORD so is the value of DS_RECURSE a DWORD as well.
Let it be 0 because not required.
BTW: for what reason do you need it?
Related
This question already has answers here:
How can I build an enum with Dart? [duplicate]
(4 answers)
Closed 8 years ago.
A simple question here :) I'm really happy to see a new feature in the dart language. But I just realized that I kind of never use enumeration.I don't know if there is a discussion somewhere about that but.
What is the pros and cons of this feature in terms of code writing (seems shorter), performance,etc?
Cheers
If I understand it correctly an enum is like a class with const members and some useful methods. Given that cost members are resolved by the compiler using an enum should not incur in any performance hit.
In terms of "code writing" enums are good candidates to replace classic const or static enumerations or, even better, hard-coded constants.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am teaching an upper-division software engineering course and am reviewing every student's code. Some of my students have picked up the habit elsewhere of adding a comment to the right of every closing brace identifying the statement type, such as:
if (x > 3) {
y = 10;
} //if
I have told the students to follow the Android code style guidelines, which says nothing about this practice. On what grounds should I tell them not to do this (besides personally not liking it), or should I permit it?
Comments are for clarifying code and increasing readability. It's clear enough to most reasonable software developers that the statement is an "if." Furthermore, many IDEs and editors automatically highlight brackets such as these, so the comment isn't necessary. Generally, you should save comments for describing what methods, classes and variables do (e.g. in Javadoc), or what subroutines within a method will do. This is based on the general guideline of making sure everything you add improves the code.
Tell them that they should assume that person who review code knows language syntax and how to program. Comments should be rare, indicate and explain some weird and not obvious code section (for instance the api provided by some library is bugged and some workarounds/hacks are needed). We've got documentation (and unit tests) to explain how to use and how code should behave. For educational purpose you can write small class/module filled with such "comment-documentation", give it to students and ask them what did they learn about code from these comments.
Well, most likely this will end up in a discussion based on personal preference - which is not within the scope of stackoverflow. But aI'll answer anyway:
In my opinion, that's a bad thing to do - for multiple reasons.
It messes up the code. the more comments are in there, the less readable it is. A single } in a line tells me, instantly, that the last block ends here. with the comment behind, there is more to read - and no additional info (but people will read anyway, cause they don't know that the comment doesn't include any info... and because people tend to read everything automatically)
It leads to sloppy indentation. After all, that may even be the reasons people started that in the first place.
it's unnecessary - if I indet the code in a consistent manner, it shouldn't be necessary to note what was closed, it should be easily visible by just going up to where the last statement with the same indentation level was. In most cases (unbless you're reverse-indenting (or whatever that is called), which I don't like at all) this should be very easy, as there is nothing in between...
it leads to bigger file sizes. may be invalid on modern systems, but still.
Every time is overkill. It depends on the level of indentation and the length of your function, but these are usually signs that you need to step back and refactor. The only time I explicitly do it is for namespaces in C++
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
Having referenced this question: Can an enum class be converted to the underlying type?.
In my code I have effectively:
enum class STATE : short
{
EMPTY,
PRESENT,
PARTIAL,
};
volatile STATE state;
Then I write a typedef and a static_assert:
typedef volatile std::underlying_type<STATE> state_type;
static_assert (sizeof (state_type) == sizeof (short), "Error - unsafe for use with InterlockedCompareExchange16");
Finally I attempt to set the state with InterlockedCompareExchange16:
if (InterlockedCompareExchange16 (static_cast<state_type *>(&state), STATE::PRESENT, STATE::EMPTY) == STATE::EMPTY)
{
}
I am getting the following errors from VS2012:
My static_assert fails complaining that state_type is not the same size as short
The static_cast complains that it cannot cast from volatile STATE * to state_type *
Please can anyone give me any pointers for how to best fix my code?
From std::underlying_type:
Defines a member typedef type of type that is the underlying type for the enumeration T.
Change to:
typedef typename std::underlying_type<STATE>::type state_type;
//^^^^
A motivation for the strongly typed enum class was to prevent conversion to int, so attempting to cast to the underlying type conflicts with the intended use of the enums (see Strongly Typed Enums (revision 3)).
Instead of using OS specific threading mechanisms use std::atomic<> template that was added to c++11:
std::atomic<STATE> state(STATE::EMPTY);
STATE expected(STATE::EMPTY);
if (state.compare_exchange_strong(expected, STATE::PRESENT))
{
// 'state' set to 'PRESENT'.
}
This removes the requirement for static_assert and does not require any casting.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
Should I use ?
{ :first_name => "Mathieu", :last_name => "Jackson" }
or
{ first_name: "Mathieu", last_name: "Jackson" }
There is no difference between the two, so it is personal preference. Though I would expect most people writing new code for 2.0 will use the second format.
It's important to note that if you are developing for open-source / public consumption and want a wide user base you should use the "old" style of hashes. Ruby 1.8.x, as well as JRuby and other ruby implementations apart from RMI, does not support the terse syntax.
There's no "should".
I prefer the 1.9 syntax unless there are symbols-as-values, then I think it looks silly.
This means I don't use them uniformly, it depends on what the hash values are–but I always use the same style in a single immediate hash.
The first one should be using if you are looking for backwards compatibility. But the second one is neater.
Use what you want. There is no sacred meaning in that. But it is highly recommended to use it uniformly.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
what tokens do you find useful in visual studio?
(visual studio 2010 → environment → task list → tokens)
currently i have only:
HACK - low
REVIEW - high
TODO - normal
WTF - high
(only these - deleted some default ones)
are you using any others?
are you covering any other important thing with comment tokens?
any best practices? thnx
Here's the ones I use:
TODO: the functionality is not yet implemented
FIXME: the code should be modified/refactored to achieve some goal (higher maintainability, better performance, and so on)
BUG: the code has a known bug
I've done a combination of most of the above tokens.
RED: code that simply does not work / compile
// Error - This code is throwing a specific reproducible error.
// Broken - This code is broken and will not run.
// WTF - WHAT THE FRIG.
ORANGE: code that works but is not right
// Hack - This code has intentionally been hacked in order to work. Should not go into production.
// FixMe - This code works but could be better. Needs better abstraction, maintainability, performance, etc.
// Bug - This code works and was expected to be right but a bug has been found. (usually flagged post production)
// Review - This code is probably right but should be reviewed for piece of mind.
// Smells - Same as FixMe
BLUE: code that works but either needs more features or more explaining
// Todo - Functionality is not yet implemented
// Note - Better explain what's going on. This is gives a higher profile to standard comments, and allows notes to be found in the to-do pane.
I like the Token REMOVE, indicating that it's only in for testing, and should not be included in the final release
Another built-in is NOTE.
Vim automatically highlights XXX, which happens to be my token of choice for the ease of typing it.
Sun's (old) Java coding conventions have this to say:
Use XXX in a comment to flag something that is bogus but works. Use FIXME to flag something that is bogus and broken.