Jump to content
  • Advertisement

Bregma

GDNet+
  • Content Count

    3132
  • Joined

  • Last visited

  • Days Won

    6

Bregma last won the day on November 16

Bregma had the most liked content!

Community Reputation

9423 Excellent

1 Follower

About Bregma

  • Rank
    Curmudgeon

Social

  • Github
    bregma
  • Twitch
    bregmatter
  • Steam
    bregma

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That is a fine, fine English word. Nicely played. One of the reasons why singletons are something to avoid is because they introduce the latent hazard of non-deterministic destruction order. That's not a problem for languages with non-deterministic destruction (for example, Java and Python), but it is fraught with peril for a language that requires deterministic destruction. This is the problem you encountered. You have had your epiphany and you are now saved. The good thing is we learn 100 times as much from one mistake as from 100 successes. I bet you'll never use a singleton in new code again.
  2. An index is a difference between the start of a sequence and a particular element within a sequence. That's not a size, it's a difference. If you have a sequence container it can be perfectly reasonable to index backwards from the end -- a negative value by conventional algebraic definitions. It's not reasonable to have a size of less than zero, but consider the popular construct for(auto i = my_array.size()+1; i-->0;) { ... }. If you need to use a standard integral type to represent an index, std::ptrdiff_t is the better choice. Perhaps it wasn't what Alexander Stepanov chose for his STL back in 1995, but its what the ISO-standard language provides for its built-in container type.
  3. Yes. std::size_t is always the appropriate type to express sizes. An index is not a size, it's a difference. It should be expressed as a signed integer. If you need a specifically-sized integer value, use a specifically-sized integer value. You rarely need such a thing, except for marshalling/unmarshalling data (which can include file I/O, network I/O, and communications with a coprocessor through an API).
  4. Bregma

    C++ how to calculate sine and cosine in c++ without STL

    Why bother with the union for i and f?
  5. The answer really depends on the operating system you're using, if any. If you're not using an operating system, it depends on the hardware you're using. At a basic level, input is handled by reading from a memory location, device file, or message events from an input server. You might have to poll the input, or receive input asynchronously. Output is, as you say, rendering 2-D colours to a memory region and taking the appropriate action to have that memory region displayed on an output device (you might be writing directly to screen memory, or you might have to submit the particulars of your memory area, like address and size, to another memory area, device file, or buffer stream going to a display server. You may have to instruct the output to swap buffers. You will need to handle timesteps to synchronize input, output, and in-game processing. If you want to know how SDL doe these jobs, read the SDL code. It's all open source. If you want to do your own input and output, read the SDL code to learn how they do it to get an understanding of how input and output work on a number of operating systems. It turns out there isn't a small simple answer to your question. No one can point to a function in the C standard library for getting input and rending in the DOM. C is not JavaScript or a full-stack web development kit.
  6. Without seeing code, my guess is that you include unnecessary headers, or else you're using a lot of 'header only' libraries. You can reduce the number of unnecessary headers by only including those you need, and by using forward declarations (which, for compile safety, can be placed in smaller simpler headers) and making sure you use include guards properly. Header only libraries make distribution of the library easier, but the cost is increased compilation times. My next guess is that you're using template-heavy code. It's going to increase compilation times. Header only libraries and template-heavy code go hand-in-hand, and both are compile-time performance killers. Sometimes you jut need to go back to the olden days. When I was young, compilation could take hours between when you submitted the job at the card reader and when you got the results back at the line printer. The best time-saving technique was to make sure your code was correct in the first place, a term called 'desk checking'. It seems modern technology is expanding to consume all of the time- and labour-saving convenience it has introduced.
  7. If used correctly, a single-allocated vector (capacity is known at creation time, same as an array), vector will always be faster than array because optimizing the data flow of memory pointer to by degenerate pointers is hard. We had to disable the part of GCC that optimizes that because it would lose track of the fact that memory was being written to and treat the pointer (array) as read-only as it travelled through function calls, under certain edge conditions (eg. a lambda reference capture in which it was the second capture and the first capture was larger than 12 bytes -- the life of a compiler support engineer can be interesting). The compiler always has knowledge about a vector as it gets passed around, so that problem can not happen and amazing optimization opportunities can obtain. The C++ standard library was developed a generation earlier than Microsoft's internal coding guidelines were even though of. Microsoft's style is based on the style of Apple Toolbox they copied, which in turn was based on the Pascal language. The Pascal conventions developed in Europe differed from the Unix and C conventions developed at Bell Labs in the USA in many ways, including the use of upper-case letters in identifiers and the use of non-alphanumeric characters that do not appear on localized keyboards in the respective countries (trigraphs anyone??). One is not objectively better than the other. It's not really reasonable to dismiss something just because it's not what you're used to. The answer to the question of what's wrong with "Vector" instead of "vector" is this. Nothing, except that's not how it is. A decision was made between arbitrary choices in which one had the greater weight of tradition and consistency at the time, and trying to retrofit later social trends has no tangible benefit and great cost. As for me, I can't stand capital case. I didn't cut my teeth on Microsoft, I learned using C, Fortran, Algol, Bourne shell, and everything on Unix and VMS all of which used all-lower-case. Capital case is too unlike writing plain English, in which I capitalize only the first word of a sentence and some proper nouns. I do not Capitalize Common Nouns (identifiers) or any Verbs (functions). Programs are lityerature intended for other readers, and forcing them to read Chaucer is undesirable.
  8. Bregma

    My main complaint with OOP

    The problem with OOP is that you can always write bad code in any language, using any paradigm. Coming up with example of bad code written using a given language or paradigm does not in fact act as an example of why the language or paradigm is bad, it's just supporting evidence of how bad coders can create bad code. Languages and paradigms are forever being touted as a great way to get less-expensive labour to create product at greater profit (although not always in those words -- but do a close reading on claims of "reduced time to release" and "less error-prone"). It turns out software development is like those squishy things where if you squeeze one part it bulges out in another part. OOP makes reasoning about many things easier (and reasoning about things is the biggest cost in software development and maintenance) at the cost of more typing (always cheap) and either better planning (large up-front cost but very low cost amortized over the lifetime of the software) or constant refactoring (lower initial cost but larger cost amortized over the lifetime of the software). If your goal is a write-once-and-throw-it-over-the-wall app, OOP is a poor choice and Agile is your friend. If you need your stuff to run on a HA server for years processing trillion-dollar financial transactions, double-down on OOP with a lot of design up front. tl;dr OOP is no more problematic than any other design paradigm, but can be abused and can certainly add to development and maintenance cost when used incorrectly.
  9. You'll love this proposal in front of the C++ standards committee. Why use a DSL when you can just customize the language itself?
  10. You can have const reference members, but you have to follow the rules. Be aware that having a const reference member means you no longer have value semantics in your object, and that means things might not work the way you intuitively expect them to. If you use pointers, you still have to follow the rules. It takes the same amount of space in memory, but what it tells the reader is subtly different.
  11. Bregma

    C# Has C# replaced C++?

    Hardly. DSOs (dynamic shared objects -- DLLs, .so files, .dylibs) are relative newcomers. I remember when AIX on the RS/6000 didn't support them at all. and certainly RSX on the PDP/11 didn;t support them -- how could it, it didn't even support virtual memory, although it supported shared pages through the FORTRAN /COMMON/ construct. Nope, DSOs are maybe a few decades old at best. Programming has been around for centuries. @Gnollrunner is completely correct when he distinguishes between native binaries and those that need a native interpreter. They are different solutions to the problem of portability, with different trade-offs. They all, however, require non-trivial runtimes.
  12. What do your LOD copy constructor and assignment operators look like?
  13. Bregma

    C# Has C# replaced C++?

    Not sure what you're trying to say with that sentence fragment, but std::thread and friends is a completely portable C++ API for threading supplied by the C++ runtime. It provides a standard, portable thread API built on top of the OS layer. If you were to skip the runtime, you would need to write some assembly to load registers with the appropriate values and raise a software exception to switch to the kernel ... in the case of Linux on x86_64, for example, you would load the value 56 into the extended A register (among other values and registers) and issue an INT 0x80). Naturally you would need to set up tables and track values and adjust things both before and after the OS call, keeping in mind you call it once but it returns twice. Other OSes have a completely different set of registers and values involved. Or a one-liner of std::async(myfunc) gets you going using the C++ runtime. Fact is, if you're not loading hardware registers manually you're using a language runtime. That goes for both CPU, GPU, and peripherals like your hard drive, network card, keyboard, and mouse. It includes OS concepts like threads and processes. Like almost everything else you might want to do in a program (including high-quality graphics-intrensive games) you never need to go directly to the OS. The C standard library provides everything you need to do basic text-based programming (what kiddies these days call 'console programming' not to be confused with programming for consoles), and libraries like opengl provide an additional facility for hiding the nasty business of talking to a GPU. Sure, the C (or even C++) runtime is not the same as the JRE or .NET in terms of how the programs get linked together. It's the same as Java or C# in that the runtime has to be available on the system and the program has to be loaded in to it in order to run. PS. some might be surprised that the "loader" that takes a .EXE file and turns it into an executing program is actually part of the C runtime, not part of the OS. The whole question of "will C# replace C++" is like asking if Uber will replace Honda.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!