Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Bregma

Member Since 09 Dec 2005
Offline Last Active Today, 04:07 PM

#5193660 Need a short name to replace a really really long function's name

Posted by Bregma on 19 November 2014 - 02:05 PM

 

I think long function names are generally a good thing as they are more descriptive. As long as you have some sort of autocomplete, you shouldn't have to type it all out, and most nowadays support just typing the initials (SPBOCP). If you are looking to reduce the length of the names, think about what information is implied by the function parameters and return type.

 

If I have a function

public List<Friend> GetListOfFriendsByID (int id)
{
    //Return new list with my friends
}

I can see that it clearly returns a List and I can clearly see that I am passing in an id. I can now shorten the name to

public List<Friend> GetFriends (int id)

Clearly you are getting data.  It should really just be public List<Friend> Friends(int id);




#5193357 libvorbis, libogg and libtheora

Posted by Bregma on 17 November 2014 - 08:34 PM

Yes.  Mostly.

 

Most AV files are containers with encoded audio and video.  A typical playback application pipeline consists of a transport stage (read or stream the data from source), parse, demux, decode, convert, and then feed to the sink.  Recording applications go the other way through a muxer.  Transcoding applications do both.

 

It's possible to use vorbis encoding with other container formats.  For example, a Matroska file could carry a vorbis video payload.  Ogg can also contain other data, for example text streams, as well as other formats such as AVI video.

 

File extensions are irrelevant unless you're trying to write a trojan virus.  Like most data files, a sequence of 'magic' bytes at the start of the file identify the actual container format, and the container indicates what data formats it contains.  Consider the advantage of magic bytes in data streaming over a network connection:  where do you put the file extension?




#5191085 Header for Common Includes

Posted by Bregma on 04 November 2014 - 05:52 AM

I'm starting to realize that this is bad practice, however. Should I only include these common files when I need to in the source files (possibly header files) where needed? Is this a better way to go?

Yes.

 

By minimizing physical coupling, not only does it improve compilations times (even if you use precompiled headers), it helps enforce reduced logical coupling and strong layering. Those two design philosophies that can have a sharp impact on maintainability of anything larger than a trivial codebase.




#5191083 Datatype Size and Struct Compiler Padding

Posted by Bregma on 04 November 2014 - 05:44 AM

It's not just C variable size and struct padding you need to worry about:  there's also alignment requirements.
 
For example, if you have an odd number of chars in a string followed by a long integer, you might end up with the integer written to an odd memory address.  Some silicon bent on supporting ancient software (eg. x86) will simply be slow when accessing an odd address, some (eg. ARM) will raise a bus error and your program will crash.  Sometimes the exact behaviour depends on how the OS was configured at build time and sometimes on how the language runtime was configured at build time.
 
Also, if you write floating-point binary you're in for a whole nother world of pain.  There are a number of different formats out there, which again might depend on the silicon, the OS, the build-time configuration of the OS or language runtime.  ARM (most phones and tablets) is particularly prone to this.
 
Some processors also change the size of the integral types under some circumstances.  A modern ARM processor, for example, has an entire second instruction set (Thumb) with smaller data sizes and instructions.  You need to be darn sure the compiler doesn't insert that during optimization, although most language runtimes won't do that during I/O.
 
Short story: avoid direct binary read/writes of internal data structs if you ever ever will do that on a machine other than one single development machine that will never be upgraded.




#5190123 weird header behavior in gcc and llvm

Posted by Bregma on 30 October 2014 - 06:33 AM

Here's a tip.

 

Physical dependencies should always be a DAG (directed acyclic graph).  Always.

 

One aspect of that is that lower-level things should never depend on higher-level things.  A source file down the hierarchy should never depend on one up the same hierarchy.  Same goes with link-time dependencies (libraries, etc).  Directed acyclic graphs.  Only.

 

Using forward declarations is one of the tools given by the designer of C to allow you to have cyclic logical dependencies without having cyclic physical dependencies.  Logical coupling should be minimized: physical coupling even more so.

 

Also, header files should only contain the public interface of a module.  The should expose only what needs to be exposed, no more.  They should also be idempotent:  they should include everything they must include, and no more, and be included in any arbitrary order.




#5189951 Why do I need to define methods twice?

Posted by Bregma on 29 October 2014 - 10:18 AM

Simple answer: you don't have to, except under certain limited situations.

Complex answer: the compiler process a translation unit in top-to-bottom order (as required by the language standard -- in fact, it is possible write a single-pass C compiler because of that). Because C is a strongly-typed language it needs to see the declaration of something before it can use it, otherwise it can not know its type. To work around problems of circular dependencies, you're allowed declare things separately from their definition.

Often, declarations are placed in a header file so the compiler can ensure declarations and definitions match across compilation units at compile time. A mismatch at link time or run time is too late, because information is often lost by that time (a feature that has resulted in C still being very useful after more than 4 decades). C++ carries more type information at link time, which is why people complain about cross-compiler ABI stability. Java does absolutely no checking at all between classes until runtime, which can be considerably more expensive than compile time in terms of developer productivity.

So, in short, being able to declare a C name separately from its definition gives the programmer the power to have mutual name references and one-pass compilation at the same time, and have improved compile-time checking with separate compilation of translation units. It's very possible to write a lot of C or C++ code without ever writing separate declarations and definitions.


#5189212 Error: unique_ptr constructed with null deleter pointer

Posted by Bregma on 26 October 2014 - 06:50 AM

Without seeing either the error message you're trying to get help with or the code causing it (why do you think you will get useful help if you describe neither the problem nor the cause?), my guess is you're likely invoking undefined behaviour.
 
If you look at the standard, it says this.

Type requirements
  - Deleter must be FunctionObject or lvalue reference to a FunctionObject or lvalue reference to function, callable with an argument of type unique_ptr<T, Deleter>::pointer

That means what Juliean says above is likely the cause of whatever mysterious problem you're encountering. Without seeing the definition of your delete_func it's hard to say, but I would expect any quality C++ implementation to give a compile failure if your code does not conform to the "must" requirements in the standard.


#5187354 c++ segmentation fault

Posted by Bregma on 16 October 2014 - 04:52 AM


Is there a reason (excluding complex reasons I'm not likely to ever come across) to avoid doing things this way, or is this perfectly acceptable practice?

It's the way the language was designed to be used.  It's not only acceptable, but one of the reasons why C is still useful after half a century and all the alternatives die off after a decade or so.




#5187352 scan a string character one by one & hexadecimal code

Posted by Bregma on 16 October 2014 - 04:47 AM

By "hexadecimal" I think your mean "char" and you're going to run into trouble, because you're probably using a multibyte codepage and you can't treat it like US-ASCII.  You need to think about glyphs and codepoints rather than bytes or hexadecimal.  I'm not sure what encoding you're using but at a guess you might want to read up on Unicode.

 

It gets even worse (as you no doubt know) with a contextual alphabet like Arabic in which standalone glyphs differ from those in the string, where letters take on their initial, medial, or final forms.




#5186146 Test tileset (like Dwarf Fortress)

Posted by Bregma on 10 October 2014 - 04:51 AM


Where I can find full tilesets for DF?

You could start with the first result teh Googs returns.




#5184891 Is upper division Linear Algebra a good idea or necessary?

Posted by Bregma on 03 October 2014 - 11:01 PM

You are not a career.  Study what you're most interested in.




#5183793 Should I wait for OpenGL NG?

Posted by Bregma on 29 September 2014 - 10:38 AM

The grass is always greener on the other side of the fence.




#5183285 Source control with git hub/lab?

Posted by Bregma on 27 September 2014 - 06:49 AM

A big advantage of one branch per change is it makes bisection (searching for a change that introduced a bug) much, much easier.  This is only a concern, of course, if you're developing software that might need maintaining.

 

One branch per change means you can engage in test-driven development by writing the failing test, then making it pass, and using the "commit early, commit often" workflow in conjunction with the "trunk always passes all tests" paradigm.  These are all very good things to do, and doing them together is even better.




#5183201 Source control with git hub/lab?

Posted by Bregma on 26 September 2014 - 02:49 PM


You don't need to create branches just to write new code, branches have other uses.

Well, with git the idiomatic use is to create a branch for every change.  You can create feature branches for multiple changes, too, and branch that and merge the smaller changes into one large change, then merge that.  You can even do squash commits that effective make smaller branches disappear after the fact.  You can rebase branches more easily than rebasing sets of commits.  Branching and merging in git is cheap cheap cheap.  It isn't yer grandpa's CVS with its mucho expensive branch-and-tag operations.

 

You can, of course, have long-lived independent branches a la CVS, if you want.  That happens in the Linux kernel tree, where from time to time groups of changes get cherry-picked from other trees and pulled into Linus's tree, and become official.  If nothing else, git is powerful and flexible.

 

There is no "master" branch, in fact.  There's just a whole lot of branches everywhere and the meaning of each is an external semantic.




#5182127 Computer Science vs. Computer Game Science

Posted by Bregma on 22 September 2014 - 09:59 AM

A university degree is not job training.  In that light, don't worry that the name of a major at one or two institutions will condemn you to a life of slavery on the assembly line.  Chances are in 10 years you'll be working on something that hasn't even been invented yet.  Study what appeals to you, learn what you love. 






PARTNERS