4 ms·

If you said what language you're working in, it might be easier for me to understand why you wouldn't use inheritance.

• Gupie 11y ago
  An example that superficially looks like "cut and paste" programming occurs is actually implementing a new derived class. In the C++ case, you could: 1. Type out the new .h and cpp files from scratch. 2. Copy/rename the base class .h file, remove all non virtual functions and other text not needed for a derived class, copy/rename this new header creating a .cpp file, convert method declarations to definitions, and add method implementations. 3. Copy/renamed the .h and .cpp files for an existing derived class and replace the existing method implementations. Option 3 is a reasonable choice and is an example of what article article discusses.
  • scott_s 11y ago
    Option 3 is a reasonable choice, but I don't think it's an example of what the article discusses. The example you provided is a good one, because it's an instance where you can't write abstractions to help you in the language you're using. Defining new classes, their interfaces and members is part of the necessary scaffolding when writing in C++. (Let's pretend it's not possible to do this with the C preprocessor.) But the first example in the article does not sound like your example. Rather, it sounds closer to im3w1l's example, where the programmer copied code for some particular functionality, not for scaffolding.
    • Gupie 11y ago
      I don't see im3w1l's example as copying code for some particular functionality, it's copying boilerplate code needed to use a particular library. First the library is initialised, passing in a number of parameters to an initialisation function. If the values of these parameters are the same in multiple instances in the same codebase then that is violating DRY, but if the parameters differ it's just the scaffolding that you are reusing.
      • scott_s 11y ago
        The difference, to me, is that it's scaffolding code that can be abstracted. You can't abstract writing a class - it's a primary activity in the language. Only macros can help you there - either the broken ones provided by the C preprocessor, or real ones provided by languages like Racket or Rust. But boilerplate code that interacts with an external library is not a primary activity in the language. You can hide it behind a class or a family of functions.
• im3w1l 11y ago
  Well consider the following c code. Demonstrates how to allocate memory on gpu, transfer data in and out, how to operate on the memory, and how to then free it. I could see myself copy pasting that to several places, but modified to perform different functions. http://docs.nvidia.com/cuda/cublas/#example-code http://docs.nvidia.com/cuda/cublas/#example-code edit: I guess if you write C++, you could protect the resources with RAII, and shave two lines of copy-pasted de-initialization.
  • scott_s 11y ago
    It can be quite a bit more than just two lines, particularly considering error handling. But when you start refactoring common patterns, you can often end up with higher level abstractions. In your example, Thrust is exactly that: https://developer.nvidia.com/Thrust https://developer.nvidia.com/Thrust
    • im3w1l 11y ago
      I'll proceed as if that was implemented on top of cuda, I have no idea if that is actually the case, but for the sake of argument. That code does not initialize the library, instead the handle is stored as a global variable that is lazily initialized when using thrust methods. This makes it easier to use but has some drawbacks too. It can not use more than one card at once. It means every call will check if library is initialized safer but slower. Resources are not freed as soon as possible. A good trade off in the majority of cases. A device vector is created and assigned a value in one call. Size is automatically tracked. Nice. Errors are not handled. All code looks cleaner if you don't handle errors.