Reading a line of text from a socket
I don't see anything in this code that needs to be commented. To echo what other people said, comments should clarify code and they should never say what the code already says.

I would recommend commenting code under these conditions:


You can't tell what the code is doing by reading it
You encountered a wonky bug that took you a long time to figure out, and the fix does not look clear or uses a programming construct or pattern that isn't normally used.


Really, the biggest problem I see is one of the biggest problems in Software Engineering. As Martin Fowler once said:


  ... there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.


The names of your variables and methods could use a little polishing.

For instance, does Socket::recvln() mean:


Receive Line
Receive Lane
Recover Line...


Even if names become a little long, make them obvious. Don't abbreviate. Some people say that abbreviating well known terms within your industry are OK. I'm from the camp that disagrees. Never assume that the next programmer is an expert in your industry.

When it comes to "reducing lines" I have mixed feelings about omitting optional curly brackets. It looks nicer, but becomes extra typing when you have to add one line of code. I go back and forth on that and have come to a compromise with myself.


If omitting the curly brackets makes the code a two-liner, that's OK

if (count &gt;= size)
    count = 0;

If I would be omitting curly brackets for nested structures, I'll put the curly brackets in even if I don't need to

for (count = 0; count &lt; size; count++)
{
    if (recvBuffer.at(count) == '\n')
    {
        break;
    }
    else
    {
        result[count] = recvBuffer.at(count);
    }
}

But sometimes within a nested structure, I'll omit the optional brackets if it is obvious:

for (count = 0; count &lt; size; count++)
{
    if (recvBuffer.at(count) == '\n')
        break;
    else
        result[count] = recvBuffer.at(count);
}

If I have a structure with one-liners and multi liners, I never omit the curly brackets:

if (count &gt; size)
{
    count = 0;
}
else
{
    foo = count + 10;
    bar = foo * -1;
}



Lastly, I recommend putting spaces around operators to make the code easier to read:

recvBuffer.erase(recvBuffer.begin(), recvBuffer.begin() + count);


(notice the spaces around the "+" sign)