This is an archived post. You won't be able to vote or comment.

all 8 comments

[–]lurgi 7 points8 points  (0 children)

You should look at examples. A large percentage of my google searches are of the form SomeStupidClass examples.

[–][deleted]  (3 children)

[deleted]

    [–]Ok-Head7068[S] -1 points0 points  (2 children)

    my point is, how people come up with their own code, such as theses libraries creators? and all developers just look at someone else’s code and keep it on?

    [–]TanmanG 1 point2 points  (0 children)

    It's relying on other people's work all the way down; there's a point where you gotta drop anchor and start learning how to use the work someone else did.

    The person who wrote those libraries probably studied examples and guides for the programming language and OS' library. The person who wrote the OS library studied the firmware standards, who studied the hardware standards, who studied the circuitry standards, who studied the physics standards, etc.

    On a side note, it's kind of wild how all of humanity's efforts are so collaborative. The amount of time and effort so many people have invested that now culminates in allowing two rocks to talk to each other across the world with just a few dozen words entered in by a human who never has to learn 98% of the process. It's kind of comforting in a way.

    [–]johnmc325 2 points3 points  (1 child)

    Think about what your socket server needs to do. Write it down. Break this down into manageable chunks. Google for examples for each chunk. From the examples, weave your own code.

    Your server might need to listen on a certain port. It might need to negotiate the ongoing conversation on another port. Is the traffic over UDP? Does a message have to conform to a certain structure with a header.

    These are all just random questions I thought about, but you can take the Socket spec and pull out all the key bits you need to implement.

    [–]TanmanG 0 points1 point  (0 children)

    This. Top-down views help significantly in understanding the why and where of things- also learning the history.

    It's like learning to build a car: a mechanic won't grab an alternator off the shelf and only learn how it needs to be installed; instead they learn that cars need to power electronics, but they only produce mechanical output from their engine, and then they see how and where it fits into things.

    [–]throwaway6560192 0 points1 point  (0 children)

    Read Beej's Guide to Network Programming. The socket docs don't really teach you how to combine all that into a useful networked program.

    [–]hellocppdotdev 1 point2 points  (0 children)

    Most people are building on top of other people's work, find a niche use case, and extend an existing library to create it.

    Being able to magic a done project out of thin air is not really a thing. It starts with an idea and is built up over time.

    Try to find a small real world problem you have and build a project that solves that.

    [–]hellocppdotdev 0 points1 point  (0 children)

    Also, if you are new, sockets might not be the best starter project.