473,854 Members | 1,449 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Boost process and C

Hi,

Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?

Thanks,
-vs

Apr 29 '06
335 11964
Chris Hills schrieb:
In article <4b************ *@individual.ne t>, Michael Mair
<Mi**********@i nvalid.invalid> writes
jacob navia schrieb:
ex********** ****@gmail.com a écrit :
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed.
There is C99
C89 still is the C standard effectively used.


You mean ISO C 90 + A1 and the two TC's
C89 is a local US standard.


True; I use C89 synonymously; considering how many people use
"ANSI C" or C89 for "ISO C 90 + AMD1 + TC1 + TC2", I am not too
alone out there :-)
Probably changing this habit is a good idea, though.
I would prefer that it were not so.


Why?


Because I fear that this means that C will not develop any
further:

The C99 (+ TC1 + TC2) extensions to C90 (+ AMD1 + TC1 + TC2)
have not been received well; they are, however, likely to be
part of a new standard.
As C99 is largely ignored[*] in the embedded community
(which often is quite happy with conforming freestanding
implementations plus one or two other goodies[*]) as well as
the target audiences for complex types and better floating
point environment support, no new add-ons are likely to draw
these groups to a new C.
Starting with language subsetting ("I am a happy fun C90
implementation with the following parts of C99 and C0X...")
IMO is the wrong way to go but may be the only way to
interest people who essentially only need and/or want
"C90+something" .
Things I personally would like to have, e.g. a compile-time
typeof() for the base types, are not exactly what you may
need for generating customer-accepted C code via a production
code generator (customers probably want explicit "Result:Int 32
Par1: Int32 Par2: Int16" macros used because of data flow
analysis) or to make C more interesting for use in numeric
simulation and optimisation projects or ...

If you cannot satisfy a substantial part of the C users by
a new language standard, then the language as a whole may
become less accepted or you effectively will have the
language standard which is used by most people as de facto
language standard version.
[*] This is my perception and may be wrong.

K&R C and C99 are discussed
in this group as well, and if there is a C0X, it will be discussed
here as well.

*sigh* Go to the appropriate places or open one yourself.
I am certainly willing to contribute.

Somehow, "Embedded C" and "C99" evolved without your contribution.


What is "Embedded C" and who developed it?


http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Apr 29 '06 #11
In article <4b************ *@individual.ne t>, Michael Mair
<Mi**********@i nvalid.invalid> writes
Chris Hills schrieb:
In article <4b************ *@individual.ne t>, Michael Mair
<Mi**********@i nvalid.invalid> writes
jacob navia schrieb:

ex********* *****@gmail.com a écrit :
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed.
There is C99
C89 still is the C standard effectively used.


You mean ISO C 90 + A1 and the two TC's
C89 is a local US standard.


True; I use C89 synonymously; considering how many people use
"ANSI C" or C89 for "ISO C 90 + AMD1 + TC1 + TC2", I am not too
alone out there :-)
Probably changing this habit is a good idea, though.
I would prefer that it were not so.


Why?


Because I fear that this means that C will not develop any
further:

The C99 (+ TC1 + TC2) extensions to C90 (+ AMD1 + TC1 + TC2)
have not been received well; they are, however, likely to be
part of a new standard.
As C99 is largely ignored[*] in the embedded community
(which often is quite happy with conforming freestanding
implementation s plus one or two other goodies[*]) as well as
the target audiences for complex types and better floating
point environment support, no new add-ons are likely to draw
these groups to a new C.
Starting with language subsetting ("I am a happy fun C90
implementati on with the following parts of C99 and C0X...")
IMO is the wrong way to go but may be the only way to
interest people who essentially only need and/or want
"C90+something ".
Things I personally would like to have, e.g. a compile-time
typeof() for the base types, are not exactly what you may
need for generating customer-accepted C code via a production
code generator (customers probably want explicit "Result:Int 32
Par1: Int32 Par2: Int16" macros used because of data flow
analysis) or to make C more interesting for use in numeric
simulation and optimisation projects or ...

If you cannot satisfy a substantial part of the C users by
a new language standard, then the language as a whole may
become less accepted or you effectively will have the
language standard which is used by most people as de facto
language standard version.

[*] This is my perception and may be wrong.

Interesting perspective. I agree with a lot of what you say.

K&R C and C99 are discussed
in this group as well, and if there is a C0X, it will be discussed
here as well.

*sigh* Go to the appropriate places or open one yourself.
I am certainly willing to contribute.

Somehow, "Embedded C" and "C99" evolved without your contribution.


What is "Embedded C" and who developed it?


http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/


That is NOT "Embedded C"

It is basically a TR for extensions for DSP's I know I had some
(minor) input into it at various WG14 and other meetings.

There is no embedded C as there is EC++ (which was developed outside the
ISO process)

For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys. org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Apr 29 '06 #12
Chris Hills schrieb:
In article <4b************ *@individual.ne t>, Michael Mair
<Mi**********@i nvalid.invalid> writes
Chris Hills schrieb:
In article <4b************ *@individual.ne t>, Michael Mair
<Mi********* *@invalid.inval id> writes <mention of "Embedded C">
What is "Embedded C" and who developed it?
http://www.embedded-c.org
http://www.open-std.org/jtc1/sc22/wg14/


That is NOT "Embedded C"

It is basically a TR for extensions for DSP's I know I had some
(minor) input into it at various WG14 and other meetings.

There is no embedded C as there is EC++ (which was developed outside the
ISO process)


I am aware of the difference between what I called "Embedded C" --
BTW: You can find exactly this TR and articles about it by searching
for "Embedded C" -- and C on embedded systems. I called the thing
by the name by which it was introduced to me (via CUJ, Embedded
Systems and friends).

For embedded work most of the world uses MISRA-C. It is also what the
tool vendors support.


Don't I know it...
Especially Japanese customers ask for MISRA compliance even in
generated code -- and, ideally, always all versions at once.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Apr 29 '06 #13
jacob navia wrote:
ex************* *@gmail.com a écrit :
Is there any group in the manner of the C++ Boost group that works on
the evolution of the C language? Or is there any group that performs an
equivalent function?
I would like that such a group existed but... I have never found one.


Well, there is also no group for discussing the *practice* of C
programming, the implementation of C compilers/libraries, common C
compilers and their extensions, algorithms in C or C variants either.
It is a pity. Most people in this forum, for instance, that I thought
it would be suchg a group, refuse to discuss about any evolution
and seem nostalgic of some mythical past: they endorse the C89
standard (full 17 years ago) and will start getting VERY upset
if any improvement is proposed. Most of them think, as one of them
said:

"C++ is the future, we are just waiting that C programmers die out."
Yes, but there is an inherent contradiction in this. C++ people also
refuse to extend the C-like subset of their language. They do this,
precisely because they incorrectly assume that the C standards
committee will be responsible and improve their standard over time in
all the relevant ways they might need or desire. (I may overstate
this, as the C++ people are very much aware of what a debacle the C99
standard was; at least from their point of view.)

So there is a big opportunity for other languages to step in an simply
deliver greater functionality than both C and C++.

A classic example of this is how Python uses GMP to support long
integers in its language. The key portions of GMP are written in
assembly language that is not generatable by any C compiler and thus
cannot be approached in performance any better than 25%. So while
Python is generally a *much* slower language than C, on the one aspect
of long integer computation portable and standard compliant Python will
embarrass any comparable standard C code in terms of performance that
tries to do that same computation.

The obvious question, then, is why can't C programmer just use GMP?
Well they can, so long as they are not bothered by including lots of
handcrafted assembly in their projects. But there are also issues with
using GMP -- GMP is not thread safe, and does not include some
classical cryptographic functions such as Barret-reduction or
Montgomery-reduction. So there are alternatives, like LibTom and
others with various other kinds of trade offs, but all them achieving
speed through assembly language. I doubt that all of them have been
ported to AMD64, which is clearly going to be the dominant platform
going forward.

Python gets away with using GMP, because its multithreading
implementation is standardized, and is coroutine based (they call them
generators) and is *emulated* rather than relying on system features to
do this. (Python also does not have special support for crypto in its
operators.) So the use of GMP is merely an implementation detail
rather than being an exposed part of their standard.

The sad thing, of course, is that C needs to add one single polymorphic
function or operator (a widening multiply) to the specification to put
an end to all of this. I will make a prediction right now, that such
an operator or function with *NEVER* be added to the C standard. The
standards purveyors simply aren't at the level required, nor are they
focussed enough to realize why this and similar issues are so
important.
This precludes of course any attitude that would discuss the evolution
of the language


Well it ends up promoting really *BAD* evolution, actually. Take TR
24731 for example. This is an extension to C that is supposedly
supposed to make C safer for string manipulation and is likely to
appear in the next standard. It does no such thing, of course (every
failure mode in standard C is direcly mappable to a failure mode using
TR 24731) -- but the standards people, somehow *BELIEVES* that it does.
It seemed promising in the sense that they at least tried something --
but one cannot help but think this is nothing more than a reactionary
move against those decrying against C as a ridiculously unsafe
language. The guilt of knowing that the C standards committee members
are, in essence, coauthors of nearly every single virus and exploit is
probably what caused them to endorse this nonsense. Of course they are
just being tools of a PR maneuver by TR 24731's authors. Most people
in this newsgroup, or anywhere else, probably have no idea what TR
24731 is. That's because there is so little open discussion about the
evolution of C.

One thing we have to ask ourselves -- is it possible to extend C in a
way that general C programmers would have to say to themselves: "I
*need* the new standard, because it will make me a better programmer"?
Look at the C99 standard and as yourself whether it rose to this level.
It clearly did not, and the next standard won't rise to this level
either.

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve. Or at least it
will not evolve from a process of open discussion. So people like
Microsoft have no trouble subverting the C standard for their own
purposes, and while system vendors just watch out for their own
self-interest.

Just compare how the proposed changes to the C standard (from C89, or
the new stuff from C99) to the proposals for the next C++ standard.
The next C++ standard is *clearly* going to be a much better language
than its predecessor -- the inclusion of "auto" is a brilliant maneuver
that really puts the question to the dynamic languages that have become
popular lately. I don't know if things are more open in the C++
universe, but clearly they have more activity amongst the creators of
Boost and STL; or maybe Stroustrup is just a brilliant guy. Whatever;
it really underscores how pathetic the C standard is.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Apr 29 '06 #14
In article <4b************ *@individual.ne t>
Michael Mair <Mi**********@i nvalid.invalid> wrote:
As C99 is largely ignored[*] in the embedded community ...
[*] This is my perception and may be wrong.


One data point: Wind River (which sells in the "embedded" market)
is moving towards full C99 support, however slowly. It is at least
a "checkbox item", if not one of the high priority ones.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Apr 29 '06 #15

Well Paul, as often, I have to agree with you in most of your analysis.

Just some points:

[snip for brevity]

Take TR
24731 for example. This is an extension to C that is supposedly
supposed to make C safer for string manipulation and is likely to
appear in the next standard. It does no such thing, of course (every
failure mode in standard C is direcly mappable to a failure mode using
TR 24731) -- but the standards people, somehow *BELIEVES* that it does.
It seemed promising in the sense that they at least tried something --
but one cannot help but think this is nothing more than a reactionary
move against those decrying against C as a ridiculously unsafe
language. The guilt of knowing that the C standards committee members
are, in essence, coauthors of nearly every single virus and exploit is
probably what caused them to endorse this nonsense. Of course they are
just being tools of a PR maneuver by TR 24731's authors. Most people
in this newsgroup, or anywhere else, probably have no idea what TR
24731 is. That's because there is so little open discussion about the
evolution of C.
The problem is that instead of getting away from strings as zero
terminated array of characters they STILL hang to it. THEN all functions
must be explicitely be given the length of the strings/buffers/etc even
if it is immediately obvious that the programmer can't know in all cases
what that dammed length is nor should he care!

typedef struct _string {
size_t length;
char *Stringdata
} String;

is too much for the C standards comitee. This structure is split then at
each function call in a data and a length, and it is up to the
programmer to figure out the length without ever making an error.

I have proposed (and implemented) a demonstration how could that be
done. See the string library of lcc-win32.

One thing we have to ask ourselves -- is it possible to extend C in a
way that general C programmers would have to say to themselves: "I
*need* the new standard, because it will make me a better programmer"?
Look at the C99 standard and as yourself whether it rose to this level.
It clearly did not, and the next standard won't rise to this level
either.

Because everyone agrees that C is dead and should NOT be developed any
further. It should be left for embedded systems with small RAM footprint
where C++ can never run.

As the hardware evolves and even small gadgets feature megabytes of RAM
those niche applications will be more and more difficult to find.

The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course.
Of course, but they willl not agree with this, obviously. They are still
in C89 and the few points that C99 brought in the sense of a better
language are just denied. Each time I remind people about them, they
tell me that "not all compilers support C99" what is true but doesn't
make things advance at all.

If there is no clear place where the evolution of C can be discussed, then it won't be, and C will not evolve.
Yes, and that is why I still try to discuss serious perspectives in this
group. Maybe because lcc-win32 is the only compiler system that is
centered around C and it is not just a C++ compiler that can also do
some C compilations.

Or is maybe that the reason for the aggressivity the "OFF TOPIC"
discussions are led?

Or at least it will not evolve from a process of open discussion. So people like
Microsoft have no trouble subverting the C standard for their own
purposes, and while system vendors just watch out for their own
self-interest.

Just compare how the proposed changes to the C standard (from C89, or
the new stuff from C99) to the proposals for the next C++ standard.
The next C++ standard is *clearly* going to be a much better language
than its predecessor -- the inclusion of "auto" is a brilliant maneuver
that really puts the question to the dynamic languages that have become
popular lately. I don't know if things are more open in the C++
universe, but clearly they have more activity amongst the creators of
Boost and STL; or maybe Stroustrup is just a brilliant guy. Whatever;
it really underscores how pathetic the C standard is.


Yes, but the problem is that in the C standards comitee most people care
much more about C++ than C. There is no compiler for C today. All are
C++ compilers that can do C as an after thought. Gcc has implemented
most of the standard but still never makes it to finish it.

Microsoft doesn't care at all, and pursues its own standards through the
windows platform, where it can dictate whatever it wishes.

Apple has got objective C, and sticks to it.

-------------------------

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.

This small change would make possible to write good string libraries,
good numerical libraries, etc.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.

And that is all. Small but essential changes that would make C a very
good language without loosing the simplicity, what is its greatest
asset. The problem of C++'s complexity is known. C with those minor
modifications would be a very useful language.

jacob
Apr 29 '06 #16
Chris Torek a écrit :
In article <4b************ *@individual.ne t>
Michael Mair <Mi**********@i nvalid.invalid> wrote:
As C99 is largely ignored[*] in the embedded community ...
[*] This is my perception and may be wrong.

One data point: Wind River (which sells in the "embedded" market)
is moving towards full C99 support, however slowly. It is at least
a "checkbox item", if not one of the high priority ones.


OFF TOPIC

Each day I see the new images of Mars sent by two rovers running
VxWorks. It is more than two (earth) years that those systems are
roaming around in the surface of Mars.

Good work guys!
Apr 29 '06 #17
we******@gmail. com writes:
[...]
The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve.

[...]

There is. It's called comp.std.c.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Apr 29 '06 #18
Keith Thompson a écrit :
we******@gmail. com writes:
[...]
The people in this newsgroup who have imposed their will that this
newgroup simply not discuss this issue are part of the problem of
course. If there is no clear place where the evolution of C can be
discussed, then it won't be, and C will not evolve.


[...]

There is. It's called comp.std.c.


No, it can't be discussed there. Standards comitees do not try to
advance the language but to standardize existing practice.

jacob
Apr 29 '06 #19
jacob navia wrote:

Because everyone agrees that C is dead and should NOT be developed any
further. It should be left for embedded systems with small RAM footprint
where C++ can never run.
C isn't dead, it's mature, there is a difference.

Still, C has a big potential of growth with some minor additions like
operator overloading, something that is accepted by more conservative
languages like fortran for instance.
If you want overloading, use C++.
This small change would make possible to write good string libraries,
good numerical libraries, etc.

Another feature is the overloaded functions feature that could allow a
limited amount of generic programming.
Same here, these features exist elsewhere, if you want them, go there.
And that is all. Small but essential changes that would make C a very
good language without loosing the simplicity, what is its greatest
asset. The problem of C++'s complexity is known. C with those minor
modifications would be a very useful language.

It already exists, but it isn't called C.

--
Ian Collins.
Apr 29 '06 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

65
5408
by: perseus | last post by:
I think that everyone who told me that my question is irrelevant, in particular Mr. David White, is being absolutely ridiculous. Obviously, most of you up here behave like the owners of the C++ language. A C++ interface installation IS ABOUT THE C++ LANGUAGE! The language does not possess the ability to handle even simple file directory manipulation. Those wise people that created it did not take care of it. So, BOOST is a portable...
205
10771
by: Jeremy Siek | last post by:
CALL FOR PAPERS/PARTICIPATION C++, Boost, and the Future of C++ Libraries Workshop at OOPSLA October 24-28, 2004 Vancouver, British Columbia, Canada http://tinyurl.com/4n5pf Submissions
17
1906
by: Howard Gardner | last post by:
/* If I am using boost, then how should I write this program? As it sits, this program is using SFINAE to determine whether or not a type supports particular syntax. I suspect that there is functionality in boost to do this. I have found mpl::has_xxx, which I suspect of being part of the solution. I've also found type_traits::has_nothrow_constructor
2
6636
by: smith4894 | last post by:
{ not sure you're aware of that but there are the newsgroups for all major operating systems. you might want to try asking in the forum 'comp.os.linux.development.apps', since memory-mapped files are not a language-supported structure, they are platform-specific. -mod } I'm trying to use boost serialization to serialize/deserialize data to and from a mmap'd file. I have my own ostream/istream classes that essentially read/write bytes...
5
2400
by: linyanhung | last post by:
I used a boost multi thread in VS 2005 on a Duo Core PC, and made a two thread process. The code is something like this: #include <boost/thread/thread.hpp> void fun1() { //do something
8
6216
by: Matt England | last post by:
My team currently using Boost Threads, but we are considering switching to ZThreads. (We seek cross-platform, C++ multithreading capabilities in an external library.) ZThread(s): http://zthread.sourceforge.net/ http://www.inf.uni-konstanz.de/dbis/members/vinnik/zsim/doc/ Can anyone share their ZThreads experience, either good, bad, or
2
2417
by: ironpingwin | last post by:
Hi! I'd like to make few threads which will run in the same time in C++. I try to use boost library v 1.34.1 (it can't be newest, because I compile on remote machine, which is not administrated by me). In this version there isn't detach() function. How to run functions from two different class in the same time?
13
4542
by: brad | last post by:
Still learning C++. I'm writing some regex using boost. It works great. Only thing is... this code seems slow to me compared to equivelent Perl and Python. I'm sure I'm doing something incorrect. Any tips? #include <boost/regex.hpp> #include <iostream> // g++ numbers.cpp -o numbers -I/usr/local/include/boost-1_35 /usr/local/lib/libboost_regex-gcc41-mt-s.a // g++ numbers.cpp -o numbers.exe
5
3596
by: ameyav | last post by:
Hi All, I am converting some C code into C++ code. The objective is to improve throughput. I have some code written in C which serially parses through a list of files, opens each one of them, processes the data and closes the file. All the files are processed one by one. The obvious performance bottleneck that i could think of is the wasted cpu cycles for file i/o. *My solution* was to spawn multiple threads to do the file i/o. For...
0
11031
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10685
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10371
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9518
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7082
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5750
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5942
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4162
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3188
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.