4 ms·

Can you give concrete example what you are referring to? From a quick skim, I would say that's quite clean, straightforward algorithmic code -- while it could b

Can you give concrete example what you are referring to? From a quick skim, I would say that's quite clean, straightforward algorithmic code -- while it could be improved a tiny little bit by sprinkling in a little C++11 syntax (don't overdo it). (For context, I'm mainly a C / Python / Unix Programmer, with an interest in common sense and architectures based on clean plain data interfaces instead of wrong abstractions, and with a good track on SPOJ)

svalorzen 11y ago
Just random things that pop up: - using namespace std; - variable names inconsistent and random, using uppercase and lowercase randomly (code also would not compile since it is cased randomly) - indenting and braces inconsistent - use of macros for trivial tasks where they are absolutely not required - use of macros in totally dangerous ways ("#define all(c) c.begin(), c.end()", seriously?) - usage of compiler dependent features - code should be for "competitive programming", and proposes a vector of vectors to make a 2D matrix - Counterproductive and unhelpful typedefs EDIT: I'd like to tell you more, but looking at that page is making me feel unwell. The ostringstream example seems to be out of a nightmare. Just learn C++ from a reputable source and save yourself and everybody else around you the pain.
- jzwinck 11y ago
  You're right that some of those items are bad practices in normal development. But some of them would actually help a person bang together crappy but working code more quickly for a one-off task. Perhaps we should read "competitive programming" as "programming quickly without regard for quality." Taken that way, the article could even be titled "programming to impress nontechnical managers so you can become one."
- Nimitz14 11y ago
  > proposes a vector of vectors to make a 2D matrix what would be the right way to do this?
  - Stasis5001 11y ago
    2D arrays that are laid out as a linear array of mn elements are faster to iterate through. That's what happens when you declare e.g. int a[5][4], you get the same layout as int a[20]. A vector of vectors is fairly sprawling in memory, and generally matrices don't get resized so you want this compact form because it's quicker to loop through (either way is O(mn), but one has a way better coefficient).
- radicality 11y ago
  Did you read that this is for _competitive programming_?. I know you did as you mention it, but then some of your points don't make sense. In topcoder every second counts, and if using `all(c)` instead of writing up `c.begin(), c.end()` can save you two seconds, you should do it. Also your code can be 'challenged' by someone else (they give an example where your code fails), and making obscure typedefs and macros that will make it ever so slightly harder for someone to decipher what you are going is allright.
- rjtobin 11y ago
  For programming contests, often saving keypresses is more valuable than good style or practice. Agreed that no one should cut these corners when writing code that will be used again tomorrow, but when you're trying to hammer out something in under 10 minutes (or whatever), there are lots of bad practice tricks that become very useful (like macros that would be awful in any other context). Before people lynch me, I just wants emphasize again that I'm not defending these practices in production code, but the article wasn't advocating that either. And of course there's the old debate about whether the contests themselves become harmful because they encourage bad practice, and that may be true, but that's a different conversation.
Devid2014 11y ago
Is this enough ? typedef vector<int> vi; typedef vector<vi> vvi; typedef pair<int,int> ii; #define sz(a) int((a).size()) #define pb push_back #defile all(c) (c).begin(),(c).end() #define tr(c,i) for(typeof((c).begin() i = (c).begin(); i != (c).end(); i++) #define present(c,x) ((c).find(x) != (c).end()) #define cpresent(c,x) (find(all(c),x) != (c).end())
- jonathankoren 11y ago
  That's just bad C code, and is exactly the type of stuff I'd expect on topcoder, which seems to attract the types that write incomprehensible code... but hey man, it's fast! Just write C. C++ is too much of a pain.

svalorzen 11y ago

Just random things that pop up: - using namespace std; - variable names inconsistent and random, using uppercase and lowercase randomly (code also would not compile since it is cased randomly) - indenting and braces inconsistent - use of macros for trivial tasks where they are absolutely not required - use of macros in totally dangerous ways ("#define all(c) c.begin(), c.end()", seriously?) - usage of compiler dependent features - code should be for "competitive programming", and proposes a vector of vectors to make a 2D matrix - Counterproductive and unhelpful typedefs EDIT: I'd like to tell you more, but looking at that page is making me feel unwell. The ostringstream example seems to be out of a nightmare. Just learn C++ from a reputable source and save yourself and everybody else around you the pain.

jzwinck 11y ago
You're right that some of those items are bad practices in normal development. But some of them would actually help a person bang together crappy but working code more quickly for a one-off task. Perhaps we should read "competitive programming" as "programming quickly without regard for quality." Taken that way, the article could even be titled "programming to impress nontechnical managers so you can become one."
Nimitz14 11y ago
> proposes a vector of vectors to make a 2D matrix what would be the right way to do this?
- Stasis5001 11y ago
  2D arrays that are laid out as a linear array of mn elements are faster to iterate through. That's what happens when you declare e.g. int a[5][4], you get the same layout as int a[20]. A vector of vectors is fairly sprawling in memory, and generally matrices don't get resized so you want this compact form because it's quicker to loop through (either way is O(mn), but one has a way better coefficient).
radicality 11y ago
Did you read that this is for _competitive programming_?. I know you did as you mention it, but then some of your points don't make sense. In topcoder every second counts, and if using `all(c)` instead of writing up `c.begin(), c.end()` can save you two seconds, you should do it. Also your code can be 'challenged' by someone else (they give an example where your code fails), and making obscure typedefs and macros that will make it ever so slightly harder for someone to decipher what you are going is allright.
rjtobin 11y ago
For programming contests, often saving keypresses is more valuable than good style or practice. Agreed that no one should cut these corners when writing code that will be used again tomorrow, but when you're trying to hammer out something in under 10 minutes (or whatever), there are lots of bad practice tricks that become very useful (like macros that would be awful in any other context). Before people lynch me, I just wants emphasize again that I'm not defending these practices in production code, but the article wasn't advocating that either. And of course there's the old debate about whether the contests themselves become harmful because they encourage bad practice, and that may be true, but that's a different conversation.

Devid2014 11y ago

Is this enough ? typedef vector<int> vi; typedef vector<vi> vvi; typedef pair<int,int> ii; #define sz(a) int((a).size()) #define pb push_back #defile all(c) (c).begin(),(c).end() #define tr(c,i) for(typeof((c).begin() i = (c).begin(); i != (c).end(); i++) #define present(c,x) ((c).find(x) != (c).end()) #define cpresent(c,x) (find(all(c),x) != (c).end())

jonathankoren 11y ago
That's just bad C code, and is exactly the type of stuff I'd expect on topcoder, which seems to attract the types that write incomprehensible code... but hey man, it's fast! Just write C. C++ is too much of a pain.