On Thu, 27 Jul 2000, Ilya Khayutin wrote:
> Other advantages on C??? Do you know about any future
> in C++ that can't be implemented in C
For one, inline functions. Don't even get me started on macros.
> except
> inheritence and the ability to "protect" variables
> (which is NOT so easily imple
> You are an idiot.
> Seems that you do not know neither C, nor C++.
> privilege control can be implemented in C without
> any trouble.
> C++ has _other_ advantages on C.
Other advantages on C??? Do you know about any future
in C++ that can't be implemented in C except
inheritence and the abilit
Quoth Stanislav Malyshev a.k.a Frodo on Mon, Jul 24, 2000:
[standard]
> VV>> Something that is widely implemented and followed, perhaps?
>
> You must mean Microsoft Office *ducks* *runs* *hides*
Now, Frodo, this is MEAN.
Vadik.
--
Spelling is a lossed art.
===
IA>> > Given enough time and resource - definitely. Having made entire DB
IA>> > solution in pure Javascript (no, it wasn't fun), I'm firm in this.
IA>>
IA>> now THAT sounds impressive. does it parse XML too? do publish it in
IA>> OpenSource :-)
No, it didn't (though I guess I might do that too,
On Mon, 24 Jul 2000, Stanislav Malyshev a.k.a Frodo wrote:
> VV>> Something that is widely implemented and followed, perhaps?
>
> You must mean Microsoft Office *ducks* *runs* *hides*
for that matter, YES. M$office is a DE FACTO standard. question is are
we discussing de-facto or de-jure st
VV>> Something that is widely implemented and followed, perhaps?
You must mean Microsoft Office *ducks* *runs* *hides*
VV>> No, sadly. You?
ITYM "no, luckily". It isn't real flamewar unless it is over One True
Standard.
VV>> For some reason, I haven't saved the addresses of FUCKING
VV>> "
Quoth Ury Segal on Sun, Jul 23, 2000:
> Yes. Do you know what is a standard ?
Something that is widely implemented and followed, perhaps?
> Have you EVER been
> involved in standatrizing effort ?
No, sadly. You?
> Did you ever READ a standard?
Do RFCs or ISO standards qualify? In this case,
Quoth Adam Morrison on Sun, Jul 23, 2000:
> > I haven't sene many programmers who go and fiddle with struct
> > __jmp_buf instead of using setjmp/longjmp.
>
> You don't have to look very far, actually.
>
> http://www.cs.huji.ac.il/course/os/Ex3/demo.c
I know. I did this exercise too. But my p
To: [EMAIL PROTECTED]; Vadim Vygonets
Subject: Re: C++ today (was "Re: GTK 1.3.1")
> Quoth Ilya Khayutin on Fri, Jul 21, 2000:
> > >From this thread I got the impression that most people
> > here think that C++ is still that language which has
> > no standart, used by
> Quoth Ilya Khayutin on Fri, Jul 21, 2000:
> > >From this thread I got the impression that most people
> > here think that C++ is still that language which has
> > no standart, used by small groups of people and is
> > realy useless. Well guys... IT IS NOT THE 80s
> > ANYMORE!!!
>
> Pity.
>
>
> > If you
> > simply write in the documentation "don't use that member", intellegient
> > programmers won't use it. And unintellegient programmers will make stupid
> > mistakes no matter how you try to protect them.
>
> For example, one of the OSes I use defines jmp_buf as:
>
> struct __jmp_bu
Quoth Moshe Zadka on Sat, Jul 22, 2000:
> On Sat, 22 Jul 2000, Vadim Vygonets wrote:
> > Private class members have nothing to do with API _or_
> > documentation. It just hides the internal structure.
>
> What do you mean "hides"? The private class members are right there in
> your face in the h
On Sat, 22 Jul 2000, Vadim Vygonets wrote:
> > Only if you're writing in the wild west. In most other places, people try
> > not to shoot themselves in the foot by using undocumented APIs.
>
> Hello?
>
> Private class members have nothing to do with API _or_
> documentation. It just hides the
Quoth Ilya Khayutin on Fri, Jul 21, 2000:
> >From this thread I got the impression that most people
> here think that C++ is still that language which has
> no standart, used by small groups of people and is
> realy useless. Well guys... IT IS NOT THE 80s
> ANYMORE!!!
Pity.
> It is year 2000 and
Quoth Moshe Zadka on Fri, Jul 21, 2000:
> On Fri, 21 Jul 2000, Ilya Khayutin wrote:
>
> > There is a big diffrence between a C++
> > class and a C struct: PRIVELEGE CONTROL!! In C
> > everyone can directly intefere with any variable in
> > the program, same with gtk+ which written in C. In C++
>
On Fri, 21 Jul 2000, Ilya Khayutin wrote:
> There is a big diffrence between a C++
> class and a C struct: PRIVELEGE CONTROL!! In C
> everyone can directly intefere with any variable in
> the program, same with gtk+ which written in C. In C++
> I can make some variable in a class private or
> pro
Hi,
>From this thread I got the impression that most people
here think that C++ is still that language which has
no standart, used by small groups of people and is
realy useless. Well guys... IT IS NOT THE 80s
ANYMORE!!! It is year 2000 and C++ is a standartized
language which is used by a VERY l
On Wed, Jul 19, 2000 at 11:10:02PM +0300, Tzafrir Cohen wrote:
> What is "xterm with unicode"?
Grab xterm. Compile with --enable-wide-chars (or something
similar). Run with xterm +u8
(You should have a font with a unicode encoding, iso10646-1.
http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html for a U
On Wed, 19 Jul 2000, Moshe Zadka wrote:
first gilad wrote:
> > Qt indeed uses C++ but AFAIK not very well. No templates, no STL and
> > little use of things like multiple inheritance . Now I can hear all you
> > hard core C programers saying to yourselves: "why, you sayit like it's
> > a bad th
On Wed, 19 Jul 2000, Gilad Ben-Yossef wrote:
> Qt indeed uses C++ but AFAIK not very well. No templates, no STL and
> little use of things like multiple inheritance . Now I can hear all you
> hard core C programers saying to yourselves: "why, you say it like it's
> a bad thing?!" but I think that
On Wed, 19 Jul 2000, Matti Picus wrote:
> But can't LGPL be used to build proprietary applications? Just build the
> proprietary stuff as a library, supply only the main.c source along with
> the libraries and headers, and you are OK, no?
you don't have to expose the source code of an applica
On Wed, 19 Jul 2000, Ilya Konstantinov wrote:
> On Wed, Jul 19, 2000 at 01:22:08AM +0300, Pavel Bibergal wrote:
> > The new development version of GTK 1.3.1 is out :)
> >
> > http://news.gnome.org/gnome-news/963685850/
> >
> > full Pango/Unicode integration.. that mean the hebrew will work right
- Original Message -
From: Ilya Konstantinov <[EMAIL PROTECTED]>
> QT is C++ and OO. For GTK+, they developed their own system
> of containers and objects so they won't have to use C++
This sentense said you realy, readly do not understand
what C++ is all about.
> (and community people
Ilya Konstantinov wrote:
>
> On Wed, Jul 19, 2000 at 08:21:50AM +0300, Ira Abramov wrote:
> > BTW, I'm still in the dark about why not use OO for libraries such as
> > this (Graphic toolkits).
>
> QT is C++ and OO. For GTK+, they developed their own system
> of containers and objects so they wo
On Wed, Jul 19, 2000 at 08:21:50AM +0300, Ira Abramov wrote:
> nothing is ever perfect from day one, and sometimes to improve a product
> you must break backwards compatibility. Bill Gates have yet to
> understand it.
Of course. For example, the multiline text widget (gtktext) was redone.
The pre
On Wed, 19 Jul 2000, Matti Picus wrote:
> But can't LGPL be used to build proprietary applications? Just build the
> proprietary stuff as a library, supply only the main.c source along with
> the libraries and headers, and you are OK, no?
It's not always convinient.
But can't LGPL be used to build proprietary applications? Just build the
proprietary stuff as a library, supply only the main.c source along with
the libraries and headers, and you are OK, no?
Matti
At 10:58 AM 19/7/00 +0300, Moshe Zadka wrote:
>On Wed, 19 Jul 2000, Chen Shapira wrote:
>
>It f
On Wed, 19 Jul 2000, Chen Shapira wrote:
> > > Anyone interested in working on such a library? a c++ toolkit
> > > from-scratch? there's an Israeli startup taking on
> > Gnome/Gtk, Eazel and
> > > Helix together with a GPL kit of their own, and they are looking for
> > > people.
>
> I'm in the
Moshe Zadka wrote:
>
> On Wed, 19 Jul 2000, Chen Shapira wrote:
>
> > > Huh? What good toolkit do you know that is
> > >
> > > a) public domain (or close enough)
> > > b) good
> > > c) portable to Win32/MacOS/BeOS/X Windows
> >
> > Perhaps GTK?
>
> It fails on licence issues -- it's LGPL
>
i
On Wed, 19 Jul 2000, Chen Shapira wrote:
> > Huh? What good toolkit do you know that is
> >
> > a) public domain (or close enough)
> > b) good
> > c) portable to Win32/MacOS/BeOS/X Windows
>
> Perhaps GTK?
It fails on licence issues -- it's LGPL
--
Moshe Zadka <[EMAIL PROTECTED]>
There is no
On Wed, 19 Jul 2000, Moshe Zadka wrote:
> Huh? What good toolkit do you know that is
>
> a) public domain (or close enough)
> b) good
> c) portable to Win32/MacOS/BeOS/X Windows
only Qt and GTk I suppose, unless you count Qt as not PD, and GTk not as
"good". but I think they both work also on w
On Wed, 19 Jul 2000, Chen Shapira wrote:
> > > Anyone interested in working on such a library? a c++ toolkit
> > > from-scratch? there's an Israeli startup taking on
> > Gnome/Gtk, Eazel and
> > > Helix together with a GPL kit of their own, and they are looking for
> > > people.
>
> I'm in the
> Huh? What good toolkit do you know that is
>
> a) public domain (or close enough)
> b) good
> c) portable to Win32/MacOS/BeOS/X Windows
Perhaps GTK? But this is rarly the point. There are enough toolkits to make
choices from.
And you can improve on existing ones as you wish.
if b is the most
On Wed, 19 Jul 2000, Chen Shapira wrote:
> Why write a Graphic Toolkit from scratch? there are many avaliable, in
> diffrent licenses, languages, stages of development, etc. Plenty of space to
> choose from and then adapt to your own taste. All are pretty decent.
Huh? What good toolkit do you kn
> > Anyone interested in working on such a library? a c++ toolkit
> > from-scratch? there's an Israeli startup taking on
> Gnome/Gtk, Eazel and
> > Helix together with a GPL kit of their own, and they are looking for
> > people.
I'm in the dark here.
Why write a Graphic Toolkit from scratch? the
Ira Abramov wrote:
>
> On Wed, 19 Jul 2000, Ilya Konstantinov wrote:
>
> > Bad thing is - GTK+ 1.3 (which'll be released as GTK+ 2.0
> > when final) won't be back-compatible. Preloading the new
> > libraries before old applications does no good, and OWen
> > said every application would have to
On Wed, 19 Jul 2000, Ilya Konstantinov wrote:
> Bad thing is - GTK+ 1.3 (which'll be released as GTK+ 2.0
> when final) won't be back-compatible. Preloading the new
> libraries before old applications does no good, and OWen
> said every application would have to undergo atleast
> some minor chang
On Wed, Jul 19, 2000 at 01:22:08AM +0300, Pavel Bibergal wrote:
> The new development version of GTK 1.3.1 is out :)
>
> http://news.gnome.org/gnome-news/963685850/
>
> full Pango/Unicode integration.. that mean the hebrew will work right on
> next gtk versions :)
I have tested the pango-gtk bu
38 matches
Mail list logo