I love using the Select/When/Otherwise statement in the data step, but my code always needs debugged before it will run properly. I never can remember the exact syntax required and SAS doesn't have very good documentation for it. (I actually can't find any mention of it except in the SCL documentation). Sometime it's because I put a semicolon after the When statements or forget that I need a Do block. Is this feature officially unsupported? If not then why isn't it documented?
Select/When/Otherwise documentaion
Related
I have a hard time formulating this question. The reason I'm asking is that I want to convert some C++ code with emscripten to java script code, but I don't think I need to convert the whole code base.
Is it possible in C++ to find all the code that a particular function could reach into when executed? Then I would know which part of the code I need to convert and which one I can just ignore.
It is called "call hierarchy" as Eugene said. You can use automatic documentation tools to get this information.
I strongly recommend you to try doxygen because it is really easy to use:
http://www.doxygen.nl/
According to the gcc docs on extended assembler:
You should only use read-write operands when the constraints for the operand [...] allow a register.
This seems to be to be pretty unambiguous: You cannot use +m for an output.
However, I've seen it being done a number of times. In fact, Linus Torvalds is on record as saying
The gcc docs are secondary. They're not updated, they aren't correct, they don't reflect reality, and they don't matter. The only correct thing to use is "+m" for things like this
I don't want to use +m if the compiler is going to end up screwing up my code. And even examining the output asm to see if it is working doesn't mean that tomorrow when I change some seemingly unrelated thing it will still work. Or that it will still work when I get the next update to gcc.
If the docs are right and I can't depend on this working correctly, I want to know that so I can pursue other options (most of which are unpleasantly painful). If the docs are wrong, please let me know how to get them corrected.
As it turns out, the problem is the docs (see the email). In case the link dies:
That part of the docs has been wrong for a while. The doc was corrected for 4.8, but it was wrong for earlier versions too.
Since I am using rubenvb's x64 compiler which reports version 4.7.2, that's the version of the docs I was reading. However, the actual code checkin was in 2004, so I'm feeling pretty confident that change is included in the code I'm running.
Please, don't cite what Linus had to say on gcc in 2001 (!), when the gcc/egcs rift was just starting to heal (that ended around 2000). Yes, the handling of asm restrictions was a horrendous mess in that timeframe (Alan Cox was sort of head of cleaning the mess up, as the compiler was starting to really heed the restrictions, I added a few patches to that).
The current GCC is a completely different beast, it has undergone extensive reengineering inside.
Believe the documentation, don't write bad constraints. They are constraints, if you lie to the compiler, it might by sheer bad luck select arguments that do work most of the time. It will break some day.
If you have an example that shows that writing an illegal constraint is accepted (that the compiler can check!), please report it.
If you have an example of a constraint that the compiler doesn't consider, please report it.
If you have code that does stuff that might (or not) work depending on options the compiler can legally take according to what ypu told it, and that sometimes works and sometimes it doesn't, OK, chalk it up to your own fault and wise up. Do not lie to your compiler, it will exact bloody revenge.
I am embarking on setting up my VIM with better autocompletion, mainly for classes. In my google research I came across omnicppcomplete and clang. I can't seem to figure out the advantage/disadvantage of the two. Does anyone know?
Also, is one easier to install on third party systems than the other?
Any feedback will help. Thanks!
Clang really 'understands' c++. That means it can tell the difference between a local variable named foo and a member function named foo. If you want to complete thisObject.fo..., it will not give you the fooContainer completion, but only the Object::fooMethod.
Also, Clang can handle all C-type languages, which ctags cannot.
Omnicppcomlete is based on ctags, which is merely a textual index of your source tree. So it will be denser, will most of the time do what you want; sometimes it will be less accurate. Which isn't a real problem.
I have not yet installed the Clang completion though :( You probably have to build clang yourself, while ctags most likely comes with your distribution.
I have a couple of simple C++ homeworks and I know the students shared code. These are smart students and they know how to cheat moss. I'm looking for a tool that can rename variables based on their types (first variable of type int will be int1, first int array will be intptr1...), or does something similar that I cannot think of now. Do you know a quick way to do this?
edit: I'm required to use moss and report 90% match
Thanks
Yep, the tool you're looking for is called a compiler. :)
Seriously, if the programs submitted are exactly the same except for the identifier names, compiling then (without debugging info) should result in exactly the same output.
If you do this with debugging turned on, the compiler may leave meta-data in the executable that is different for each executable, hence the comment about ensuring it is off. This is also why this wont work for Java programs - that kind of info is present whether in debug mode or not (for the purposes of dynamic introspection).
EDIT: I see from the comments added to the question that you're observing some submissions that are different in more than just identifier names. If the programs are still structurally equivalent, this should still work.
EDIT: Given that the use of moss is a requirement, this probably isn't the way to go. I does seem though that moss has some support for comparing assembly - perhaps compiling to assembler and submitting that to moss is an option (depending on what compiler you're using).
You can download and try our C CloneDR duplicate code detector. It finds duplicated code even when the variable names have been changed. Multiple changes in the same chunk are treated as just one; if they rename the varaibles consistenly everywhere, you'll get back a report of "one clone" with the precise variable subsitution.
You can try Copy Paste Detector with ignoreIdentifiers turned on. You can at least use it for a first pass before going to the effort of normalizing names for moss. Or, since the source is available, maybe you can get it to spit out its internal normalization of the code.
Another way of doing this would be to compile the applications and compare their binaries, so your examination is not limited to variable/function name changing.
An HEX editor can help you with that. I just tried ExamDiff (not free $) and I was happy with the result.
While working within C++ libraries, I've noticed that I am not granted any intellisense while inside directive blocks like "#ifndef CLIENT_DLL ... #endif". This is obviously due to the fact that "CLIENT_DLL" has been defined. I realize that I can work around this by simply commenting out the directives.
Are there any intellisense options that will enable intellisense regardless of directive evaluation?
By getting what you want, you would lose a lot.
Visual C++ IntelliSense is based on a couple major presumptions
1. that you want good/usable results.
2. that your current IntelliSense compiland will present information related to the "configuration" you are currently in.
Because your current configuration has that preprocessor directive, you will not be able to get results from the #ifndef region.
The reason makes sense if you think it through. What if the IntelliSense compiler just tried to compile the region you were in, regardless of #ifdef regions? You would get nonsense and non-compilable code. It would not be able to make heads or tails of your compiland.
I can imagine a very complex solution where it runs a smaller (new) parse on the region you are in, with only that region being assumed to be part of the compiland. However, there are so many holes in this approach (like nothing in that region being declared/defined) that this possible approach would immediately frustrate you, except in very very simple scenarios.
Generally it's best to avoid logic in #ifdef regions, and instead to delegate the usage of parameterized compilation to entire functions, so that the front-end of the compiler is always compiling those modules, but the linker/optimizer will select the correct OBJ later on.
Hope that helps,
Will
Visual Studio 6.0 has a little better support for C++ in some arena's such as this. If you need the intellisense then just comment it out temporarily, build and then you should have intellisense. Just remember to recomment it when you're through if that was your intent.
I just wish Intellisense would work when it SHOULD in VS2008. MS "workarounds" don't work (deleting .ncb files) most of the time. Oooh,
here's another SO discussion..., let's see what IT has to say (I just love SO)
I'm often annoyed by that too ... but I wonder whether intellisense would actually be able to provide any useful information, in general, within a conditioned-out block?
The problem I see is that if the use of a variable or function changes depending on the value of a preprocessor directive then so may it's definition. If code-browsing features like "go to definition" were active within a conditioned-out block would you want them to lead to the currently-enabled definition or to one that was disabled by the same preprocessor conditions as the disabled code you're looking at?
I think the "princple of least surprise" dictates that the current behaviour is the safest, annoying though it is.
Why you want to do explicitly in the code?
There is already cofiguration setting in VS and the way you can enable and disble the intellisense.
see the link.
http://msdn.microsoft.com/en-us/library/ms173379(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ks1ka3t6(v=VS.80).aspx
This link may help you.