In C++14 is it valid to use a double in the dimension of a new expression?












41















In C++14 given the following code:



void foo() {

  double d = 5.0;

  auto p1 = new int[d];

}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live in godbolt):



error: expression in new-declarator must have integral or enumeration type

    7 |     auto p1 = new int[d];

      |                       ^


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live in godbolt):



error: array size expression must have integral or unscoped enumeration type, not 'double'

    auto p1 = new int[d];

              ^       ~


Is clang correct? If so what changed in C++14 to allow this?






c++ c++14 language-lawyer new-expression







share|improve this question




















  • 2





    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.

    – Thomas Matthews
    Dec 12 '18 at 15:13








  • 5





    @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float

    – Shafik Yaghmour
    Dec 12 '18 at 15:59






  • 1





    @tomerzeitune Well, that (0.75 -> 0) is not what you wrote (0.75 -> 16360) ;)

    – Bob__
    Dec 13 '18 at 9:50






  • 1





    @tomerzeitune Why int? Why not unsigned or long?

    – curiousguy
    Dec 13 '18 at 22:35






  • 1





    @KeithThompson I think the commenters are joking around

    – Shafik Yaghmour
    Dec 14 '18 at 18:11
















41















In C++14 given the following code:



void foo() {

  double d = 5.0;

  auto p1 = new int[d];

}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live in godbolt):



error: expression in new-declarator must have integral or enumeration type

    7 |     auto p1 = new int[d];

      |                       ^


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live in godbolt):



error: array size expression must have integral or unscoped enumeration type, not 'double'

    auto p1 = new int[d];

              ^       ~


Is clang correct? If so what changed in C++14 to allow this?






c++ c++14 language-lawyer new-expression







share|improve this question




















  • 2





    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.

    – Thomas Matthews
    Dec 12 '18 at 15:13








  • 5





    @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float

    – Shafik Yaghmour
    Dec 12 '18 at 15:59






  • 1





    @tomerzeitune Well, that (0.75 -> 0) is not what you wrote (0.75 -> 16360) ;)

    – Bob__
    Dec 13 '18 at 9:50






  • 1





    @tomerzeitune Why int? Why not unsigned or long?

    – curiousguy
    Dec 13 '18 at 22:35






  • 1





    @KeithThompson I think the commenters are joking around

    – Shafik Yaghmour
    Dec 14 '18 at 18:11














41












41








41


1






In C++14 given the following code:



void foo() {

  double d = 5.0;

  auto p1 = new int[d];

}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live in godbolt):



error: expression in new-declarator must have integral or enumeration type

    7 |     auto p1 = new int[d];

      |                       ^


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live in godbolt):



error: array size expression must have integral or unscoped enumeration type, not 'double'

    auto p1 = new int[d];

              ^       ~


Is clang correct? If so what changed in C++14 to allow this?






c++ c++14 language-lawyer new-expression







share|improve this question
















In C++14 given the following code:



void foo() {

  double d = 5.0;

  auto p1 = new int[d];

}


clang compiles this without diagnostic while gcc on the other hand produces the following diagnostic (see it live in godbolt):



error: expression in new-declarator must have integral or enumeration type

    7 |     auto p1 = new int[d];

      |                       ^


I specifically labeled this C++14 because in C++11 mode clang treats this as ill-formed and produces the following diagnostic (see it live in godbolt):



error: array size expression must have integral or unscoped enumeration type, not 'double'

    auto p1 = new int[d];

              ^       ~


Is clang correct? If so what changed in C++14 to allow this?






c++ c++14 language-lawyer new-expression




c++ c++14 language-lawyer new-expression






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 13 '18 at 21:10







Shafik Yaghmour

















asked Dec 12 '18 at 14:25









Shafik YaghmourShafik Yaghmour

127k23329546




127k23329546








  • 2





    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.

    – Thomas Matthews
    Dec 12 '18 at 15:13








  • 5





    @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float

    – Shafik Yaghmour
    Dec 12 '18 at 15:59






  • 1





    @tomerzeitune Well, that (0.75 -> 0) is not what you wrote (0.75 -> 16360) ;)

    – Bob__
    Dec 13 '18 at 9:50






  • 1





    @tomerzeitune Why int? Why not unsigned or long?

    – curiousguy
    Dec 13 '18 at 22:35






  • 1





    @KeithThompson I think the commenters are joking around

    – Shafik Yaghmour
    Dec 14 '18 at 18:11














  • 2





    Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.

    – Thomas Matthews
    Dec 12 '18 at 15:13








  • 5





    @ThomasMatthews no this would end up being a float to integral conversion and would truncate the float

    – Shafik Yaghmour
    Dec 12 '18 at 15:59






  • 1





    @tomerzeitune Well, that (0.75 -> 0) is not what you wrote (0.75 -> 16360) ;)

    – Bob__
    Dec 13 '18 at 9:50






  • 1





    @tomerzeitune Why int? Why not unsigned or long?

    – curiousguy
    Dec 13 '18 at 22:35






  • 1





    @KeithThompson I think the commenters are joking around

    – Shafik Yaghmour
    Dec 14 '18 at 18:11








2




2





Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.

– Thomas Matthews
Dec 12 '18 at 15:13







Out of curiosity, a double allows for fractional quantities, so how would you allocate 0.75 of an integer, such as int * p_array = new int [0.75];? Or take something like 0.33333333, which is kind of difficult to allocate.

– Thomas Matthews
Dec 12 '18 at 15:13






5




5





@ThomasMatthews no this would end up being a float to integral conversion and would truncate the float

– Shafik Yaghmour
Dec 12 '18 at 15:59





@ThomasMatthews no this would end up being a float to integral conversion and would truncate the float

– Shafik Yaghmour
Dec 12 '18 at 15:59




1




1





@tomerzeitune Well, that (0.75 -> 0) is not what you wrote (0.75 -> 16360) ;)

– Bob__
Dec 13 '18 at 9:50





@tomerzeitune Well, that (0.75 -> 0) is not what you wrote (0.75 -> 16360) ;)

– Bob__
Dec 13 '18 at 9:50




1




1





@tomerzeitune Why int? Why not unsigned or long?

– curiousguy
Dec 13 '18 at 22:35





@tomerzeitune Why int? Why not unsigned or long?

– curiousguy
Dec 13 '18 at 22:35




1




1





@KeithThompson I think the commenters are joking around

– Shafik Yaghmour
Dec 14 '18 at 18:11





@KeithThompson I think the commenters are joking around

– Shafik Yaghmour
Dec 14 '18 at 18:11












2 Answers
2






active

oldest

votes


















43














Clang is correct, the key wording in [expr.new]p6 changes from the following in the C++11 draft:




Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




to this in the C++14 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. …




In C++14 the requirement for the expression in a noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



The change in wording came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






share|improve this answer





















  • 19





    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

    – Matthieu M.
    Dec 12 '18 at 15:48






  • 12





    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

    – Shafik Yaghmour
    Dec 12 '18 at 15:57








  • 2





    @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

    – Shafik Yaghmour
    Dec 14 '18 at 17:56



















1














From c++14 to c++17 (for the ones that wonder like me), the phrasing remains practically the same (unlike from C++11 to C++14 as @ShafikYaghmour answered), as stated in this C++17 draft:




Every constant-expression in a noptr-new-declarator shall be a converted constant expression of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. [..]




with only this part ([expr.const]) missing from the C++17 draft.






share|improve this answer


























    Your Answer






    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: "1"
    };
    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: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    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
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53745158%2fin-c14-is-it-valid-to-use-a-double-in-the-dimension-of-a-new-expression%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    43














    Clang is correct, the key wording in [expr.new]p6 changes from the following in the C++11 draft:




    Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




    to this in the C++14 draft:




    Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. …




    In C++14 the requirement for the expression in a noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
    single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



    The change in wording came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






    share|improve this answer





















    • 19





      I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

      – Matthieu M.
      Dec 12 '18 at 15:48






    • 12





      @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

      – Shafik Yaghmour
      Dec 12 '18 at 15:57








    • 2





      @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

      – Shafik Yaghmour
      Dec 14 '18 at 17:56
















    43














    Clang is correct, the key wording in [expr.new]p6 changes from the following in the C++11 draft:




    Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




    to this in the C++14 draft:




    Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. …




    In C++14 the requirement for the expression in a noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
    single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



    The change in wording came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






    share|improve this answer





















    • 19





      I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

      – Matthieu M.
      Dec 12 '18 at 15:48






    • 12





      @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

      – Shafik Yaghmour
      Dec 12 '18 at 15:57








    • 2





      @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

      – Shafik Yaghmour
      Dec 14 '18 at 17:56














    43












    43








    43







    Clang is correct, the key wording in [expr.new]p6 changes from the following in the C++11 draft:




    Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




    to this in the C++14 draft:




    Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. …




    In C++14 the requirement for the expression in a noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
    single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



    The change in wording came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.






    share|improve this answer















    Clang is correct, the key wording in [expr.new]p6 changes from the following in the C++11 draft:




    Every constant-expression in a noptr-new-declarator shall be an integral constant expression ([expr.const]) and evaluate to a strictly positive value. The expression in a noptr-new-declarator shall be of integral type, unscoped enumeration type, or a class type for which a single non-explicit conversion function to integral or unscoped enumeration type exists ([class.conv]). If the expression is of class type, the expression is converted by calling that conversion function, and the result of the conversion is used in place of the original expression. …




    to this in the C++14 draft:




    Every constant-expression in a noptr-new-declarator shall be a converted constant expression ([expr.const]) of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. …




    In C++14 the requirement for the expression in a noptr-new-declarator was weakened to not require an integral, unscoped enumeration or a class with a
    single non-explicit conversion function to one of those types but just allow implicit conversions to size_t.



    The change in wording came from the proposal A Proposal to Tweak Certain C++ Contextual Conversions, v3.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Dec 15 '18 at 15:00

























    answered Dec 12 '18 at 14:25









    Shafik YaghmourShafik Yaghmour

    127k23329546




    127k23329546








    • 19





      I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

      – Matthieu M.
      Dec 12 '18 at 15:48






    • 12





      @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

      – Shafik Yaghmour
      Dec 12 '18 at 15:57








    • 2





      @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

      – Shafik Yaghmour
      Dec 14 '18 at 17:56














    • 19





      I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

      – Matthieu M.
      Dec 12 '18 at 15:48






    • 12





      @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

      – Shafik Yaghmour
      Dec 12 '18 at 15:57








    • 2





      @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

      – Shafik Yaghmour
      Dec 14 '18 at 17:56








    19




    19





    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

    – Matthieu M.
    Dec 12 '18 at 15:48





    I am dubious about the usefulness of allowing double to be used as the size of an array... it seems more likely to let bugs pass silently than anything else :(

    – Matthieu M.
    Dec 12 '18 at 15:48




    12




    12





    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

    – Shafik Yaghmour
    Dec 12 '18 at 15:57







    @MatthieuM. I agree, I believe it is a defect and that the intent was really to say contextually implicitly converted. I am filing a defect report on this hopefully today but who knows maybe I am wrong :-(

    – Shafik Yaghmour
    Dec 12 '18 at 15:57






    2




    2





    @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

    – Shafik Yaghmour
    Dec 14 '18 at 17:56





    @MatthieuM. FYI I filed a defect report, processing takes a while so I don't expect to have an update anytime soon though.

    – Shafik Yaghmour
    Dec 14 '18 at 17:56













    1














    From c++14 to c++17 (for the ones that wonder like me), the phrasing remains practically the same (unlike from C++11 to C++14 as @ShafikYaghmour answered), as stated in this C++17 draft:




    Every constant-expression in a noptr-new-declarator shall be a converted constant expression of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. [..]




    with only this part ([expr.const]) missing from the C++17 draft.






    share|improve this answer






























      1














      From c++14 to c++17 (for the ones that wonder like me), the phrasing remains practically the same (unlike from C++11 to C++14 as @ShafikYaghmour answered), as stated in this C++17 draft:




      Every constant-expression in a noptr-new-declarator shall be a converted constant expression of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. [..]




      with only this part ([expr.const]) missing from the C++17 draft.






      share|improve this answer




























        1












        1








        1







        From c++14 to c++17 (for the ones that wonder like me), the phrasing remains practically the same (unlike from C++11 to C++14 as @ShafikYaghmour answered), as stated in this C++17 draft:




        Every constant-expression in a noptr-new-declarator shall be a converted constant expression of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. [..]




        with only this part ([expr.const]) missing from the C++17 draft.






        share|improve this answer















        From c++14 to c++17 (for the ones that wonder like me), the phrasing remains practically the same (unlike from C++11 to C++14 as @ShafikYaghmour answered), as stated in this C++17 draft:




        Every constant-expression in a noptr-new-declarator shall be a converted constant expression of type std::size_t and shall evaluate to a strictly positive value. The expression in a noptr-new-declarator is implicitly converted to std::size_t. [..]




        with only this part ([expr.const]) missing from the C++17 draft.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Jan 10 at 8:42









        Bakudan

        14k84266




        14k84266










        answered Dec 14 '18 at 14:34









        gsamarasgsamaras

        52.3k25107193




        52.3k25107193






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • 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.


            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%2fstackoverflow.com%2fquestions%2f53745158%2fin-c14-is-it-valid-to-use-a-double-in-the-dimension-of-a-new-expression%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

            How to change which sound is reproduced for terminal bell?

            Image
            3 Recently upgrade to 18.10 from 18.04, and using the terminal is becoming annoying: the new alert sound is a drip ( /usr/share/sounds/gnome/default/alerts/drip.ogg ), and the previous one is still located at ( /usr/share/sounds/ubuntu/stereo/bell.ogg ). My issue is that at the gnome-terminal, when autocompleting or pressing left BOTH sounds are reproduced, at the same time. I want to just have ubuntu/stereo/bell.ogg active, not both . At the moment I have been only able to reduce the volume of the alerts (but still both are played), or turn the alerts down (but I dislike both "solutions"). gnome-terminal 18.10 teminal-bell share | improve this question
            Read more

            Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

            Image
            up vote 5 down vote favorite 2 I would like to make it so that the vertical space below the title of each chapter is the same when using the Bjornstrup package (i.e. so that the descenders do not affect the spacing - as shown by the red arrow in the picture below). I think I'm fairly happy with the spacing around "A chapter", so I'd really like titles without descenders (e.g. "Contents") to have the same vertical spacing as "A chapter" below the title. I would also like to remove the large "0" in the contents title. Any help appreciated, as always. documentclass[11pt,a4paper]{book} % Packages[![enter image description here][1]][1] usepackage[left=3.5cm, right=3.5cm, top=4.3cm, bottom=4.25cm]{geometry} usepackage[utf8]{inputenc} usepackage{libertine} usepackage[libertine]{newtx
            Read more

            Can I use Tabulator js library in my java Spring + Thymeleaf project?

            Image
            0 I want to add Tabulator js to my java project. I added tabulator.min.js, tabulator.min.css to resources folder. After that added to my html page these dependencies as recommending in readme.md. <link rel="stylesheet" th:href="@{/css/tabulator.min.css}"> <script type="text/javascript" th:src="@{/js/tabulator.min.js}"></script> Now my tables view all elements, that I have in the html page, but not correct. In the documentation of Tabulator is example how to create header and table, var table = new Tabulator("#example-table", { columns:[ {title:"Name", field:"name", sorter:"string", width:200, editor:true}, {title:"Age", field:"age", sorter:"
            Read more