- I think Java or C# are not like C++ - 1 Update
- Read again i correct - 2 Updates
- And what about the debate of wich is better Java or C++ ? - 2 Updates
- Factors affecting C++ Compilation time – How to reduce them - 1 Update
- Rick's mother is dead - 1 Update
- Modules - 2 Updates
- linus - 1 Update
| Intelli2 <intelli2@mama.com>: Dec 21 05:51PM -0500 Hello, I think Java or C# are not like C++ or modern Object Pascal of Delphi and FreePascal compilers, because Java and C# wanted to be more high level that avoids more to leaking memory by for example forcing garbage collection and by being more high level by avoiding bugs of pointers and inline assembler, but forcing garbage collection is not optimally efficient and being high level as Java and C# by forbiding inline assembler and pointers is not raking wide or being more general, this is why Java and C# are not the solution for all, and this is why C++ compilers and FreePascal and Delphi compilers are still useful. Thank you, Amine Moulay Ramdane. |
| Intelli2 <intelli2@mama.com>: Dec 21 05:10PM -0500 Hello... And what about the debate of wich is better Java or C++ ? I think what i have learned with C++ compilers and Delphi and FreePascal compilers is that i can do inline assembler with them and this permits me to understand more the hardware and talk to the hardware in Embedded systems etc. this can not be done with Java or C# or the like, also forcing garbage collection in Java and C# is not optimally efficient, please read this to understand it: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Other than that i am working with Delphi and Lazarus because they have there strenght such as being more productive with there RAD tools for developing GUI etc. and FreePascal and Delphi support modern Object Pascal, and even if they lack static type inference, you can compensate for that by using dynamic type inference with variants and RTTI that are supported by modern Object Pascal of Delphi and FreePascal, and they support anonymous methods or Lambdas and i think they support decently generics etc. etc. and they are single-pass compilers that have there advantage because they are much faster than C++ at compiling. I am also working with C++ because it is also good. Thank you, Amine Moulay Ramdane. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 21 02:14PM -0800 On Friday, 22 December 2017 00:11:04 UTC+2, Intelli2 wrote: > Hello... Go away, you can't discuss stuff. We can't help. Sorry. |
| Intelli2 <intelli2@mama.com>: Dec 21 05:02PM -0500 Hello, And what about the debate of wich is better Java or C++ ? I think what i have learned with C++ compilers and Delphi and FreePascal compilers is that i can do inline assembler with them and this permits me to understand more the hardware and talk to the hardware in Embedded systems etc. this can not be done with Java or C# or the like, also forcing garbage collection in Java and C# is not optimally efficient, please read this to understand it: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf Other than that i am working with Delphi and Lazarus because they have there strenght such as being more productive with there RAD tools for developing GUI etc. and FreePascal and Delphi support modern Object Pascal, and even if they lacks static type inference, you can compensate for than by using dynamic type inference with variants and RTTI, and they support anonymous methods or Lambdas and i think they support decently generics etc. etc. and they are single-pass compilers that have there advantage because they are much faster than C++ at compiling. I am also working with C++ because it is also good. Thank you, Amine Moulay Ramdane. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 21 02:13PM -0800 On Friday, 22 December 2017 00:03:11 UTC+2, Intelli2 wrote: > Hello, > And what about the debate of wich is better Java or C++ ? End of world is likely near ... even Amine is trolling. Programming language is a *TOOL* of software engineering. What is better: saw or chisel for wood engineering? |
| Intelli2 <intelli2@mama.com>: Dec 21 03:51PM -0500 Hello, Factors affecting C++ Compilation time – How to reduce them Read more here: https://mikaelsitruk.wordpress.com/2010/08/11/speeding-up-cpp-compilation/ Thank you, Amine Moulay Ramdane. |
| mcheung63@gmail.com: Dec 21 10:14AM -0800 mche...@gmail.com於 2017年12月10日星期日 UTC+8上午3時08分53秒寫道： > god punished his mother, remember this We are so happy she die so early |
| woodbrian77@gmail.com: Dec 20 06:46PM -0800 On Wednesday, December 20, 2017 at 2:21:22 PM UTC-6, Thiago Adams wrote: > You have a public interface with 1 header and 1 source code with > all the combined implementation. > To consume the library you just add these two files. I don't know much about sqlite, but Wikipedia says it's a C library. I'm talking about C++ modules. Brian Ebenezer Enterprises http://webEbenezer.net |
| Thiago Adams <thiago.adams@gmail.com>: Dec 21 03:26AM -0800 > > To consume the library you just add these two files. > I don't know much about sqlite, but Wikipedia says it's a C library. > I'm talking about C++ modules. From: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf "3 The Problems The primary issue we face when trying to scale compilation of C++ libraries and programs to billions of lines of code is how C++ programmers author software components, compose, and consume them." I give just a sample with SQLite to answer "Is that how others are approaching it?". I consider the amalgamation approach, that is used by sqlite and others, a good approach to compose and consume libraries. With this approach we have two files that can be used in a portable way in different platforms. It's not clear for me if modules have the property of being portable. |
| David Brown <david.brown@hesbynett.no>: Dec 21 10:54AM +0100 On 20/12/17 20:35, Thiago Adams wrote: > When you include the module you have something faster than parsing. > To archive this design the module cannot be affect by the external > pre-processor. In some ways it is similar of pre-compiled headers. It has similarities to pre-compiled headers. But pre-compiled headers /are/ affected by the pre-processor - by compiler options, flags, other include files, pre-processor macro definitions, etc. This is why you can't have more than one pre-compiled header included by a translation unit, why it must come first in the list of includes, and why they will fail to be used if you change settings or have extra macro defines. With modules, you are not allowed to have that kind of dependency, thus your application code can import as many modules as it wants, in any order. And modules can also contain implementation code, not just the header code. |
| 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