Showing posts with label lambdas. Show all posts
Showing posts with label lambdas. Show all posts

Tuesday, 1 September 2020

Chapter 16 // Drills 1, 2, 3, 4 - Principles & Practice Using C++

In this exercise I am using Visual Studio 2017 and modified versions of the graphics files used throughout the chapters. You can find those versions through the link below.

Chapter 16 // Drills 1, 2, 3, 4

1. Make a completely new project with linker settings for FLTK (as described in Appendix D).
2. Using the facilities of Graph_lib, type in the line-drawing program from section 16.5 and get it to run.
3. Modify the program to use a pop-up menu as described in section 16.7 and get it to run.
4. Modify the program to have a second menu for choosing line styles and get it to run.

Github: https://github.com/l-paz91/principles-practice/tree/master/Chapter%2016/Drills

I didn't do 1 as I've been using the same project since the start of chapter 12 because I'm lazy.


The second one made me scratch my head a few times. I initially set it up in Graph.h but it didn't like that. So I moved it to Simple_window.h...visual studio also didn't like that. It didn't like it in Window.h either. Eventually, because I'm big brain, I realised I was creating circular dependencies due to certain headers that needed to be included so Lines_window is in GUI.h. Also, because Window is a class and not a struct, make sure you put : public Window when inheriting....

3 is pretty simple as long as you follow the code in the book however you need to add hideMenu() and redraw() to the change() function otherwise the menu won't close itself after you've selected a new colour.

Once 3 was working, 4 was as simple as copypasta and change some code. I decided not to implement callback functions and use lambdas as I hate them and I need to get more comfortable using them..even if I think the callback functions are more readable. Unreal Engine fucking loves lambdas. I made the change line style function take in a line style so I didn't have to create a function for every different line style.


I'm happy to have finally started this chapter though; I'm going to create some sick 1998-looking programs now.

Thursday, 20 August 2020

Chapter 15 // Exercise 5 - Principles & Practice Using C++

In this exercise I am using Visual Studio 2017 and modified versions of the graphics files used throughout the chapters. You can find those versions through the link below.

Chapter 15 // Exercise 5

"Animate" (as in section 15.5) the series 1-1/3+1/5-1/7+1/9-1/11+.... It is known as Leibniz's series and converges to pi/4.

Github: https://github.com/l-paz91/principles-practice/blob/master/Chapter%2015/Exercise%205

This took me a while to wrap my head around and I'm still not entirely convinced at how the lambda expression works but whatever.

So pi/4 == 0.7853989 (not precisely but you have to stop somewhere)

The problem with this exercise is that each frame looks identical as it gets closer to pi/4. Probably not the best function to graph. Either that or I've completely miscalculated.

Wednesday, 5 August 2020

Notes on Chapter 15 // Principles & Practice using C++

So I've been reading though this chapter and got stuck on section 15.5 where he uses a lambda expression to capture some data. The code can be seen on page 533. Here he uses Function to graph another function however I got the following error when entering the code myself:

error C2440: 'initializing': cannot convert from 'initializer list' to 'Graph_lib::Function'

I triple checked the code in the book and my code and there was no difference. Unfortunately no one else seemed to have encountered this exact problem. I eventually fixed it with some guidance from this stackoverflow post: https://stackoverflow.com/questions/36030589/i-cannot-pass-lambda-as-stdfunction

In Graph.h, the struct Function has just one constructor, with the first argument being of the type Fct. Now Fct is a typedef of a function called Fct that takes in a double and returns a double. Unfortunately, Visual Studio did not like this and would not convert the lambda expression to fit. In order to get round this, I created a new constructor that instead takes in a std::function called f that takes in a double and returns a double:


Visual Studio was happy with this and built the solution.

Fixing Window label bug
EDIT 18/08/2020 - Please read the edit down below.

I also finally fixed the weird thing that was going on with the window label. After you click next it always disappeared for me or started displaying garbage. I looked into this and found that FLTK eventually relies on this constructor for label:

void Fl_Window::label(const char *name) {
  label(name, iconlabel()); // platform dependent
}

When it calls iconlabel() it goes here:

  /**  See void Fl_Window::iconlabel(const char*)   */
  const char* iconlabel() const {return iconlabel_;}

iconlabel_ is null. This is in Fl_Window.H which I am reluctant to modify. It appears that in our Window.h, Window is calling the constructor for label and passing a char array to it. However it is not setting up the icon label.

void set_label(const string& s) { label(s.c_str()); }


iconlabel_ is set to 0 in the constructor for Fl_Window(). To fix this, it is a one line change in Window.h:

void set_label(const string& s) { label(s.c_str()); show(); }

After trying to set iconlabel_ manually it took me to another function which checks to see if the window is to be shown. It returned false. show() is a function set in GUI.h and is only called once upon initialisation of the window (which is why the label correctly displays upon first viewing). The problem is that when the label is changed we need to call show() again otherwise iconlabel_ will not be updated.

EDIT 18/08/2020 - Nothing can ever be simple. Whilst doing exercise 2 of Chapter 15, I noticed the label would go missing again if the next button was pressed to be replaced with garbage. I had a look and even just after the window has been created it's showing the title label as null. I tried setting the label in the window init() function, changing the label in the Fl_wait loop but the label was always null.

I then noticed that Fl_Window wants a const char* in it's constructor:
In C, you can use char* as strings. char* will always point to the first character in the string. Our Window and Simple_window uses a string& and then converts that to a char* using the .c_str() function. This should work just fine but in case there was something being lost in translation, I changed all the string& references to const char*. Now, it's displaying labels correctly and storing them in Fl_window. You don't need to call show() in set_label either as I changed that to take in a char* as well.

Fixing Default Line Colour

Another thing that was annoying me was that the default line colour was a light grey; this was impossible to see on the background and I was sick of always having to set the colour for everything. So I just set the default line colour to black in the constructor for Shape:
Shape() { set_color(Color::black); }