C++, multi-threading and queues

Discussion in 'Computer Science & Culture' started by AlphaNumeric, Oct 27, 2012.

Thread Status:
Not open for further replies.
  1. Crunchy Cat F-in' *meow* baby!!! Valued Senior Member

    Messages:
    8,423
    I am assuming that is sarcasm but in case it's not, you can brush up on it here:

    http://www.theregister.co.uk/2009/05/15/microsoft_banishes_memcpy/

    That is correct.

    I don't find it insane in the least to have explicit control over a program.

    It's hard to read, doesn't provide any performance gain, is harder to maintain, has a negative len value bug, and has an increment inefficienty on some compilers. I would not classify it as better.

    Your statement is incorrect. First and foremost, the code is not managed code; therefore, it does not expose managed memory. Second, even in the context of unmanaged code, it's not exposing any internal object to the outside world; thus, encapsulation is not broken.

    Yet, you cannot find any C++ compiler that doesn't also work on C code at the same time. I would consider thinking about why that might be.

    You don't/do *need* anything is a subjective opinion.

    I am not sure what you were referring to by the "In this case either..." section; however, your assertion about executing a non-standard function on a container in a way which has undefined behavior is incorrect. memcpy() is very much a standard function. Accessing a vector's memory in a contiguous fashion is also correct because "A vector's storage is guaranteed to be contiguous. From ISO 14882, 2nd ed., 23.2.4 [lib.vector]:".

    Again, just reiterating... it's unmanaged code (not managed). The answer to all your questions is obviously yes.
     
  2. Google AdSense Guest Advertisement



    to hide all adverts.
  3. Chipz Banned Banned

    Messages:
    838
    Fine, continue to live in the world of Windows mediocrity. You either don't understand my points or you don't care, in either case just hope you never work for me

    Please Register or Log in to view the hidden image!

    .
     
  4. Google AdSense Guest Advertisement



    to hide all adverts.
  5. Crunchy Cat F-in' *meow* baby!!! Valued Senior Member

    Messages:
    8,423
    Nothing you have argued is Windows specific, but I am not sure that you actually understood the points that you were trying to make. I responded and that's all I can do and no amount trying a last ditch effort to position yourself as an authority will actually make you correct.
     
  6. Google AdSense Guest Advertisement



    to hide all adverts.
  7. Chipz Banned Banned

    Messages:
    838
    Okay -- I'll give you one last reponse, and also embolden all of the windows specific content you wrote.


    Your definition of "unsafe" is wrong and is tainted by Windows terminology.

    Believe it or not; pointer dereferencing is significantly faster than subscripting -- this implementation will perform faster than a standard for loop. Compilers do not distinguish between i++ or ++i in for loops and haven't for 15 years.
    Your other points are valid; it's harder to maintain and has a negative len value bug... that's my whole point.

    A std::vector acts to manage an internal memory segment and performs (what used to be) the arduous task of reallocation of blocks on expansion. This memory is all heap-allocated and is freed at the d-tor. How is a C++ vector not managed C? Isn't that one of the biggest reasons it was created in the first place?

    Second, yes, it is exposing an interal object to the outside world.

    Code:
    #include <string.h>
    
    void *memcpy(void *dest, const void *src, size_t n);
    
    RETURN VALUE
           The memcpy() function returns a pointer to dest.
    
    Try doing a delete[] on the return value of your memcpy and watch the vector crash on the destruction of the object. This is because you're doing a bitwise copy to the internal data pointer which is managed by the C++ container.

    So what? That doesn't mean they are the same language, if you believe this ... you don't know at least one of the two languages well (and I am assuming it's C).

    Again, so what? It doesn't matter if the memory segment is contiguous. What matters is you're modifying an internal state in an undefined way. The correct way exists -- (say the constructor accepting to memory addresses). This will modify necessary private state variables accordingly. Do you know there will never be in the future state variables affected by direct access to encapsulated memory?

    You're brainwashed imo.
     
  8. Crunchy Cat F-in' *meow* baby!!! Valued Senior Member

    Messages:
    8,423
    I don't think I have issued a formal definition; however, please do show me the correct definition regardless.

    That might be true; however, it is out of scope. AlphaNumeric's issue specifically dealt with doubles and vectors. The memcpy() solution is faster than any for-loop() that you can make. The reason is that memcpy() uses human-optimized native instructions and larger block moves.

    Except for many firmware compilers that don't auto-optimize (and last I checked people are using those today).

    OK?

    I agree with that interpretation.

    "Managed <insert language>" has a very specific meaning that you even correctly stated earlier on:

    The industry agrees with your original terms as well:

    http://msdn.microsoft.com/en-us/library/0adb9zxe(v=vs.80).aspx
    http://missingmanuals.com/pub/a/dotnet/2003/01/13/intromcpp.html

    By suddenly changing the meaning of "managed" you are introducing the same term for a different concept without any kind of hard context switch. It's a trick to navigate a debate; thus, enabling you to claim a "cat" is really a "dog" or a "cat" is really a "cat". It is; however, not a good strategy to utilize by those whom can easily see it.

    Possibly. I can't find any motive history on it; however, I do see that it's most often used with TCP communication where the vector is pre-sized for messages and its contents are directly read or written to via memcpy().

    How? The Converter class operates on references. No pointers (let alone to anything internal) are returned.

    I am not sure what point you are trying to make. Why would you ever delete[] the vector's buffer when you never new[]-d it to begin with?

    I do think the point was missed. I'll expand. Using the assertion that C++ and C are different languages (which is as obvious asserting the sky is blue) in a debate only has one purpose... to argue that programs should never use both at the same time. ALL C++ compilers (no exception) work with C code at the same time. The reason for this is so you *can* use both languages (and their pre-made APIs) at the same time.

    Of course it matters if it's contiguous or not. If it wasn't, you could never have reliable direct access. A Vector consequently doesn't have state variables linked to the contents of its buffer because it is not an observer class. Not just that, it is designed to provide direct buffer access (one of the reasons why its buffer is made of contiguous memory). Humans cannot forsee the future; therefore, your question about it is is a bit moot. What I can tell you is that an ISO vector-like class that observes its own buffer's contents is something that is not a vector.

    More importantly, you haven't provided any evidence showing that the memcpy() in the Converter class is bad, and yet there it is... an implementation example for AlphaNumeric that works just fine and uses by-design features. Mind you, I am open to changing my mind with a reasonable evidence-based argument.
     
    Last edited: Nov 17, 2012
  9. funkstar ratsknuf Valued Senior Member

    Messages:
    1,390
    Off-topic, but I can't help but smirk every time I read "std::vector".
     
  10. Crunchy Cat F-in' *meow* baby!!! Valued Senior Member

    Messages:
    8,423
    It's just another joke in a long line of intentional technology jokes.

    STD from std::vector
    depends.exe from Microsoft Dependency Viewer
    .ptl files from Rational Rose (jokiningly pronounced pedo-files)
    ...

    and the list goes on.
     
  11. LaurieAG Registered Senior Member

    Messages:
    586
    Have any of you heard of the event loop as I have not noticed anything in the code snippets?

    I studied OOP at uni using C++ DOS before Win 3.11 was available so we just created our own classes and objects.

    The basic assignment was a ping pong game and some students went the whole hog and turned this into a shootem up version of asteroids.

    The main program was just a very simple loop which incremented a counter and interracted with the object.
     
  12. funkstar ratsknuf Valued Senior Member

    Messages:
    1,390
    Well, it wasn't the STD part in itself, it's the combination with "vector" (which is also used in medicine) that makes it funny.
     
  13. Crunchy Cat F-in' *meow* baby!!! Valued Senior Member

    Messages:
    8,423
  14. LaurieAG Registered Senior Member

    Messages:
    586
    If your main event loop is clogged up with code you will have no option but to do it the hard way.

    If you have a clean event loop this can be used to sequence your multi thread calls (and handling) so that the threads are triggered contiguously at that optimum external point instead of within the object classes (and after all of the code that has to be run to get to the multi thread call).
     
  15. Crunchy Cat F-in' *meow* baby!!! Valued Senior Member

    Messages:
    8,423
    I hate to say it Laurie, but I am not quite sure what you are talking about. Event loops are most often implementations that listen for events in a queue and then dipatch them to a router. The router in turn then analyzes the event and invokes a handler to do something with it. It often looks something like this:

    while (GetNextEvent(evt))
    {
    RouteEvent(evt);
    }

    In this context, GetNextEvent() would simply put the processor into an efficient wait state until a new event becomes available and then it would return true with the event all ready to be routed. Quite often there would be some kind of keepAlive flag that could be set that would cause GetMessage() to immediately return with a false; thus, breaking out of the loop. Given your video game example, I think that you may be talking about a game loop. It is a similar concept but has a specific application for games. It would typically look like this:

    while (keepGameAlive)
    {
    // Handle input events
    // Process game logic.
    // Render the screen.
    }
     
Thread Status:
Not open for further replies.

Share This Page