- Yucky logic with redundancy, suggestions for alternatives? - 1 Update
- linus - 11 Updates
- My Parallel archiver library - 1 Update
- Modules - 1 Update
| legalize+jeeves@mail.xmission.com (Richard): Dec 18 11:26PM [Please do not mail me a copy of your followup] "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code >If one refrains from posting source code with non-ASCII characters just >to support some very few people's archaic newsreader software, then IMHO >that's an impractical set of priorities. FWIW, I know you like to use UTF-8, which is why I assumed that was the reason for the weird formatting I saw. I recognize that my preferred newsreader is ancient and not the best in supporting some features people like to use. I don't expect anyone to adapt to me, but I do find some uses of UTF-8 gratuitous with no value added, simply different. Just like I find your preference to always use trailing return type :). -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Juha Nieminen <nospam@thanks.invalid>: Dec 18 08:40AM > Limit yourself to C with classes > (don't use STL, don't use Exceptions, disable RTTI for performance). Templates can make the code more efficient with less code than the equivalent non-templated version (just compare std::sort with qsort, for instance). Also, C++ has much more to offer in terms of efficiency than C, such as constexpr functions (and anything constexpr, for that matter). |
| Thiago Adams <thiago.adams@gmail.com>: Dec 18 03:53AM -0800 On Saturday, December 16, 2017 at 9:18:45 AM UTC-2, Mr Flibble wrote: > And the reason you snipped "I wouldn't use the default allocator" from > my post you replied to is? > /Flibble I think I answered the older replies before to read the new ones. |
| Thiago Adams <thiago.adams@gmail.com>: Dec 18 04:35AM -0800 On Monday, December 18, 2017 at 6:40:36 AM UTC-2, Juha Nieminen wrote: > Templates can make the code more efficient with less code than the > equivalent non-templated version (just compare std::sort with qsort, > for instance). This is the classic sample repeated many times. I think C programmers understand well the problem and they can remove the pointer callback in a specialized algorithm. Templates are convenient for algorithms and they solved the "container problem" that still exist in C. Templates also opened the door for language libraries that requires type parametrization. > Also, C++ has much more to offer in terms of efficiency than C, > such as constexpr functions (and anything constexpr, for that matter). I don't see constexpr as a feature for efficiency. They are convenient like templates to express in code some computation/code generation that can be done in compilation time. Without constexpr we still can compute things and use the result having the same efficiency. constexpr just make it more integrated. The advantage of constexpr, templates and this integration with the language is more visible when some change in code requires updates in the generated code. For instance, let's say you want a table of primes numbers. This table is not affected by your code changes. In this case you can create an external program and generate your table. If your table is not affect by your code, it also means, that doesn't make sense to generate this table in each build. This is the same for factorial(5). On the other hand, if you are experimenting and changing some params that affects the computation then constexpr offers a convenient way to update the result in a integrated way. Templates also offers a convenient way of instantiation. For instance, lets say you have a code generator that generates a vector<T> for you. In this case, you would probably have some flags to specify the functions you want to instantiate. When you need a function that you didn't generated then you would have to run the generator again. With automatic template instantiation, when you use the template function it will be automatically instantiated and this is very convenient. The only disadvantage I see of this convenience is that it's so simple to generate more instances that programmers can easily forget that the code may be duplicated with small differences. I think modern compilers do a hard job to avoid code bloat. For instance, let's say a container of pointers instantiated for pointer T1 and T2 etc.. The push_back and others have the same code that only differs for T but T doesn't affect the code. In this case the compiler can join the implementation of these instantiated functions. Generated code also offer to programmers an important property. If we can broke a problem in small parts then we have a good way to go. If the parts are not related then this make easy to review and maintaining your code. Sometimes it is difficult to isolate completely on part from other but the bound between parts can have a pre-defined behavior that can be checked or generated by the compiler. This make the programmer free to think each part independently. For instance, class X{ ..} class Y {X x; ..} class Z { Y y; ...} When we add some data member in X the class Z is affected. The constructor of Z is generated again. But we can think in X in a very isolated way and this property is very interesting and powerful. |
| scott@slp53.sl.home (Scott Lurndal): Dec 18 02:08PM >Templates can make the code more efficient with less code than the >equivalent non-templated version (just compare std::sort with qsort, >for instance). And how many operating systems need a sort function? >Also, C++ has much more to offer in terms of efficiency than C, >such as constexpr functions (and anything constexpr, for that matter). I suspect that anything that can be done with constexpr in C++ can also be done in C, if less cleanly, with preprocessor macros. |
| David Brown <david.brown@hesbynett.no>: Dec 18 04:10PM +0100 On 18/12/17 15:08, Scott Lurndal wrote: >> equivalent non-templated version (just compare std::sort with qsort, >> for instance). > And how many operating systems need a sort function? Templates allow many other things, such as neat and convenient strong typing. How many operating systems need that in their code? Any that try to make it as difficult as possible to write incorrect code. >> such as constexpr functions (and anything constexpr, for that matter). > I suspect that anything that can be done with constexpr in C++ can also be > done in C, if less cleanly, with preprocessor macros. No, that is not the case. Even when you allow for immensely ugly pre-processing and fixed limits on things (because macros don't allow recursion or looping), you will not be able to duplicate everything. And the key point of constexpr is that the same code works for compile time and for run time. The C equivalent to C++ constexpr is external code generators and dedicated pre-processors. constsexpr does not eliminate these entirely of course, but it certainly reduces the need for them. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 18 01:26PM -0800 On Monday, 18 December 2017 16:08:48 UTC+2, Scott Lurndal wrote: > >equivalent non-templated version (just compare std::sort with qsort, > >for instance). > And how many operating systems need a sort function? The std::sort/qsort example is not example of sorting but example how templates allow very tight integration of different modules. Templates let us to make language to generate such integration in compile-time Turing-complete manner. > >such as constexpr functions (and anything constexpr, for that matter). > I suspect that anything that can be done with constexpr in C++ can also be > done in C, if less cleanly, with preprocessor macros. The idea of constexpr is to allow ordinary (within certain constraints) variables to be declared as compile-time constants and ordinary (again constraints) functions to be ran compile-time. So it is (second and simpler) feature of C++ that is compile-time Turing-complete. The C preprocessor can be used in quite clever manners but it is not Turing-complete. That has been the gloat of Lisp (that has Turing- complete macros) fans like Paul Graham forever and ever so it can't come as surprise to anyone of us? |
| scott@slp53.sl.home (Scott Lurndal): Dec 18 09:42PM >templates allow very tight integration of different modules. >Templates let us to make language to generate such integration in >compile-time Turing-complete manner. At the expense, potentially of a larger code footprint. A key metric in kernel development. Granted compilers have gotten better since the first template implementations with cfront, e.g. std::min/std::max generate code inline with simple comparision instructions with good optimizing compilers. Templates can be abused, however. |
| legalize+jeeves@mail.xmission.com (Richard): Dec 18 11:04PM [Please do not mail me a copy of your followup] thiago.adams@gmail.com spake the secret code >Generic code can be dangerous when you try to solve problems that you >don't have. Interesting. Can you provide an example? The idea behind generic algorithms is to leverage the expertise of other people as opposed to re-inventing the wheel. I know the real-time/game working group has very speicfic concerns about the standard library, but most of them come from the containers and not the algorithms. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Dec 18 11:07PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >> The ideal code would have only null_ptr and the junior college would >> never ask the difference and the complexity would be hidden. >Clang modernise may take care of that, if I recall correctly. Yes, clang-tidy can upgrade everything to use nullptr. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| David Brown <david.brown@hesbynett.no>: Dec 19 12:18AM +0100 On 18/12/17 22:42, Scott Lurndal wrote: > the first template implementations with cfront, e.g. std::min/std::max > generate code inline with simple comparision instructions with good > optimizing compilers. Templates can be abused, however. Templates can also lead to noticeably smaller code - because it is specialised for the task in hand, rather than a generic function. Newer and better compilers do make a difference - nowadays tools can spot identical functions and merge them, for example, so that foo<int> and foo<unsigned int> don't both take space. And they will merge the same template-generated function across different translation units (unless the functions have been inlined, cloned, etc.). Yes, templates can be abused - but they can also be /used/. |
| legalize+jeeves@mail.xmission.com (Richard): Dec 18 11:25PM [Please do not mail me a copy of your followup] Thiago Adams <thiago.adams@gmail.com> spake the secret code >,for instance, a macro for the equivalent of static assert and a macro >for the equivalent of deleted constructor and operator =. This is >for windows and we don´t have a refactoring tool. clang-tidy is pretty much ubiquitous. On Windows, VS2015 shipped with some limited refactoring support out of the box and they improved/expanded on it in VS2017. Even better is ReSharper for C++ add-on from JetBrains. The JetBrains products (CLion, R++) score highest on passing my refactoring test suite. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Intelli2 <intelli2@mama.com>: Dec 18 03:43PM -0500 Hello, I am posting here because my Parallel archiver library works with C++Builder.. My Parallel archiver library will be ported to Linux and it will work with the FreePascal Linux compiler in Delphi compatible mode and it will work of course with Lazarus for Linux in Delphi compatible mode. It will work on both Windows and Linux and it will be much much more stable and fast. It will take me one or two days to port it to Linux. Also it will take me few more days to implement my new invented fully scalable algorithm of a Threadpool and i will easily use my fully scalable Threadpool inside my Parallel archiver and my Parallel Compression Library, pigz or pbzip or pzstd or others compression programs are not using a scalable method to distribute chunks of memory to the worker threads as my fully scalable Threadpool that i will use. And about adding Delphi to C++Builder, and of course you can add any .pas file of my Delphi Parallel archiver library to a C++ project. (C++Builder has supported adding Pascal files into a C++ project for many years, since at least CB2006.) When you add a Pascal file and build the C++ project, the .pas files are built before any C++ files, and the Delphi compiler auto-generates a C++ header with a .hpp extension. This is exactly the same as the headers for the VCL or FMX! This allows C++ code to refer to Delphi classes and types, completely unaware they are not implemented in C++, and at link time the Delphi code is linked in to C++ code. My Windows version for Delphi and FreePascal of my Parallel archiver was stabilized much much more and it is fast, you can download it from: https://sites.google.com/site/aminer68/parallel-archiver Thank you, Amine Moulay Ramdane. |
| fir <profesor.fir@gmail.com>: Dec 18 10:03AM -0800 > I think I may create a separate github repo for the modules > version of my code. At first the non-modules repo would be > the dominant repo. Is that how others are approaching it? in my world, there is a lot of modules, there are called dlls, (for example msvcrt.dll kernel32.dll bass.dll NxPhysics.dll green.fire.dll ) there is a lot that can be said on those modules as this knowledge related to them is very importnt, you may for example read my post "granular upgrade" on comp.lang.c which is up to that |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment