Writing a custom, highly-specialized, special-purpose standard-compliant C++ allocator The 2019 Stack Overflow Developer Survey Results Are InC++ custom memory allocatorMaximum sum subarray efficiency — divide and conquer w/ vectorsNecklace counting problem-with consecutive prime constraintSubdividing intervals that contain the largest error valuesC++ fixed-size queue full/empty signalingC++ Queue ImplementationUndirected Unweighted Graph Implementation - C++Sorted vector/set class that works with simple types (char, int, double, etc…)Generalizing std::minmax_elementC++ object pool using C memory pool as base

In microwave frequencies, do you use a circulator when you need a (near) perfect diode?

I see my dog run

Why could you hear an Amstrad CPC working?

Is this food a bread or a loaf?

Extreme, unacceptable situation and I can't attend work tomorrow morning

Dual Citizen. Exited the US on Italian passport recently

If the Wish spell is used to duplicate the effect of Simulacrum, are existing duplicates destroyed?

It's possible to achieve negative score?

Springs with some finite mass

Why is it "Tumoren" and not "Tumore"?

JSON.serialize: is it possible to suppress null values of a map?

What does Linus Torvalds mean when he says that Git "never ever" tracks a file?

What is this 4-propeller plane?

Is domain driven design an anti-SQL pattern?

Are USB sockets on wall outlets live all the time, even when the switch is off?

What is the steepest angle that a canal can be traversable without locks?

Geography at the pixel level

Where does the "burst of radiance" from Holy Weapon originate?

On the insanity of kings as an argument against monarchy

Is three citations per paragraph excessive for undergraduate research paper?

What are the motivations for publishing new editions of an existing textbook, beyond new discoveries in a field?

What is the best strategy for white in this position?

Manuscript was "unsubmitted" because the manuscript was deposited in Arxiv Preprints

What is the motivation for a law requiring 2 parties to consent for recording a conversation



Writing a custom, highly-specialized, special-purpose standard-compliant C++ allocator



The 2019 Stack Overflow Developer Survey Results Are InC++ custom memory allocatorMaximum sum subarray efficiency — divide and conquer w/ vectorsNecklace counting problem-with consecutive prime constraintSubdividing intervals that contain the largest error valuesC++ fixed-size queue full/empty signalingC++ Queue ImplementationUndirected Unweighted Graph Implementation - C++Sorted vector/set class that works with simple types (char, int, double, etc…)Generalizing std::minmax_elementC++ object pool using C memory pool as base



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








0












$begingroup$


Brief Preface



I recognize that there are many nuances and requirements for a standard-compatible allocator. There are a number of questions here covering a range of topics associated with allocators. I realize that the requirements set out by the standard are critical to ensuring that the allocator functions correctly in all cases, doesn't leak memory, doesn't cause undefined-behaviour, etc. This is particularly true where the allocator is meant to be used (or at least, can be used) in a wide range of use cases, with a variety of underlying types and different standard containers, object sizes, etc.



In contrast, I have a very specific use case where I personally strictly control all of the conditions associated with its use, as I describe in detail below. Consequently, I believe that what I've done is perfectly acceptable given the highly-specific nature of what I'm trying to implement.



I'm hoping someone with far more experience and understanding than me can either confirm that the description below is acceptable or point out the problems (and, ideally, how to fix them too).



Overview / Specific Requirements



In a nutshell, I'm trying to write an allocator that is to be used within my own code and for a single, specific purpose:



  • I need "a few" std::vector (probably uint16_t), with a fixed (at runtime) number of elements. I'm benchmarking to determine the best tradeoff of performance/space for the exact integer type[1]

  • As noted, the number of elements is always the same, but it depends on some runtime configuration data passed to the application

  • The number of vectors is also either fixed or at least bounded. The exact number is handled by a library providing an implementation of parallel::for(execution::par_unseq, ...)

  • The vectors are constructed by me (i.e. so I know with certainty that they will always be constructed with N elements)

[1] The value of the vectors are used to conditionally copy a float from one of 2 vectors to a target: c[i] = rand_vec[i] < threshold ? a[i] : b[i] where a, b, c are contiguous arrays of float, rand_vec is the std::vector I'm trying to figure out here, and threshold is a single variable of type integer_tbd. The code compiles as SSE SIMD operations. I do not remember the details of this, but I believe that this requires additional shifting instructions if the ints are smaller than the floats.



On this basis, I've written a very simple allocator, with a single static boost::lockfree::queue as the free-list. Given that I will construct the vectors myself and they will go out of scope when I'm finished with them, I know with certainty that all calls to alloc::deallocate(T*, size_t) will always return vectors of the same size, so I believe that I can simply push them back onto the queue without worrying about a pointer to a differently-sized allocation being pushed onto the free-list.



As noted in the code below, I've added in runtime tests for both the allocate and deallocate functions for now, while I've been confirming for myself that these situations cannot and will not occur. Again, I believe it is unquestionably safe to delete these runtime tests. Although some advice would be appreciated here too -- considering the surrounding code, I think they should be handled adequately by the branch predictor so they don't have a significant runtime cost (although without instrumenting, hard to say for 100% certain).



In a nutshell - as far as I can tell, everything here is completely within my control, completely deterministic in behaviour, and, thus, completely safe. This is also suggested when running the code under typical conditions -- there are no segfaults, etc. I haven't yet tried running with sanitizers yet -- I was hoping to get some feedback and guidance before doing so.



I should point out that my code runs 2x faster compared to using std::allocator which is at least qualitatively to be expected.



CR_Vector_Allocator.hpp



class CR_Vector_Allocator 

using T = CR_Range_t; // probably uint16_t or uint32_t, set elsewhere.

private:
using free_list_type = boost::lockfree::queue>;

static free_list_type free_list;

public:
T* allocate(size_t);
void deallocate(T* p, size_t) noexcept;

using value_type = T;
using pointer = T*;
using reference = T&;

template struct rebind using other = CR_Vector_Allocator;;
;


CR_Vector_Allocator.cc



CR_Vector_Allocator::T* CR_Vector_Allocator::allocate(size_t n) 

if (n <= 1)
throw std::runtime_error("Unexpected number of elements to initialize: " +
std::to_string(n));

T* addr_;
if (free_list.pop(addr_)) return addr_;

addr_ = reinterpret_cast<T*>(std::malloc(n * sizeof(T)));
return addr_;


void CR_Vector_Allocator::deallocate(T* p, size_t n) noexcept
if (n <= 1) // should never happen. but just in case, I don't want to leak
free(p);
else
free_list.push(p);


CR_Vector_Allocator::free_list_type CR_Vector_Allocator::free_list;


It is used in the following manner:



using CR_Vector_t = std::vector<uint16_t, CR_Vector_Allocator>;

CR_Vector_t Generate_CR_Vector()

/* total_parameters is a member of the same class
as this member function and is defined elsewhere */
CR_Vector_t cr_vec (total_parameters);
std::uniform_int_distribution<uint16_t> dist_;

/* urng_ is a member variable of type std::mt19937_64 in the class */
std::generate(cr_vec.begin(), cr_vec.end(), [this, &dist_]()
return dist_(this->urng_););
return cr_vec;


void Prepare_Next_Generation(...)
/*
...
*/
using hpx::parallel::execution::par_unseq;
hpx::parallel::for_loop_n(par_unseq, 0l, pop_size, [this](int64_t idx)
auto crossovers = Generate_CR_Vector();
auto new_parameters = Generate_New_Parameters(/* ... */, std::move(crossovers));




Any feedback, guidance or rebukes would be greatly appreciated.

Thank you!!









share







New contributor




Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$


















    0












    $begingroup$


    Brief Preface



    I recognize that there are many nuances and requirements for a standard-compatible allocator. There are a number of questions here covering a range of topics associated with allocators. I realize that the requirements set out by the standard are critical to ensuring that the allocator functions correctly in all cases, doesn't leak memory, doesn't cause undefined-behaviour, etc. This is particularly true where the allocator is meant to be used (or at least, can be used) in a wide range of use cases, with a variety of underlying types and different standard containers, object sizes, etc.



    In contrast, I have a very specific use case where I personally strictly control all of the conditions associated with its use, as I describe in detail below. Consequently, I believe that what I've done is perfectly acceptable given the highly-specific nature of what I'm trying to implement.



    I'm hoping someone with far more experience and understanding than me can either confirm that the description below is acceptable or point out the problems (and, ideally, how to fix them too).



    Overview / Specific Requirements



    In a nutshell, I'm trying to write an allocator that is to be used within my own code and for a single, specific purpose:



    • I need "a few" std::vector (probably uint16_t), with a fixed (at runtime) number of elements. I'm benchmarking to determine the best tradeoff of performance/space for the exact integer type[1]

    • As noted, the number of elements is always the same, but it depends on some runtime configuration data passed to the application

    • The number of vectors is also either fixed or at least bounded. The exact number is handled by a library providing an implementation of parallel::for(execution::par_unseq, ...)

    • The vectors are constructed by me (i.e. so I know with certainty that they will always be constructed with N elements)

    [1] The value of the vectors are used to conditionally copy a float from one of 2 vectors to a target: c[i] = rand_vec[i] < threshold ? a[i] : b[i] where a, b, c are contiguous arrays of float, rand_vec is the std::vector I'm trying to figure out here, and threshold is a single variable of type integer_tbd. The code compiles as SSE SIMD operations. I do not remember the details of this, but I believe that this requires additional shifting instructions if the ints are smaller than the floats.



    On this basis, I've written a very simple allocator, with a single static boost::lockfree::queue as the free-list. Given that I will construct the vectors myself and they will go out of scope when I'm finished with them, I know with certainty that all calls to alloc::deallocate(T*, size_t) will always return vectors of the same size, so I believe that I can simply push them back onto the queue without worrying about a pointer to a differently-sized allocation being pushed onto the free-list.



    As noted in the code below, I've added in runtime tests for both the allocate and deallocate functions for now, while I've been confirming for myself that these situations cannot and will not occur. Again, I believe it is unquestionably safe to delete these runtime tests. Although some advice would be appreciated here too -- considering the surrounding code, I think they should be handled adequately by the branch predictor so they don't have a significant runtime cost (although without instrumenting, hard to say for 100% certain).



    In a nutshell - as far as I can tell, everything here is completely within my control, completely deterministic in behaviour, and, thus, completely safe. This is also suggested when running the code under typical conditions -- there are no segfaults, etc. I haven't yet tried running with sanitizers yet -- I was hoping to get some feedback and guidance before doing so.



    I should point out that my code runs 2x faster compared to using std::allocator which is at least qualitatively to be expected.



    CR_Vector_Allocator.hpp



    class CR_Vector_Allocator 

    using T = CR_Range_t; // probably uint16_t or uint32_t, set elsewhere.

    private:
    using free_list_type = boost::lockfree::queue>;

    static free_list_type free_list;

    public:
    T* allocate(size_t);
    void deallocate(T* p, size_t) noexcept;

    using value_type = T;
    using pointer = T*;
    using reference = T&;

    template struct rebind using other = CR_Vector_Allocator;;
    ;


    CR_Vector_Allocator.cc



    CR_Vector_Allocator::T* CR_Vector_Allocator::allocate(size_t n) 

    if (n <= 1)
    throw std::runtime_error("Unexpected number of elements to initialize: " +
    std::to_string(n));

    T* addr_;
    if (free_list.pop(addr_)) return addr_;

    addr_ = reinterpret_cast<T*>(std::malloc(n * sizeof(T)));
    return addr_;


    void CR_Vector_Allocator::deallocate(T* p, size_t n) noexcept
    if (n <= 1) // should never happen. but just in case, I don't want to leak
    free(p);
    else
    free_list.push(p);


    CR_Vector_Allocator::free_list_type CR_Vector_Allocator::free_list;


    It is used in the following manner:



    using CR_Vector_t = std::vector<uint16_t, CR_Vector_Allocator>;

    CR_Vector_t Generate_CR_Vector()

    /* total_parameters is a member of the same class
    as this member function and is defined elsewhere */
    CR_Vector_t cr_vec (total_parameters);
    std::uniform_int_distribution<uint16_t> dist_;

    /* urng_ is a member variable of type std::mt19937_64 in the class */
    std::generate(cr_vec.begin(), cr_vec.end(), [this, &dist_]()
    return dist_(this->urng_););
    return cr_vec;


    void Prepare_Next_Generation(...)
    /*
    ...
    */
    using hpx::parallel::execution::par_unseq;
    hpx::parallel::for_loop_n(par_unseq, 0l, pop_size, [this](int64_t idx)
    auto crossovers = Generate_CR_Vector();
    auto new_parameters = Generate_New_Parameters(/* ... */, std::move(crossovers));




    Any feedback, guidance or rebukes would be greatly appreciated.

    Thank you!!









    share







    New contributor




    Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.







    $endgroup$














      0












      0








      0





      $begingroup$


      Brief Preface



      I recognize that there are many nuances and requirements for a standard-compatible allocator. There are a number of questions here covering a range of topics associated with allocators. I realize that the requirements set out by the standard are critical to ensuring that the allocator functions correctly in all cases, doesn't leak memory, doesn't cause undefined-behaviour, etc. This is particularly true where the allocator is meant to be used (or at least, can be used) in a wide range of use cases, with a variety of underlying types and different standard containers, object sizes, etc.



      In contrast, I have a very specific use case where I personally strictly control all of the conditions associated with its use, as I describe in detail below. Consequently, I believe that what I've done is perfectly acceptable given the highly-specific nature of what I'm trying to implement.



      I'm hoping someone with far more experience and understanding than me can either confirm that the description below is acceptable or point out the problems (and, ideally, how to fix them too).



      Overview / Specific Requirements



      In a nutshell, I'm trying to write an allocator that is to be used within my own code and for a single, specific purpose:



      • I need "a few" std::vector (probably uint16_t), with a fixed (at runtime) number of elements. I'm benchmarking to determine the best tradeoff of performance/space for the exact integer type[1]

      • As noted, the number of elements is always the same, but it depends on some runtime configuration data passed to the application

      • The number of vectors is also either fixed or at least bounded. The exact number is handled by a library providing an implementation of parallel::for(execution::par_unseq, ...)

      • The vectors are constructed by me (i.e. so I know with certainty that they will always be constructed with N elements)

      [1] The value of the vectors are used to conditionally copy a float from one of 2 vectors to a target: c[i] = rand_vec[i] < threshold ? a[i] : b[i] where a, b, c are contiguous arrays of float, rand_vec is the std::vector I'm trying to figure out here, and threshold is a single variable of type integer_tbd. The code compiles as SSE SIMD operations. I do not remember the details of this, but I believe that this requires additional shifting instructions if the ints are smaller than the floats.



      On this basis, I've written a very simple allocator, with a single static boost::lockfree::queue as the free-list. Given that I will construct the vectors myself and they will go out of scope when I'm finished with them, I know with certainty that all calls to alloc::deallocate(T*, size_t) will always return vectors of the same size, so I believe that I can simply push them back onto the queue without worrying about a pointer to a differently-sized allocation being pushed onto the free-list.



      As noted in the code below, I've added in runtime tests for both the allocate and deallocate functions for now, while I've been confirming for myself that these situations cannot and will not occur. Again, I believe it is unquestionably safe to delete these runtime tests. Although some advice would be appreciated here too -- considering the surrounding code, I think they should be handled adequately by the branch predictor so they don't have a significant runtime cost (although without instrumenting, hard to say for 100% certain).



      In a nutshell - as far as I can tell, everything here is completely within my control, completely deterministic in behaviour, and, thus, completely safe. This is also suggested when running the code under typical conditions -- there are no segfaults, etc. I haven't yet tried running with sanitizers yet -- I was hoping to get some feedback and guidance before doing so.



      I should point out that my code runs 2x faster compared to using std::allocator which is at least qualitatively to be expected.



      CR_Vector_Allocator.hpp



      class CR_Vector_Allocator 

      using T = CR_Range_t; // probably uint16_t or uint32_t, set elsewhere.

      private:
      using free_list_type = boost::lockfree::queue>;

      static free_list_type free_list;

      public:
      T* allocate(size_t);
      void deallocate(T* p, size_t) noexcept;

      using value_type = T;
      using pointer = T*;
      using reference = T&;

      template struct rebind using other = CR_Vector_Allocator;;
      ;


      CR_Vector_Allocator.cc



      CR_Vector_Allocator::T* CR_Vector_Allocator::allocate(size_t n) 

      if (n <= 1)
      throw std::runtime_error("Unexpected number of elements to initialize: " +
      std::to_string(n));

      T* addr_;
      if (free_list.pop(addr_)) return addr_;

      addr_ = reinterpret_cast<T*>(std::malloc(n * sizeof(T)));
      return addr_;


      void CR_Vector_Allocator::deallocate(T* p, size_t n) noexcept
      if (n <= 1) // should never happen. but just in case, I don't want to leak
      free(p);
      else
      free_list.push(p);


      CR_Vector_Allocator::free_list_type CR_Vector_Allocator::free_list;


      It is used in the following manner:



      using CR_Vector_t = std::vector<uint16_t, CR_Vector_Allocator>;

      CR_Vector_t Generate_CR_Vector()

      /* total_parameters is a member of the same class
      as this member function and is defined elsewhere */
      CR_Vector_t cr_vec (total_parameters);
      std::uniform_int_distribution<uint16_t> dist_;

      /* urng_ is a member variable of type std::mt19937_64 in the class */
      std::generate(cr_vec.begin(), cr_vec.end(), [this, &dist_]()
      return dist_(this->urng_););
      return cr_vec;


      void Prepare_Next_Generation(...)
      /*
      ...
      */
      using hpx::parallel::execution::par_unseq;
      hpx::parallel::for_loop_n(par_unseq, 0l, pop_size, [this](int64_t idx)
      auto crossovers = Generate_CR_Vector();
      auto new_parameters = Generate_New_Parameters(/* ... */, std::move(crossovers));




      Any feedback, guidance or rebukes would be greatly appreciated.

      Thank you!!









      share







      New contributor




      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.







      $endgroup$




      Brief Preface



      I recognize that there are many nuances and requirements for a standard-compatible allocator. There are a number of questions here covering a range of topics associated with allocators. I realize that the requirements set out by the standard are critical to ensuring that the allocator functions correctly in all cases, doesn't leak memory, doesn't cause undefined-behaviour, etc. This is particularly true where the allocator is meant to be used (or at least, can be used) in a wide range of use cases, with a variety of underlying types and different standard containers, object sizes, etc.



      In contrast, I have a very specific use case where I personally strictly control all of the conditions associated with its use, as I describe in detail below. Consequently, I believe that what I've done is perfectly acceptable given the highly-specific nature of what I'm trying to implement.



      I'm hoping someone with far more experience and understanding than me can either confirm that the description below is acceptable or point out the problems (and, ideally, how to fix them too).



      Overview / Specific Requirements



      In a nutshell, I'm trying to write an allocator that is to be used within my own code and for a single, specific purpose:



      • I need "a few" std::vector (probably uint16_t), with a fixed (at runtime) number of elements. I'm benchmarking to determine the best tradeoff of performance/space for the exact integer type[1]

      • As noted, the number of elements is always the same, but it depends on some runtime configuration data passed to the application

      • The number of vectors is also either fixed or at least bounded. The exact number is handled by a library providing an implementation of parallel::for(execution::par_unseq, ...)

      • The vectors are constructed by me (i.e. so I know with certainty that they will always be constructed with N elements)

      [1] The value of the vectors are used to conditionally copy a float from one of 2 vectors to a target: c[i] = rand_vec[i] < threshold ? a[i] : b[i] where a, b, c are contiguous arrays of float, rand_vec is the std::vector I'm trying to figure out here, and threshold is a single variable of type integer_tbd. The code compiles as SSE SIMD operations. I do not remember the details of this, but I believe that this requires additional shifting instructions if the ints are smaller than the floats.



      On this basis, I've written a very simple allocator, with a single static boost::lockfree::queue as the free-list. Given that I will construct the vectors myself and they will go out of scope when I'm finished with them, I know with certainty that all calls to alloc::deallocate(T*, size_t) will always return vectors of the same size, so I believe that I can simply push them back onto the queue without worrying about a pointer to a differently-sized allocation being pushed onto the free-list.



      As noted in the code below, I've added in runtime tests for both the allocate and deallocate functions for now, while I've been confirming for myself that these situations cannot and will not occur. Again, I believe it is unquestionably safe to delete these runtime tests. Although some advice would be appreciated here too -- considering the surrounding code, I think they should be handled adequately by the branch predictor so they don't have a significant runtime cost (although without instrumenting, hard to say for 100% certain).



      In a nutshell - as far as I can tell, everything here is completely within my control, completely deterministic in behaviour, and, thus, completely safe. This is also suggested when running the code under typical conditions -- there are no segfaults, etc. I haven't yet tried running with sanitizers yet -- I was hoping to get some feedback and guidance before doing so.



      I should point out that my code runs 2x faster compared to using std::allocator which is at least qualitatively to be expected.



      CR_Vector_Allocator.hpp



      class CR_Vector_Allocator 

      using T = CR_Range_t; // probably uint16_t or uint32_t, set elsewhere.

      private:
      using free_list_type = boost::lockfree::queue>;

      static free_list_type free_list;

      public:
      T* allocate(size_t);
      void deallocate(T* p, size_t) noexcept;

      using value_type = T;
      using pointer = T*;
      using reference = T&;

      template struct rebind using other = CR_Vector_Allocator;;
      ;


      CR_Vector_Allocator.cc



      CR_Vector_Allocator::T* CR_Vector_Allocator::allocate(size_t n) 

      if (n <= 1)
      throw std::runtime_error("Unexpected number of elements to initialize: " +
      std::to_string(n));

      T* addr_;
      if (free_list.pop(addr_)) return addr_;

      addr_ = reinterpret_cast<T*>(std::malloc(n * sizeof(T)));
      return addr_;


      void CR_Vector_Allocator::deallocate(T* p, size_t n) noexcept
      if (n <= 1) // should never happen. but just in case, I don't want to leak
      free(p);
      else
      free_list.push(p);


      CR_Vector_Allocator::free_list_type CR_Vector_Allocator::free_list;


      It is used in the following manner:



      using CR_Vector_t = std::vector<uint16_t, CR_Vector_Allocator>;

      CR_Vector_t Generate_CR_Vector()

      /* total_parameters is a member of the same class
      as this member function and is defined elsewhere */
      CR_Vector_t cr_vec (total_parameters);
      std::uniform_int_distribution<uint16_t> dist_;

      /* urng_ is a member variable of type std::mt19937_64 in the class */
      std::generate(cr_vec.begin(), cr_vec.end(), [this, &dist_]()
      return dist_(this->urng_););
      return cr_vec;


      void Prepare_Next_Generation(...)
      /*
      ...
      */
      using hpx::parallel::execution::par_unseq;
      hpx::parallel::for_loop_n(par_unseq, 0l, pop_size, [this](int64_t idx)
      auto crossovers = Generate_CR_Vector();
      auto new_parameters = Generate_New_Parameters(/* ... */, std::move(crossovers));




      Any feedback, guidance or rebukes would be greatly appreciated.

      Thank you!!







      c++ memory-management





      share







      New contributor




      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.










      share







      New contributor




      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      share



      share






      New contributor




      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 7 mins ago









      Shmuel LevineShmuel Levine

      101




      101




      New contributor




      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Shmuel Levine is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          0






          active

          oldest

          votes












          Your Answer





          StackExchange.ifUsing("editor", function ()
          return StackExchange.using("mathjaxEditing", function ()
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
          );
          );
          , "mathjax-editing");

          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "196"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );






          Shmuel Levine is a new contributor. Be nice, and check out our Code of Conduct.









          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217172%2fwriting-a-custom-highly-specialized-special-purpose-standard-compliant-c-all%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          0






          active

          oldest

          votes








          0






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          Shmuel Levine is a new contributor. Be nice, and check out our Code of Conduct.









          draft saved

          draft discarded


















          Shmuel Levine is a new contributor. Be nice, and check out our Code of Conduct.












          Shmuel Levine is a new contributor. Be nice, and check out our Code of Conduct.











          Shmuel Levine is a new contributor. Be nice, and check out our Code of Conduct.














          Thanks for contributing an answer to Code Review Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          Use MathJax to format equations. MathJax reference.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f217172%2fwriting-a-custom-highly-specialized-special-purpose-standard-compliant-c-all%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          名間水力發電廠 目录 沿革 設施 鄰近設施 註釋 外部連結 导航菜单23°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.7113923°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.71139計畫概要原始内容臺灣第一座BOT 模式開發的水力發電廠-名間水力電廠名間水力發電廠 水利署首件BOT案原始内容《小檔案》名間電廠 首座BOT水力發電廠原始内容名間電廠BOT - 經濟部水利署中區水資源局

          Prove that NP is closed under karp reduction?Space(n) not closed under Karp reductions - what about NTime(n)?Class P is closed under rotation?Prove or disprove that $NL$ is closed under polynomial many-one reductions$mathbfNC_2$ is closed under log-space reductionOn Karp reductionwhen can I know if a class (complexity) is closed under reduction (cook/karp)Check if class $PSPACE$ is closed under polyonomially space reductionIs NPSPACE also closed under polynomial-time reduction and under log-space reduction?Prove PSPACE is closed under complement?Prove PSPACE is closed under union?

          Is my guitar’s action too high? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Strings too stiff on a recently purchased acoustic guitar | Cort AD880CEIs the action of my guitar really high?Μy little finger is too weak to play guitarWith guitar, how long should I give my fingers to strengthen / callous?When playing a fret the guitar sounds mutedPlaying (Barre) chords up the guitar neckI think my guitar strings are wound too tight and I can't play barre chordsF barre chord on an SG guitarHow to find to the right strings of a barre chord by feel?High action on higher fret on my steel acoustic guitar