Jump to content

  • Log In with Google      Sign In   
  • Create Account

Bregma

Member Since 09 Dec 2005
Offline Last Active Yesterday, 12:17 PM

#5274474 messing up the functions from inherited classes from two different base classes

Posted by Bregma on 05 February 2016 - 10:41 AM

Apparently WoopsASword is right - you can't do OOP without some globals

I do not see where he said that.
 
Try passing your currentChar to your Stage1::logic() as a parameter instead.  Something like the following.

 
int main()
{
    Ryu currentChar;
    Intro introState;
    GameState* currentState = &introState;
 
    currentState->logic(&currentChar);
    currentState->handle_events(&currentChar);
    currentState->render(&currentChar);
}



#5274434 Read one text line without limit correctly

Posted by Bregma on 05 February 2016 - 07:07 AM


Using fgets you can read one line correctly but you need to know the max line size possible.
How read one line without limit correctly ? Read each character until '\n' is the only way ?

If you're reading from a C standard library FILE object, yes, that's the only portable, reliable way.  Use the fgetc() function to read one character at a time until it returns EOF or static_cast<int>('\n').  Don't worry, a C FILE object performs buffered input, so it's not actually inefficient.  The fgets() function is probably implemented that way underneath.




#5274431 messing up the functions from inherited classes from two different base classes

Posted by Bregma on 05 February 2016 - 06:59 AM

1st question goes to Wooh: Are you suggesting that I should make a third base class and inherit all the levels (without the menu and intro ) from it? Because I already have a base class for the different screens( like intro, menu, character select, and the stages where you fight ). I really don't think it's a good idea to make another base class. I think i should somehow find a way to call the ryu logic() function into the Stage logic() function. I already have GameStates that should deal with everything, 3rd base class is ugly, in my opinion.
2nd question goes to WoopsASword: Ryu's logic is in the ryu class in the function logic(). And I've already made a base class Character. And what do you mean by 'register and instance to the level class'?

Sounds like you need to understand the difference between a class (a description of data and the rules for operating on those data) and an object (a realized instance of a class).  An object of your Stage class needs to be able to ask an object of your Character class to do its logic().  Inheritance is not the right tool for this job.




#5274071 Who vs. whom

Posted by Bregma on 03 February 2016 - 10:46 AM

I'm asking because I'm not a native speaker and I try to follow the grammar rules as much as possible, but the use of "whom" doesn't always sound right to me and it seems like many native speakers don't even use it.

Unless you like to wear tweed jackets with leather patches on the elbows and hold a teaching position at the University of Oxford, you can generally get away with never using 'whom' and always using 'who.'

Unlike many languages, there is no central government authority in English that decides what correct grammar is. We leave that primarily to people called 'prescriptive grammarians' who like to discuss these things at length in the free time they have because they do not get invited to parties or social events in general.

There are a number of style guides you can choose to use for your writing. "The Elements of Style" by E. B. White and William Strunk Jr. (casually known as 'Strunk and White') says to just relax and use 'who' everywhere, so if that's what you choose to do, you can do that with impunity and cite that as a reference.




#5270214 Python for 1st language?

Posted by Bregma on 08 January 2016 - 10:11 PM

Python is an excellent choice for learning to program.

I would go farther and say C++ is not an excellent choice for learning to program.


#5270191 Criticism of C++

Posted by Bregma on 08 January 2016 - 07:04 PM

I'm not proposing to change pass-by-value mechanism. Instead what I am proposing is the ability to modify function arguments and return value the same way as any normal variable.

You just gave the definition of pass-by-name. You're proposing to use pass-by-name instead of pass-by-value.
 
Algol used pass-by-name.
 
Turns out it can be really hard to write good code using pass-by-name.  Consider this classic snippet of Algol code.
 begin integer i;
        integer procedure sum(i, j);
            integer i, j;
                comment parameters passed by name;
            begin integer sm; sm := 0;
                for i := 1 step 1 until 100 do sm := sm + j;
                sum := sm
            end;
        print(sum(i, i*10 ))
Because the parameter "j" is "i+10" every time i gets incremented, so does j.


#5270157 Criticism of C++

Posted by Bregma on 08 January 2016 - 03:14 PM


think 'C++' has many flaws. One of them is the functions.

Well, it's an interesting criticism, but I think it's a little off base for this topic.

 

The most fundamental construct of the C programming language is its use of functions parameterized on pass-by-value arguments.  Using pass-by-value instead of some of the more complex methods used by competing languages at the time (pass-by-descriptor in FORTRAN, pass-by-reference in Algol, functional programming in LISP) allowed a C language compiler to be very small, very fast, and very portable and made most of the programs written in it smaller, faster, and more portable too.  Hence its long-term continuing success over its rivals over the past 40-odd years.

 

The rather verbose post above criticizes the pass-by-value machanism in favour of a pass-by-name architecture.  Fair enough:  there are a number of ways of passing parameters into subroutines, and the designers of the languages are usually aware of the tradeoffs involved when choose which mechanism(s) to specify.  Perhaps in alternate universes we all use Modula-3 to write complex systems (except for MacOS, which uses Oberon).  Fact is, pass-by-value is Good Enough and easier to get right when writing a compiler, even if sometimes it can cause performace problems when not used correctly.




#5270109 Fast C++ book

Posted by Bregma on 08 January 2016 - 11:57 AM

There is no better reference work than "The C++ Programming Language" by Bjarne Stroustrup.

 

If you have trouble using that as a reference book, the problem is not with the book.




#5269943 Should I Take AP Biology?

Posted by Bregma on 07 January 2016 - 06:25 PM

I have no idea what an AP is, but I'll give the same advice I always give to this question.

 

You're not an entrance qualification, and you will not be a career when you're done your education.  Study what interests you.  If you have no interest, make your studies wide until you've found your interest.  If you've already found your interest, make your studies wide in case you lose your interest.

 

Post-secondary education institutes often look at your overall average, as well as other factors such as work load and extracurriculars.  If you can pull off all those honours courses, it will prove you can handle an engineering workload post-secondary.

 

I never studied biology in high school and I managed to get an education and a job.  Funny thing was, the only prereq for both first year biology and first year chemistry was senior-year (grade 13!) high school physics.




#5269409 C++ Deleting data from files

Posted by Bregma on 05 January 2016 - 07:59 AM

You need to understand that filesystem operations are OS-specific and not a part of the C++ language.  Not every C++ target even support filesystems, so there's a good reason for it.

 

From the point of view of C++, there are only data streams.  Those data streams may or may not be attached to underlying persistent storage provided by the operating system.  The C++ standard library provides a few rudimentary operations that may correspond to operations on the underlying storage, like fpos.  If you want full control of the underlying storage, you need to write OS-specific code.  For instance, positioning the record pointer in an ISAM file, which would be ideal for your application but sadly not supported by most of today's filesystems.  You will probably also need to use the underlying OS read/write calls.

 

A POSIX OS provides os-level calls like open/creat/read/write/seek.  Other OSes provide similar low-level calls (and often a POSIX-compatible layer if they're not POSIXlike to begin with).

 

Traditionally, for text files, the entire changed file is rewritten to a temporary file and the the underlying OS file manipulation calls are used on success to move the temp file onto the original file (a replace operation).  C++17 is going to contain a filesystem library to help with that.

 

Notice that writing a temp file and then copying it, or writing a temp file to somewhere other than the target destination and renaming it from there, are bad ideas.  A locked-down secure OS will often fail the rename or copy operation.




#5269384 Criticism of C++

Posted by Bregma on 05 January 2016 - 05:40 AM


C++11 broke backward compatibility, C++17 will also do this.

Can you point to any breaks?

 

I know some vendors had implemented some unspecified library functionality in one way, and the C++11 standard clarified or specified the functionality (the O(1) behaviour of list::size() for example).  That's not a backward-compatible change in the language, and all code continues to compile correctly.  It was a change in the runtime.  MSVC for example, does that every release even though the language hasn't changed.




#5268990 Criticism of C++

Posted by Bregma on 03 January 2016 - 08:13 AM

It has been my experience that when you start reading a criticism of something on the internet, you should first find out what the ask is.  Someone posts a criticism of C++, you need to find out what product are they going to try to sell you.

 

Sure, C++ is imperfect and ugly, like most things that evolved to fill a niche.  If any of you have seen a naked human body (I'm sure a few of you probably have) it's damn ugly and full of impractical and poorly thought out bits, and certainly maintenance becomes increasingly difficult over a lifetime of its use.  Despite that we have yet to come up with some centrally-designed equivalent that comes anywhere near replacing it.

 

C++ is a terrible language, and all the others are even worse.




#5268825 Random Number Generator Seed Initialization

Posted by Bregma on 02 January 2016 - 08:02 AM

It depends on what you're trying to do with what.

 

If you're only ever going to use a single LCG PRNG, then if you want it to act like a global variable, go ahead and use a global variable as its seed.

 

If you want to use something more sophisticated than a single 32-bit LCG, like a lagged Fibonacci or a Mersenne Twister PRNG, then a 32-bit initialization vector is insufficient to start with.

 

If you want to use several different PRNGs in an application, how could a single 32-bit initialization vector ever help you?

 

If you're relying on a single 32-bit initialization vector in the global namespace to be uninitialized to use as a seed value for any PRNG, you are in for a quality debugging treat.

 

Initializing an initialization vector in the constructor of a PRNG object makes no sense.  You want to pass the initialization vector in to the constructor so it can use it to initialize the PRNG.




#5268165 C++ Class Constructor

Posted by Bregma on 27 December 2015 - 09:04 PM

You have an error in person.h, which is included before phonebook.h.  It's possible that that error, which sounds like it may be a typo or a syntax error but is in a source file you did not include in your post, may be causing a cascade of interpretation errors elsewhere in the translation unit.  Try focusing on that problem first.
 
Also, to eliminate the possibility of the most vexing parse, try changing line 30 of phonebook.cpp to

Phonebook myBook = PhoneBook(setPhoneBookName());

and see what happens.




#5268163 Why automake?

Posted by Bregma on 27 December 2015 - 08:55 PM

The autotools are the gods gift to programmer kind.  Before the autotools, there was chaos and a sort of dark evil lurking horror of formless void.

 

If you're on a POSIXish system there is nothing better for handling cross-platform builds.  The autotools fall down when it comes to Windows builds, but they're no worse than the alternative of CMake or handling MS Visual Studio configurations manually.

 

It's funny that even CMake relies on the autotools to be ported to a new platform before it can be ported.  Well, not exactly, because the autotools do cross compilation with such ease and grace, so you only have to bootstrap the CMake prerequisites from an existing port.

 

If you're shipping a generated Makefile with your autotools project, you're doing it wrong -- it makes no more sense than shipping your Win10 .EXE file to you Mac or Android target.  It's designed to build from a read-only source tree, so if you're getting artifacts in your sources you're doing it wrong.

 

There was an effort once to replace the autotools with pure GNUmake (google for "quagmire") but it didn't do anything the autotools couldn't do and the autotools don't require the arcance GNUmake function syntax and opaque debuggability.  The Linux kernel uses an extended GNUmake engine for its kconfig utility, and that's been adapted throughout the embedded world but in my experience, it's even more arcane than the autotools.

 

I don't want to preselytize the autotools:  choose the tools that work for you.  But, don;t diss the autotools just because you're personally unfamiliar with them and have read opinions on the interwebs somewhere.  I came from the time before the autotools, and I've used them extensively in a lot of places, and I tell you the're a really good tool that almost always is the best choice for the job.






PARTNERS