Parser written in PHP is 5.6x faster than the same C++ program in a similar test (g++ 4.8.5)
Always Profile Optimized Code.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rper-measure

Use -O3 optimisation: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Use a profiler: https://github.com/KDAB/hotspot

https://en.wikipedia.org/wiki/List_of_performance_analysis_tools


Reduce the duplication
string inPath = argv[1];
string outPath = argv[2];

std::ifstream inFile;
std::ofstream outFile;

inFile.open(inPath.c_str());
outFile.open(outPath.c_str());

to
std::ifstream inFile(argv[1]);
std::ofstream outFile(argv[2]);


Avoid string operations and allocations as much as possible. Prefer std::string_view if the string is only being read.

Remove string makeCSVLine(vector&lt;string&gt; splitLine) and use a formatter library like {fmt} https://github.com/fmtlib/fmt. Just to make the code prettier in
  outFile &lt;&lt; makeCSVLine(split);

, you're paying with a significant time penalty. OR use the good old (discussed below) fprintf if that turns out to be faster. If there is not a significant time gain, follow the guidelines and use fmt + streams.
 fmt::print(&lt;FILE*&gt;,
           &quot;{},{},{},{},{},{},{},{},{},{},{}\n&quot;,
           vec[0],
           vec[1],
           vec[3],
           vec[4],
           vec[5],
           vec[6],
           vec[10],
           vec[9],
           vec[11],
           vec[7],
           vec[32]);

Make it a macro or a lambda, or a function with inline attribute set if you want to use it with other answers but in a separate block of code.
See speed tests by fmt also. source file

vector&lt;string&gt; splitStr(string line, const char delimiter = ',')
Avoid returning the vector and pass it by reference to fill it inside the function ( return type will be void). This makes it Return Value Optimisation independent. All compilers will treat it the same way.
Also, consider using .reserve(), and/or .emplace_back() for the vector. reserve() has been tested to improve performance.

Use stringstream + getline with a delimiter. If you doubt that this is time costly, profile. Don't guess the performance results, measure them.
void split_by_delim(const string &amp;string, char delim, vector&lt;string&gt; &amp;r_out)
{
  std::stringstream ss(string);
  string word{};   // reserve space if you can guess it right.
  while (std::getline(ss, word, delim)) {
    if (!word.empty()) {
       r_out.push_back(word);
    }
  }
}


Avoid fstreams iff the reader or writer are the biggest time sinks. fprintf has been 40% faster in my tests with no loss in flexibility (I used it for writing ints and floats, it may vary(edit: yes it varied and the gain is insignificant compared to the other benefits of streams (or with fmt) ) with strings.).
Re comments that Stream IO is as fast as printf family IO, take it from Herb Sutter &amp; Bjarne Stroustrup:

It is often (and often correctly) pointed out that the printf() family has two advantages compared to iostreams: flexibility of formatting and performance. This has to be weighed against iostreams advantages of extensibility to handle user-defined types, resilient against security violations, implicit memory management, and locale handling.
If you need I/O performance, you can almost always do better than printf().

Emphasis mine.

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rio-streams


In the current code, the reading speed (getline()) is bound by splitting the string and the write speed. In other words, more lines cannot be read as long as file writer has not done its job. You're not using the disk's read speed to the full potential here.
Consider splitting them such that all reading is done at once and data is stored in memory and it is written out at once.
If you want to keep peak memory usage to minimum, make use of threads and separate the reader and the (splitter + writer) in asynchronous threads.


Addendum
Machine: MacBook Air 2017, macOS Mojave, MQD32LL https://en.wikipedia.org/wiki/MacBook_Air#Technical_specifications_2
Profiler: Instruments.app.
Compiler: Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Flags: -Ofast (and linking with {fmt} where required.)
PHP: 7.1.23 (cli) (built: Feb 22 2019 22:19:32) ( NTS )

Writer code to make CSV file, derived from Edward's answer for consistency: https://ideone.com/gkmUUN
Note that close enough timings should be considered the same due to fluctuations which can affect 3 to 5 seconds by a lot.
Matthew's code with the knowledge of line length and word length: 2.6s
Matthew's code as of rev 1 : 2.7s
Edward's algorithm with char array storage &amp; {fmt}: https://ideone.com/Kfkp90. This depends on the knowledge that the incoming CSV has a maximum line length of 300 characters and a maximum word length of 20 characters. 2.8s.
Martin's code as of rev 7: 2.8s
For less bug-prone code, and dealing with unknown length strings: https://ideone.com/siFp3A. This is Edward's algorithm which uses {fmt}. 4.1s.
gdate +%s.%3N &amp;&amp; php parser.php &amp;&amp; gdate +%s.%3N where parser.php is in Edward's code as of rev 5 : 4.4s
Edward's code as of rev 1: 4.75s
Edward's code with fprintf https://ideone.com/0Lmr5P : 4.8
OP's code with basic optimisations, and fprintf https://ideone.com/5ivw9R : 5.6s
OP's C++ code posted in the question: 6.2s
OP's C++ code with -O2: 6.4s
OP's C++ code with -O0: 45s