multi-file weekend coding: c++is worst lang

In my weekend assignments, tcost of BP is higher for c++  than other languages.

In any language, function names must match across the files. Ditto for type names and variable names.

Java additionally requires consistency between supertype^subtype, across files. I often rely on Eclipse for that.

C++ adds one more major headache — header files.My C++ coding uses vi or notepad++.

  • more #includes are needed when I extract a header file
  • in header files, I can’ t “use namespace ..”, so I must manually add the namespace prefixes on many names
  • function declaration^definition much match across header file vs implementation files

In a weekend coding assignment, I need to avoid multiple-file coding.

Just keep everything in one file. Tidy up in the end and adhere to Best Practices.

 

 

prefer std::deque when you need stack/queue

  • std::stack is unnecessarily troublesome for dumping and troubleshooting … see https://github.com/tiger40490/repo1/blob/cpp1/cpp/2d/maxRectangle.cpp
  • std::queue has a similar restriction.
  • std::dequeue let’s you peek at any element
  • std::dequeue even supports insert/delete mid-stream , albeit inefficiently. This feature can be used in some coding tests but if interviewer examines your code she would frown on it.

Philosophically, std::stack and std::queue are container adapters designed to deny random access, often for safety. They are often based on an underlying “crippled deque”. As soon as you need to dump the container content, you want a full-fledged deque.

## G20 operations(4cod`IV)on containers+str

“Operation” means logical operations any programmer (java, Perl, javascript, whatever) frequently performs on a common data structure. STL offers about 30 to 60 everyday operations. A beginner can benefit from a good short list.

List below leans towards sequential containers (shows up in 80% coding questions), but also includes essential operations on associative containers.

  1. ) print — using copy and ostream_iterator. See post. See stl-tut
  2. ) find, find_all
  3. slicing i.e. subsequence
  4. [iv] sort — using custom “myLess” as a type param. See post on functor-type. See effSTL
  5. [iv] construct a sorted container using customer “myLess” as type param. See blog
  6. filter
  7. [iv] nested container
  8. truncate at a point
  9. append, in bulk
  10. pop front
  11. binary search in pre-sorted
  12. [iv] deep copy
  13. mass-populate with one default value
  14. remove/erase – see effSTLplug back_inserter into copy, remove_copy, replace_copy …
  15. [iv] plug bind2nd into replace_if/replace_copy_if, count_if, remove_if/remove_copy_if …. See blog
  16. initialize with hardcoded literals — relatively easy
  17. conversion like between string and vector of char. See blog. See [[ stl tut ]]
  18. —-2nd tier
  19. insert mid-stream, in bulk
  20. [iv] = possibly picked by interviewers

##9dataStruct(+..)for c++speed cod`

  1. linked node manipulation in a graph context
  2. vector (more useful than array), std::string (more useful than cStr). Many string operations are still unfamiliar
    1. Array-based data structures are required in 80% of my coding tests.
    2. More than 50% of all my coding tests require nothing but arrays.
    3. Most of my toughest coding tests are presented in arrays but may need maps as helpers
  3. string in std::string or c-str
  4. iterator manipulation like erase, lower_bound, find,
  5. sorting, operator<(), upper_bound, binary search … on containers
  6. sorted data structure like std::map
  7. [w] stringstream — ECT to improve

Very few Wall St interviewers would test you on graph or DP. Here are other less important constructs:

  1. [w] binary tree is common and simple, but they can ask very tough questions on it!
  2. [w] double pointer is trickier and my advantage
  3. [w] Node class in a linked data structure.
  4. [w] stack, queue.
  5. [w] grid or matrix
  6. file I/O? only for IDE tests, not pure algo or take-home tests
  7. [w] basic syntax for pointer arithmetic.
  8. [w] dtor, copier, op=? only for design questions, not algo questions.
  9. [w] shared_ptr? Only for design questions, never needed in algo questions!
  10. [w] ref variable only as function I/O.
  11. stl algo? Only Citadel array-shrink
  12. never exception
  13. never template
  14. no (very, very seldom) threading in coding Q
  15. adv: pointer to function
  16. adv: circular buffer
  17. [w = no weakness]

 

c++cod`IV: no threading/boost/template/socket..

See C++(n java) high-end IV tend2beat us]4ways

This post is about the c++ topics. The BP/ECT/algo fronts primarily use basic constructs in ##10 basic program`constructs for c++ cod`IV

QQ BP ECT algo#pure
heavy no never never thread
heavy yes seldom never smart ptr
seldom never never never other boost
yes never never never rvr+move
seldom optional never other c++11
heavy seldom never never memory tricks
yes never never never templates meta..
heavy yes never never c^c++
heavy never never never sockets
never never never once object graph serialization
heavy never never never inline
heavy never never never cpu cache
yes never never never exception safety
yes never never never pimpl

tips for bbg cod`IV

  • chrome (not Opera) supports Alt-R
  • Show 67 lines of source code
    • chrome F11 to toggle full screen
    • chrome can zoom out 75% to show 67 lines in editor, if you can’t find a bigger monitor.
    • use hackerrank top right icon -> settings -> SMALL font
    • put multiple lines in one line as much as possible
    • Can we hide the address bar?
  • hackerrank top right icon -> settings -> light (not dark) scheme shows line highlight better, but dark shows text better.
  • add comments to show your thinking

Here’s some code we can copy-paste:

#include 
#include 
#define ss if(1>0)cout
using namespace std;   int i1, i2, i3, N;   string s, s1, s2, s3;
int main(){
    ss<<"s = "<<s<<endl;
}