Saturday, February 28, 2015

Digest for comp.lang.c++@googlegroups.com - 7 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Feb 26 08:11AM

> is only 1.5 times difference of storage. Things run typically
> sufficiently fast so I can rarely convince shareholders of maintenance
> that supposedly improves performance by less than 2 times.
 
If the tight inner loop of your dictionary search consists of
character comparisons, and you are performing millions of such
comparisons (as is very easily the case with eg. puzzle solvers),
UTF-16/UCS-2 vs. UTF-8 makes a significant difference.
 
It also makes the code simpler and shorter.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
JiiPee <no@notvalid.com>: Feb 26 08:34AM

On 24/02/2015 08:39, Juha Nieminen wrote:
 
> UTF-8 would be horrible in terms of speed for this, while UTF-16
> would be quite optimal.
 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
both are variable byte strings. You mean its faster because it contains
less bytes on average than UTF-8? Thats why its faster? Or because the
encoding rules are faster?
Martijn Lievaart <m@rtij.nl.invlalid>: Feb 26 10:56AM +0100

On Thu, 26 Feb 2015 08:34:19 +0000, JiiPee wrote:
 
 
> both are variable byte strings. You mean its faster because it contains
> less bytes on average than UTF-8? Thats why its faster? Or because the
> encoding rules are faster?
 
Assuming he ment UCS2 where he said UTF-16, I would guess because
indexing is faster. In applications like the puzzle solver above, that
would be the bottleneck.
 
 
M4
Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 25 10:40PM

Ramine <ramine@1.1> writes:
<snip>
 
> for (i = 0; i < 7; i++)
 
> So as you have noticed there is an "i++" that we must add in C and
> C++, so Object Pascal is more beautiful and easier here...
 
What does this loop look like in Object Pascal:
 
for (auto i : { 2, 3, 5, 7, 11, 13, 17 }) f(i);
 
In C++, if you decide you need to generate these numbers and do other
calculation on the collection you can write
 
for (auto i : some_primes) f(i);
 
with some_primes declared in all sort of ways depending on what you need
to do with them:
 
std::set<int> some_primes = { 2, 3, 5, 7, 11, 13, 17 };
std::vector<int> some_primes = { 2, 3, 5, 7, 11, 13, 17 };
std::list<int> some_primes = { 2, 3, 5, 7, 11, 13, 17 };
int some_primes[] = { 2, 3, 5, 7, 11, 13, 17 };
 
without any change to the loop.
 
<snip>
--
Ben.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 26 01:02AM

On 26/02/2015 02:05, Ramine wrote:
> noticed the Object Pascal of the Delphi and FreePascal are powerful,
> they can support generics, and they even support also Lambda expressions
> to express more your program in a functional manner ...
 
You didn't answer his question. Again: what do those C++ loops look like
in Object Pascal? I bet the answer isn't pretty mate.
 
/Flibble
bleachbot <bleachbot@httrack.com>: Feb 26 12:05AM +0100

bleachbot <bleachbot@httrack.com>: Feb 26 12:34AM +0100

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.
Posted by at No comments:

Fwd: People Who Have Mastered The Art of Snow



Sent from my iPad

Begin forwarded message:

From: "Pat Shumard" <pshumard@cox.net>
Date: February 28, 2015 at 1:07:22 PM CST
To: "Andrea weed" <awsimmental@gmail.com>, "Bridget" <bj3672@yahoo.com>, "Carrie Herzberg" <bherzberg@cox.net>, "Gladys Schupbach" <sissy-gms@live.com>, "J D" <jack_icthospitality@hotmail.com>, "Janet" <dawgbob@sbcglobal.net>, "jlshumard" <jlshumard@cox.net>, "Joseph Walker" <jwalker38134@msn.com>, "Joyce" <jbowers4@kc.rr.com>, "Mary Jane" <lmeyer004@centurytel.net>, "MIKE" <mlmcarthur@yahoo.com>, "Pat A" <headbookworm@yahoo.com>, "Richard Drown" <rdrown@cox.net>, "Robert McArthur" <rsm0761@cox.net>, "Ron" <rtriper@hughes.net>, "sharon norton" <norton3608@yahoo.com>, "susan Cooper" <slcooper123@hotmail.com>, "tien" <tsoongtotherim@aol.com>, "Tracie Shumard" <mypeanut1218@yahoo.com>
Subject: Fw: People Who Have Mastered The Art of Snow

 
 
Sent: Saturday, February 28, 2015 9:36 AM
Subject: People Who Have Mastered The Art of Snow
 
 
 
Snow and creativity go along way to enabling us to staying sane. The people in Boston need this kind of creative relief.

 

 

 

 

 

 



This email has been checked for viruses by Avast antivirus software.
www.avast.com


Posted by at No comments:

Digest for comp.programming.threads@googlegroups.com - 6 updates in 2 topics

bleachbot <bleachbot@httrack.com>: Feb 27 10:31PM +0100

bleachbot <bleachbot@httrack.com>: Feb 27 10:44PM +0100

bleachbot <bleachbot@httrack.com>: Feb 27 10:57PM +0100

Ramine <ramine@1.1>: Feb 27 04:31PM -0800

Hello,
 
 
In this post i am going to speak about an important subject...
 
There are a number of factors that have influenced the adoption of
high-order functions in languages like Java, C++ and Delphi. One of the
important factor is the proliferation of multi-core processors and,
with that, the desire for more parallel and concurrent processing.
 
The map/filter/reduce style of functional programming is very friendly
to parallelization, allowing the programmer to easily make use of
multiple cores, without writing any explicit threading code.
 
Functions, plus a map/filter/reduce programming pattern, and
immutability are the core of functional programming. Together these
things make for powerful tools of parallel and concurrent programming.
 
Also one of the very important things of functional programming
is immutability and composability in the presence of concurrency,
and i have just read the following webpage about "The Functional
Revolution in C++", here it is:
 
http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
 
But i have noticed that this guy called "Bartosz Milewski" is
saying that the functional programming revolution is unvoidable,
but i don't agree with him, because from experience i have
come to conclusion that in most of the projects aroun the world the
parallel part`s quantity of there source code is much smaller than the
serial part`s quantity of there source code, an i really think that this
fact will not change, so from this fact i have come to the conclusion
that the functinal programming revolution will not bring much to the
imperative languages when it comes to concurrency, because
since on most programming projects the parallel part`s
quantity of the source code is much smaller than the serial part`s
quantity of the source code, so applying the higher level abstractions
of functoinal programming to them will not bring much improvement to
maintenability, expressiveness or costs or time or competitivity or
quality of programming in general of the products.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Feb 27 04:44PM -0800

Hello,
 
I will add this:
 
If you read this again:
 
http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
 
You will notice that "Bartosz Milewski" is saying that object oriented
programming is not composable in presence of concurrency... but i think
he is not correct... because what you can do is write near the
property's interface(and don't forget to use set and get) and the
methods that they are thread-safe, so when you you will inherit from the
parent class, you will just read near the interface of the parent's
class wich one is thread-safe and you will take that into account when
you will compose by ineritance, and i think that this is easy to do
and that it's efficient and no need for functional programming.
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Feb 27 04:57PM -0800

Hello..
 
 
In this post i am going to speak about an important subject...
 
There are a number of factors that have influenced the adoption of
high-order functions in languages like Java, C++ and Delphi. One of the
important factor is the proliferation of multi-core processors and,
with that, the desire for more parallel and concurrent processing.
 
The map/filter/reduce style of functional programming is very friendly
to parallelization, allowing the programmer to easily make use of
multiple cores, without writing any explicit threading code.
 
Functions, plus a map/filter/reduce programming pattern, and
immutability are the core of functional programming. Together these
things make for powerful tools of parallel and concurrent programming.
 
Also one of the very important things of functional programming
is immutability and composability in the presence of concurrency,
and i have just read the following webpage about "The Functional
Revolution in C++", here it is:
 
http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
 
But i have noticed that this guy called "Bartosz Milewski" is
saying that the functional programming revolution is unvoidable,
but i don't agree with him, because from experience i have
come to conclusion that in most of the projects aroun the world the
parallel part`s quantity of there source code is much smaller than the
serial part`s quantity of there source code, an i really think that this
fact will not change, so from this fact i have come to the conclusion
that the functinal programming revolution will not bring much to the
imperative languages when it comes to concurrency, because
since on most programming projects the parallel part`s
quantity of the source code is much smaller than the serial part`s
quantity of the source code, so applying the higher level abstractions
of functoinal programming to them will not bring much improvement to
maintainability, expressiveness or costs or time or competitivity or
quality of programming in general of the products.
 
I will add this:
 
 
You will notice that "Bartosz Milewski" is saying that object oriented
programming is not composable in presence of concurrency... but i think
he is not correct... because what you can do is write near the
property's interface(and don't forget to use set and get) and the
methods that they are thread-safe, so when you you will inherit from the
parent class, you will just read near the interface of the parent's
class wich one is thread-safe and you will take that into account when
you will compose by ineritance, and i think that this is easy to do
and that it's efficient and no need for functional programming.
 
 
 
Thank you,
Amine Moulay Ramdane.
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:

Friday, February 27, 2015

Digest for comp.lang.c++@googlegroups.com - 8 updates in 4 topics

Ramine <ramine@1.1>: Feb 27 04:31PM -0800

Hello,
 
 
In this post i am going to speak about an important subject...
 
There are a number of factors that have influenced the adoption of
high-order functions in languages like Java, C++ and Delphi. One of the
important factor is the proliferation of multi-core processors and,
with that, the desire for more parallel and concurrent processing.
 
The map/filter/reduce style of functional programming is very friendly
to parallelization, allowing the programmer to easily make use of
multiple cores, without writing any explicit threading code.
 
Functions, plus a map/filter/reduce programming pattern, and
immutability are the core of functional programming. Together these
things make for powerful tools of parallel and concurrent programming.
 
Also one of the very important things of functional programming
is immutability and composability in the presence of concurrency,
and i have just read the following webpage about "The Functional
Revolution in C++", here it is:
 
http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
 
But i have noticed that this guy called "Bartosz Milewski" is
saying that the functional programming revolution is unvoidable,
but i don't agree with him, because from experience i have
come to conclusion that in most of the projects aroun the world the
parallel part`s quantity of there source code is much smaller than the
serial part`s quantity of there source code, an i really think that this
fact will not change, so from this fact i have come to the conclusion
that the functinal programming revolution will not bring much to the
imperative languages when it comes to concurrency, because
since on most programming projects the parallel part`s
quantity of the source code is much smaller than the serial part`s
quantity of the source code, so applying the higher level abstractions
of functoinal programming to them will not bring much improvement to
maintenability, expressiveness or costs or time or competitivity or
quality of programming in general of the products.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Feb 27 04:45PM -0800

Hello,
 
I will add this:
 
If you read this again:
 
http://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/
 
 
You will notice that "Bartosz Milewski" is saying that object oriented
programming is not composable in presence of concurrency... but i think
he is not correct... because what you can do is write near the
property's interface(and don't forget to use set and get) and the
methods that they are thread-safe, so when you you will inherit from the
parent class, you will just read near the interface of the parent's
class wich one is thread-safe and you will take that into account when
you will compose by ineritance, and i think that this is easy to do
and that it's efficient and no need for functional programming.
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Christopher Pisz <nospam@notanaddress.com>: Feb 27 04:09PM -0600

On 2/27/2015 6:31 PM, Ramine wrote:
> quality of programming in general of the products.
 
> Thank you,
> Amine Moulay Ramdane.
 
 
What was your question on C++?
 
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
bleachbot <bleachbot@httrack.com>: Feb 27 10:31PM +0100

bleachbot <bleachbot@httrack.com>: Feb 27 10:44PM +0100

Vir Campestris <vir.campestris@invalid.invalid>: Feb 27 08:11PM

On 12/02/2015 08:57, Luca Risolia wrote:
 
>> I think Android is a pretty important market too. The trouble is there
>> are a variety of CPUs, so you really need to stick to Java.
 
> It's a well known fact that C++ is more portable than Java.
 
(1) references?
 
(2) Not at the binary level.
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Feb 26 11:40PM

[Please do not mail me a copy of your followup]
 
no@notvalid.com spake the secret code
>> The choice as you've described it is a false one. It isn't a choice
>> between fast and quality.
 
>But surely quality and time are correlated, right?
 
Schedule/time here refers to the idea of a fixed delivery date, i.e. we
must ship this game in time for Christmas, not the time required to
develop a feature.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Feb 26 11:42PM

[Please do not mail me a copy of your followup]
 
Bo Persson <bop@gmb.dk> spake the secret code
 
>A problem is that if you tell the truth up front, you will hardly ever
>get any checks.
 
>That's worse than being caught with "bad predictions".
 
Both of these are symptomatic of an environment with a low trust
dynamic. This is something that comes up constantly in discussions of
agile development.
 
The bottom line is that without trust, people will fall back into
gaming the system in one way or another. Both of the dysfunctional
behaviors described above ("punished for telling the truth" and "lying
to secure approval") are results of a low trust environment.
 
In an environment where trust is prevalent, neither of these kinds of
dysfunctions occurs.
 
How do you gain trust? There is no silver bullet for this because it
is a problem of human relations and not one of technology.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
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.
Posted by at No comments:

Fwd: 真相



Sent from my iPad

Begin forwarded message:

From: Li Li <lilinola@yahoo.com>
Date: February 27, 2015 at 6:19:10 AM CST
To: Tina Soong <tinasoong@att.net>, Irene Wang <yutsuyi@gmail.com>
Subject: 真相

Posted by at No comments:

Thursday, February 26, 2015

Fwd: It's a Beautiful World



Sent from my iPad

Begin forwarded message:

From: Jensie Tou <pandjtou@aol.com>
Date: February 24, 2015 at 11:42:15 AM CST
To: Nancy Chao <nancyhychao@yahoo.com>, Dolores Kuo <doloresmkuo@gmail.com>, Tina Soong <tinasoong@att.net>, Mingmei Wu <mingmei.wu3@gmail.com>
Subject: Fwd: It's a Beautiful World





It's a beautiful World!




Posted by at No comments:

Fwd: Stayin Alive



Sent from my iPad

Begin forwarded message:

From: Tina Soong <tsoongtotherim@aol.com>
Date: February 25, 2015 at 5:57:07 PM CST
To: Tina Soong <tinasoong@att.net>
Subject: Fwd: Stayin Alive



Sent from my iPad

Begin forwarded message:

From: "Pat Shumard" <pshumard@cox.net>
Date: February 25, 2015 at 5:22:57 PM CST
To: "Andrea weed" <awsimmental@gmail.com>, "Bridget" <bj3672@yahoo.com>, "Carrie Herzberg" <bherzberg@cox.net>, "Gladys Schupbach" <sissy-gms@live.com>, "Janet" <dawgbob@sbcglobal.net>, "Joseph Walker" <jwalker38134@msn.com>, "Joyce" <jbowers4@kc.rr.com>, "Karla Lytle" <karlakl@aol.com>, "Mary Jane" <lmeyer004@centurytel.net>, "MIKE" <mlmcarthur@yahoo.com>, "Pat A" <headbookworm@yahoo.com>, "Richard Drown" <rdrown@cox.net>, "Robert McArthur" <rsm0761@cox.net>, "sharon norton" <norton3608@yahoo.com>, "susan Cooper" <slcooper123@hotmail.com>, "tien" <tsoongtotherim@aol.com>, "Tracie Shumard" <mypeanut1218@yahoo.com>
Subject: Fw: Stayin Alive

 
 
From: Ron
Sent: Wednesday, February 25, 2015 5:36 AM
Subject: Stayin Alive
 

Aunt Patsy,

 

Can the woman dance or what?

And some great editing!!!!

Hope you enjoy it as much as I did……

 

 

https://www.youtube.com/watch?v=mz3CPzdCDws

 

Love Ron



This email has been checked for viruses by Avast antivirus software.
www.avast.com


Posted by at No comments:

Digest for comp.lang.c++@googlegroups.com - 6 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Feb 26 08:11AM

> is only 1.5 times difference of storage. Things run typically
> sufficiently fast so I can rarely convince shareholders of maintenance
> that supposedly improves performance by less than 2 times.
 
If the tight inner loop of your dictionary search consists of
character comparisons, and you are performing millions of such
comparisons (as is very easily the case with eg. puzzle solvers),
UTF-16/UCS-2 vs. UTF-8 makes a significant difference.
 
It also makes the code simpler and shorter.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
JiiPee <no@notvalid.com>: Feb 26 08:34AM

On 24/02/2015 08:39, Juha Nieminen wrote:
 
> UTF-8 would be horrible in terms of speed for this, while UTF-16
> would be quite optimal.
 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
both are variable byte strings. You mean its faster because it contains
less bytes on average than UTF-8? Thats why its faster? Or because the
encoding rules are faster?
Martijn Lievaart <m@rtij.nl.invlalid>: Feb 26 10:56AM +0100

On Thu, 26 Feb 2015 08:34:19 +0000, JiiPee wrote:
 
 
> both are variable byte strings. You mean its faster because it contains
> less bytes on average than UTF-8? Thats why its faster? Or because the
> encoding rules are faster?
 
Assuming he ment UCS2 where he said UTF-16, I would guess because
indexing is faster. In applications like the puzzle solver above, that
would be the bottleneck.
 
 
M4
Ramine <ramine@1.1>: Feb 25 06:34PM -0800

On 2/25/2015 2:40 PM, Ben Bacarisse wrote:
> int some_primes[] = { 2, 3, 5, 7, 11, 13, 17 };
 
> without any change to the loop.
 
> <snip>
 
Sorry for my english, i will correct some typos, please read again...
 
 
Hello Ben Becarisse,
 
 
Generics are supported by Object Pascal of Delphi and FreePascal
compilers, and what you are doing above with C++ is creating objects of
classes that support generics, so you are passing <int>, that means you
are creating objects that has there elements of type "int"...
generics are also supported by Object Pascal of Delphi and FreePascal
compilers, so what you can do with Delphi and FreePascal is create
objects of datastructures that support generics, in Delphi and
FreePascal we have for example the TList datastructure that supports
generics..
 
So we create an Object of TList datastructure using generics as follow
in Object Pascal of the Delphi and FreePascal compilers:
 
var
Item: Integer;
[1] List: TList<Integer>;
 
....
[2] for Item in List do
Writeln(Item);
 
 
As in C++, in the Object Pascal code above, notice that in [1] we are
creating an object of class Tlist that supports generics, and in [2],
like in C++, we are using the "for" loop to go through
the elements of the Tlist, this will work with the Object Pascal of the
Delphi and FreePascal compilers.. and you can easily find libraries of
Object Pascal in internet that support classes that support generics
and you can do the same as you are doing with C++...so as you have
noticed, the Object Pascal of the Delphi and FreePascal are powerful,
they can support generics, and they even support also Lambda expressions
to express more your program in a functional manner ...
 
 
 
Thank you,
Amine Moulay Ramdane.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 26 01:02AM

On 26/02/2015 02:05, Ramine wrote:
> noticed the Object Pascal of the Delphi and FreePascal are powerful,
> they can support generics, and they even support also Lambda expressions
> to express more your program in a functional manner ...
 
You didn't answer his question. Again: what do those C++ loops look like
in Object Pascal? I bet the answer isn't pretty mate.
 
/Flibble
bleachbot <bleachbot@httrack.com>: Feb 26 12:34AM +0100

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.
Posted by at No comments:

Digest for comp.programming.threads@googlegroups.com - 19 updates in 7 topics

homer500@gmail.com: Feb 25 04:37PM -0800

This is a test.
Ramine <ramine@1.1>: Feb 25 04:37PM -0800

Hello,
 
I have tried to look at the C++ language and compare it to
Object Pascal, because i am also a Delphi and FreePascal develloper
that is using Object Pascal(i mean object pascal that is more powerful,
not pascal), so i have tried to look at the syntax of C++ patiently
to feel more what is C++ and C , and i have come to the follwing conclusion:
 
If you look at the "for" statement:
 
In Object Pascal we write this:
 
for i := 0 to 6 do
 
But in C and C++ we write this:
 
for (i = 0; i < 7; i++)
 
So as you have noticed there is an "i++" that we must add in C and C++,
so Object Pascal is more beautiful and easier here...
 
 
Other than that there is also the "case" statement:
 
In Object Pascal we write this:
 
case n of
0: str := 'alpha';
1: str := 'beta';
2: str := 'gamma';
else
str := 'invalid';
end; // case
 
 
but in C and C++ we write this:
 
switch (n)
{
case 0 : str = "alpha";
break;
case 1 : str = "beta";
break;
case 2 : str = "gamma";
break;
default: str = "invalid";
} // switch
 
 
So notice with me that in C++ and C you have to write
the "switch" word and you have to write all over again many times
the "case" word, but in Object pascal you write only one time
the "case" word, so Object Pascal is beautiful and easier here...
 
 
Other than that i was amazed to not find in C and C++ the data type that
we call "sets" in Object Pascal...
 
For example in Object Pascal we can do this with the "sets" type:
 
type
col_t = (red, blu, grn); // enum.
MySetType := set of col_t;
var
a, b, c : MySetType;
begin
a := []; // empty set
a := a + [red]; // union
b := a - [blu]; // difference
c := a * b; // intersection
if [red] in a then ...
(* Note that sets are generally used to handle non-exclusive flags in
Object Pascal. *)
 
 
But in C and C++ there is no equivalent type of the "sets" of Object
Pascal, so Object Pascal is beautiful and simple easier here again...
 
 
Also in Object Pascal, i have noticed that it's much easier to work with
strings than in C and C++... so Object pascal is more beautiful and
easier here also...
 
 
Also i have noticed that it's much easier to create a dynamic link
library(so or dll) with Delphi or FreePascal than with C++ or C compilers...
 
I think also that i don't need to speak about the macros in C++ or C,
because macros can become easily "cryptic" in C++ or C and that's bad...
 
 
And i have noticed that it's much easier to work with dynamic arrays
with Object Pascal than with C++ or C.
 
So i think i will not continu this comparison between Object Pascal
an C++ and C, because i think C++ and C are a mess.
 
So i think overall Object Pascal is more "beautiful" and easier than C++
and C, and i think that's the strenght of Object Pascal.
 
 
 
 
Thank you,
Amine Moulay Ramdane.
bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Feb 25 10:36PM +0100

Ramine <ramine@1.1>: Feb 25 01:56PM -0800

Hello,
 
I am an arab but i am "french", because i always talk and think french
in my daily life...
 
So i want to share with you this french song of compagnie creole, listen
to it , it's so beautiful...
 
https://www.youtube.com/watch?v=FNw0X8jy-IA
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Feb 25 01:41PM -0800

Hello guys..
 
 
Don't worry guys, i will post just few posts in this newsgroup...
so don't be so harsh, and about comp.programming, i was not the person
who have caused people to flee from comp.programming, the newsgroups
of comp.programming and comp.programming.thread was dying in fact before
i have posted in them, so i have decided to post some content there
about parallel programming and such, i didn't want to harm this
comp.programming or comp.programming.threads newsgroups, but since they
were dying , i just wanted to post some content about parallel
programming and such to not let them die...
 
 
That's all guys...
 
 
Thank you for your time...
 
 
Amine Moulay Ramdane.
ljshole@gmail.com: Feb 25 10:29AM -0800


> u guyz r rude. serouslee, the brew Ian axed a str8t up qestion.
> shur, he haz limited bakground knowledge but that doesn't meen you should tear into hymn about the complexity of your work. OK, you're a programmer, we're past that... Now answer our god dam qestions about compooters without being a snoody.
> "Given how poorly your question is asked"... get over yourshelf
 
Thank you my brother. Because they can tell the guy was asking a question what vaguely; they could have just asked him what he meant by explaining a few things to him and not biting his head off.
Ramine <ramine@1.1>: Feb 25 01:06PM -0800

Hello,
 
 
I have come to an interesting subject..
 
I was asking myself right now what is exactly is the big and important
improvement that brings Object oriented programming like C++ or Object
Pascal or Java or C# ?
 
I have thought rapidly at this and i think the BIG improvement that
brings object oriented programming is that it tries to "minimize" at
best "complexity" so that it can improve the criterion of
"maintainability" etc.. but how can we look at object programming ?
i think that by analogy it look like divide-and-conquer methods and
algorithms, i mean that object oriented programming is like an
"optimization" that minimizes at best the "complexity",
divide-and-conquer methods and algorithms also try to minimize at best
the number of steps or instructions that an algorithm have to do and we can
measure that as a time complexity expressing it by a O().
 
 
 
 
Thank you,
Amine Moulay Ramdane.
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at No comments:
Subscribe to: Posts (Atom)