Jump to content

  • Log In with Google      Sign In   
  • Create Account

Bregma

Member Since 09 Dec 2005
Offline Last Active Oct 17 2014 06:25 AM

#5015229 Heap Corruption with ifstream and delete[]

Posted by Bregma on 28 December 2012 - 05:45 PM

If I were a gambler, my money would rest on the fact that you do not check the success of the read() call, and the fact that ifstream::eof() doesn't work they way you're using it.

 

At a guess, this might work better.

//.. preamble

int c = 0;
while(reader.read(pixelInfo, 3)) //pixelInfo is a char[3]
{
  //Filling RGBA info into my bitmapArray
  bitmapArray[c] = pixeInfo[0];
  bitmapArray[c + 1] = pixeInfo[1];
  bitmapArray[c + 2] = pixeInfo[2];
  bitmapArray[c + 3] = 255;
  c += 4; //increasing C for the next values
}
reader.close();

//Here I use bitmapArray for some stuff

 




#5014101 How to use bool variable.

Posted by Bregma on 24 December 2012 - 10:47 PM

In my opinion, using an actual comparison in a conditional clause is more readable than using a Boolean expression without one.
 

if(ReturnsABool() == false) {...}   /* is better than */   if(!ReturnsABool()) {...}

Your sentence should more correctly read 'using an actual boolean-valued comparison expression in a conditional is more readable than using a boolean-valued expression without one.  I don't believe this is true, but I believe parsimony is a virtue and one should eschew the obfuscation of unnecessary verbosity and redundancy.

 
Also, testing a Boolean expression for equality is more readable than testing it for inequality.
 

if(ReturnsABool() == false) {...}  /* is better than */  if(ReturnsABool() != true) {...}

I would phrase that as "positive logic is easier to reason about than negative logic."  Alternatively, you could say that it is not easier to reason about negative logic.

Along the same lines, I prefer to pass enumerated values as parameters over integers or Boolean values. 
 

car Car(car::RED);  /* is better than */  car Car(0x02);  /* or */  car Car(true);

This.  Every time.
 
However, there is a place for well-named boolean variables and functions.  Their use in control structures contribute greatly to the readabilty of code.
 
If find this

while (thread.is_running())
{
  // ...
}

quite an improvement over

while (thread.is_running() == true)
{
  // ...
}

Try reading them both aloud to see which one makes more sense.


 




#5013655 CHandle Wrapper overloaded operator help

Posted by Bregma on 23 December 2012 - 07:37 AM

In summary, there are three practical solutions to your problem.

 

(1) provide a conversion operator operator HANDLE(){ return m_h; } and rely on overload resolution to so the right thing.

 

(2) provide a getter, similar to std::string::c_str() and use that explicitly at the call site.

 

(3) provide a member function ReadFile() to wrap the system-provided one and use you member variable privately.

 

There are advantages and disadvatages to each.  For example, option (1) will use overload resolution in unexpected and very difficult to track down places, and over the years you'll learn a non-manifest interface is clever for the junior guy that writes it but really costly for the folks who come along later trying to fix the bugs is causes (and that may be you).  Option (2) is good, but not really much different from using a simple all-public C-style struct, or even better a simple scalar variable.  Why even bother with the class?  Option (3) may grow hairy as you find you need to add Open() and WriteFile() and Rewind() and all kinds of other overloads.

 

Of the three, I would recommend option (3), mostly because I find object-oriented designs to be less costly to maintain (that is, easier testing, fewer bugs overall, and shallower learning curve for those unfamiliar with the code).  I would run from solution (1) screaming because non-explicit code is about the biggest maintenance nightmare there is, outside of old-fashioned spaghetti code (and that seems to have suffered a Darwinian fate).

 

Edit: formatting in the new goram UI is pretty messed up right now/




#5012529 Once you go OO, you never go back?

Posted by Bregma on 19 December 2012 - 12:26 PM

this will become tragically clear once you'll try to debug a big project where everything can talk and modify everything else

QFE

A lot of game code tends to be write-only, but in other programming domains maintenance turns out to be the bulk of the cost of software. Good OO design leads to well-defined interfaces and good decoupling, which in turn leads to improved testability and easier reasoning about the code, which further leads to fewer bugs, fewer staff hours for fixing problems, and less cursing and grumbling (and lower staff turnover).

OO is a very useful design tool. It can be a very useful implementation strategy. So-called Data-Oriented Design is a refinement of OO using many of the techniques pioneered for procedural programming in the 1970s by the likes of Coad and Yourdon and rediscovered recently by people who didn't pay attention in computer science class.

As for the OP, congrats on gaining the OO achievement. Keep playing, the game's not over yet.


#5010224 Considering move to C++

Posted by Bregma on 13 December 2012 - 08:28 AM

C++ is a multi-paradigm language. It supports you if you want to do OOP. It supports you if you want to do imperative. It supports you if you want to do metaprogramming. It supports you if you want to do functional programming. It gets out of your way of you choose not to use those paradigms.

The biggest and best thing about C++ is it supports the RAII paradigm (which requires a certain amount of OOP). That alone makes C++ stand head and shoulders above C or Java and any other language with non-deterministic destruction. You can use RAII using only std::unique_ptr and lambdas if it's important that you avoid the appearance of using classic OOP.


#5008785 Copyright protection, USB dongle?

Posted by Bregma on 09 December 2012 - 07:53 AM

Yeah, I remember the days when the salepeople from dongle companies were making a killing and we'd have a chain of these things hanging off our serial ports (this was before USB was invented).

I was even then easier to use archie to grab a cracked version of software because either your dongle was faulty, or they'd interfere with each other, or you could use only one at a time, or they didn't work at all with the particular version of hardware or OS you were running.

Short answer: no, there is no technical way to prevent software copying using DRM.


#5007131 Namespaces good for anything else?

Posted by Bregma on 04 December 2012 - 11:17 AM

Just for the record, C++ namespaces can also be used to perform compile-time selection of alternate implementations. You don't see it very often, but when it's needed it's very useful.


#5005688 Is C++ too complex?

Posted by Bregma on 30 November 2012 - 08:06 AM

I'm of the opinion that exceptions as implemented in C++ are too costly to be used in the same fashion as they are in C#/Java. I use exceptions in C#, but never ever use them in C++.

It's funny, because ,y gut feel puts me in the same position with many constructs. Using dictionaries or regular expressions in Python, for example, is normal but in C++ I tend to avoid them because they're expensive.

Funny thing is, much of the time such constructs in higher-level languages are implemented using the underlying C++ construct. For instance, Java exceptions in the GCC Java runtime are implemented using exactly the same mechanism as C++ exceptions (it's the same libgcc_s.so file on my system). Any performance barrier is psychological: Java forces you to pay the cost always by design, C++ allows you to pay only for what you use, and you can avoid using exceptions, so you feel guilty about waste.

I am still of the opinion that exceptions are too costly to use for anything but exceptional situations. I limit (but not avoid) their use in C++, avoid Java completely, and use Python mostly for prototyping.


#5004828 'virtual static const'

Posted by Bregma on 27 November 2012 - 10:06 PM

Firstly, I am using inheritance correctly. The base class is virtual so LSP doesn't really apply

Hmm. I am having an awful lot of trouble getting those three statements to align correctly.


#5004258 Cross platform directory list

Posted by Bregma on 26 November 2012 - 12:16 PM

Aren't there any standard functions for this?

No, the concept of file hierarchies is pretty platform-specific. Like the concept of a GUI, there is no standard way to do something that's not standard across platforms.

Unless you really think it's really necessary to have a hierarchical filesystem on a toaster. Or a phone.


#5003733 Had I chose right degree?

Posted by Bregma on 24 November 2012 - 07:05 AM

I still don't know if I have chose right degree.

Relax. Stop worrying.

Getting is a degree, any degree, is what's important, and in a computer-related field is even better. Some of the most successful people I have met in the field majored either in physiscs or in English literature.

The fact that you can stick it through and be able to focus despite external distractions, and have learned how to learn on your own, is what a degree proves. It is not job training.

When I am acting as a hiring manager, I glance once at their resume to check that a person has a degree (and preferably in a computer-related field), but spend most of my time reviewing what they've done outside of academia. So if you want to be a game developer, develop games. It's that simple.


#5003332 OpenGL for Linux and MacOSX?

Posted by Bregma on 22 November 2012 - 04:32 PM

I simply need a pure OpenGL context 4.x, no extra lib, no fancy stuff, only the core… I’d really appreciate if anyone could help clear this up.

Problems is there's not really such as thing as a pure OpenGL context. You're going to need something to draw to.

Even if you're going full screen, you're not directly programming the GPU and you're not driving the video output chips, you need to go through the OS kernel. A typical modern OS kernel is design to prevent you from getting at the hardware directly: you need to ask it nicely at the very least if it will do you the favour of accessing the hardware on your behalf. On a GNU/Linux system, that means getting the X11 server to share nicely. On Mac OS X that means getting the Quartz service to share nicely. Even on Microsoft Windows you need to share nicely with other applications calling into the embedded display service. On Android you use EGL to share the flinger nicely.

There are cross-platform libraries that will get you an OpenGL context. That's what they're for and why they're there. SDL, for example, works very well on all the above platforms. If you insist on doing without such a library, the source is free so you can see how it works and reimplement it yourself. Of course, it might turn out SDL uses glx/wgl/egl underneath, because to do otherwise would reimplement all those ioctl/X11/port/SYS calls. Might be worth checking, though, or even just using the library directly.


#5003303 OpenGL for Linux and MacOSX?

Posted by Bregma on 22 November 2012 - 01:47 PM

I can't answer about MaC OS X, it's been too many years for me. Linux isn't an OS so there's no definitive answer there, but I can tell you about Debian-derived OSes (like Ubuntu), which are GNU-based OSes that can sometimes use the Linux kernel: try installing the libgl1-mesa-dev package. If you're asking about Android, another common OS that uses the Linux kernel, the GLES libraries should come with your devkit.

The answer to why your third-party software (skaslev-gl3w) uses GLX, well, you'd have to ask whoever developed it, but it's a handy and standard way to create a GL context on an X11 server.


#5003107 How do I properly... dispose of a vector<>

Posted by Bregma on 21 November 2012 - 09:33 PM

Do I need to delete it, dispose it, clear it, take it to dinner and a movie?

You can take it to dinner and a movie, but don't feel you have to. Like most dates, if you just ignore it completely eventually it will go away and leave you to get back to productive programming.


#5003105 bitvectors?

Posted by Bregma on 21 November 2012 - 09:29 PM

Interestingly, std::vector<bool> is required by the standard to be a specialization that packs the bools into single bits for the very reason of saving space. It was included in the standard as an example of how to write proxying containers. I believe many committee members later regretted that.

The std::bitset container also provides a bit-oriented container, complete with boolean operations and a cunning string-serialization interface. Guaranteed to take only one bit per bit, and when compiled with release-level optimization generates the same code as C-style bitmask operations for smaller-sized sets.

Since the C++ standard library has provided these appropriate containers for about a generation, perhaps the book include the bitvector class as exposition?




PARTNERS