OSDev.org

First an apology as I think this is perhaps too off topic for OSDev but I would be happy for either an answer or a direct to a more relevant forum.

Having stepped into every pot hole on the road I no have a working kernel cross compiler and am working my way back to where I was about 2 months ago. I have chosen to implement using C++, which may turn out to be a poor choice in the long run but for now it is certainly exercising my limits.

I have just begun to use lambdas instead of explicit for or while loop and they have worked well in my hosted environment and I am now porting them across to the kernel which means I require some minimal headers to support these features.

So I have begun with <functional> and the very minimal content shown below which fails to compile giving an error saying the function is not a class template. I have looked for examples and explanations finding none that descibe this form of template declarations. Given it is a straight copy and severe trim of the declration from the GCC include file I am stumped.

It indicates, of course, that I do not really understand what is going on here, so I am trying to find the c++14 spec to read, but in the mean time is there a compiler switch I should use (doubtful) or is it clear that I have missed something that would allow a declaration of this form?

hubris wrote:

Code: Select all

  
    template<typename _Res, typename... _ArgTypes>
    class function<_Res(_ArgTypes...)>
    : public _Maybe_unary_or_binary_function<_Res, _ArgTypes...>,
      private _Function_base
    {
        ...
    }

You need a class template that has the exact number of template arguments; your implementation is the only used specialization (so that all others give a compile error and so you can use a more shiny type). Also, unary_function and binary_function are deprecated; might as well not implement them locally.

Thank for the guidance. I have used your suggestion and have been able to move forward a fair way to the next sticking point. A brief description I have a Unicode class that supports a method with a std:function argument which I use to iterator over the individual code points in the Unicode "string". I have a simple write to video memory prior to, and after the execution of the lambda which I pass into the method.

When I execute the program every thing runs, the guards are displayed but nothing of the Unicode "string". I have stepped through the code to the point where the lambda operator () method is called however nothing is displayed! So this question is how to determine if the correct operator () is being called, although I cannot see that there is any alternative.

w.r.t your comments about unary and binary I have read this as well. However I am still learning. and shooting myself in the foot, so I have started with the most recent gnu files and have tried to cut them down to the minimum I require for these initial kernel booting steps.

I have also put a write to video memory in the operator () declaration in the template but this is not happening, as well as the bochs xchg bx,bx debugging instruction so I can see the template method is not being called so I do not know where it is going.

So less of a question and more of a befuddlement as I am running out of ideas on how to determine where it is all going! I have not had success with using the *.map file because I am creating a binary format file so I am a little stumped at the moment.

I would suggest having a string with a code point iterator instead. I've implemented one that's 99% std::string except when it's directly logical and beneficial to not be that.

- data() returns raw data, begin()/end() are code points
- size() is raw data size, length() is number of code points

Constructor has char16_t and char32_t constructors for UTF16/UTF32 string inputs, internally all is UTF8.

Also, as this code should be 100% free from your OS environment, have you thought making some program that just tests it on your regular dev environment? Call it a unit test, maybe? Then integrate that in the build so that when it fails your build breaks - so you don't go and test an OS that's 100% certainly broken.