porting from C++Builder

  • Thread starter Thread starter emavisu
  • Start date Start date
you were lying?

daniel, i am very confident that microsoft will do something about "triky"
individuals like you, who are not trying to help anything or anybody, but
rather engage in provocative non-sense. to make my point clearly, here are
some of your posts from the past:

That's a good point -- and well made -- and if your apps are all desktop
apps then it may be a good enough solution for you. I achieve much the
same by running Windows apps in a Windows VM under linux; it means I have
to have a licensed copy of Windows to run in the VM, which you avoid by
using Crossover (or Wine), but that is not a big problem.

or
So, yes, I think native code is the way to go for C++ ... and I'd choose
Java rather than C# for the sandboxed environments because it has greater
market penetration. To me, C# is a language that should never have been.

or from your website (http://www.calamity.org.uk/):

Sorry, nothing here. Maybe someday, maybe not.

or another example, your own statement:
It doesn't help that Boost.Build works very badly with Windows 9x (I'm
mainly a linux user, so I never upgraded). Another part of the problem
is that I'm not sure what is causing the link errors in the test
results. Such as: http://tinyurl.com/c8tdo. Hopefully over the next week
or two I'll get a better idea.

So, if you mainly a linux user, what are you doing in here? Looking for
troubles? For provocations against people who spent all their lifes in good
faith and hard work under windows / ms platforms, since day one (msdos 1.0)?
About here, you are always welcome, if you really wanna get a taste of what
professional development on professional platforms (windows) looks like, but
please, try to respect the culture here... take your fights to linux world...
over there you may succed

Regards,
d :-)
 
Daniel said:
Yup. I got the impression (perhaps wrongly) that the OP wasn't working
on Open Source code, though. IIUC Qt's licensing makes it clear that
the GPL version can only be used for free (as in beer) software.

Ummm. IANAL but...

GPL can only ever be applied to free (as in speech) products, they don't
have to be free (as in beer) and the GPL is incompatible with any extra
licensing language that would add a zero-price-tag requirement.
 
of cross platform, offered cross language interoperability. the
crowds reacted and in a way, it makes perfect sense not to certify
C++ developers, since these guys know so much, that their systems
certify themselves! on the other hand, in mfc (and later on in atl)

You're not only a troll, you're rather naive as well. .NET systems don't
certify themselves any more than C++ systems do.
you see a bizare mix of the most advanced C++ features (templates,
multiple inheritance) coupled, mixed together with horrible
(completely unnaceptable, type unsafe) c preprocessor macros, so
horrible and innapropiate that they make one wonder... it's legacy,
it was the way to go, a long time back, they've been accepted for
aparent simplicity, when in fact, the C++ language supposed to get
true support for properties, events, etc in order to offer true
COMPONENTNESS to the masses (just like BCB dialect, and VCL, never
fully ported to C++ did once). Even today, the 0x upcoming C++
standard say NOTHING about support for properties and events (true

Or rather, C had support for function pointers since before your pet
language was dreamt up. Stop complaining about this non-issue.
componentness) for the simple reason that the ANSI C++ comitee is 99%
politics and 20 years old technical agendas (spliting hairs instead
of actually doing what the crowd need). from this point of view, c#
is definitely better, vb as well was alligned, keeping some familiar
feel and touch and the impression that still feels like the old days,
etc.
[snip]


i know, .NET offers a full range of obfuscators, sometimes, entire
apps are dressed into a native stub, instantiating the managed stuff
in memory, it's a looooong story. i do know about JITs, about the
strategy of actually bringing manged code at the level of "native"
code, but there are places where native code is needed, and the (so
hard to get) skills of C++ programmers will always be fully rewarded.

so, it's commercial software (in a box). then drivers. then system
level development, anti viruses, security software, even legacy
enterprise applications, then development tools, reality cannot be
put in a box and go like "hey, this is better, it's my way or the
highway" - it simply doesn't work that way.

Wow, you rag on C++ and then say it's necessary. Make up your mind please.
 
Daniel said:
Hurb Sutter: For me, easily the biggest news of the meeting was that
we voted lambda functions and closures into C++0x. I think this will
make STL algorithms an order of magnitude more usable, and it will be
a great boon to concurrent code where it's important to be able to
conveniently pass around a piece of code like an object, to be
invoked wherever the program sees fit (e.g., on a worker thread).

and this is so true!

there are two things i would personally like to see, in the standard
(not in a brilliant proprietary set of language extensions or
another).

1. better property support, and when i say better, i mean better than
this: http://www.codeguru.com/cpp/cpp/cpp_mfc/article.php/c4031#more
2. infering! and i don't have to say no more :-)

Already there, see the new and improved 'auto' keyword.
 
Daniel said:
actually, nothing could be further away from the truth! despites that
class you are talking about is actually a class template, properties
implemented that way cannot be generic, because of speciffic
operators. there are many implementations which seam to work but
choke on simple things like my_property++; and btw, properties go far
beyond having a setter and a getter and formal sintactic shoogar!

1. properties have setters and getters.
2. properties can engage in expressions of any kind, freely, just
like they were their "non-property" counteparts.

There's not a language around where a property can be used with the
address-of operator like a regular variable.
3. properties should be inheritable (let's say that this works
already, despites many implementation propose excruciating binding
macros for setters and getters...)
4. properties should be RTTI querable (have enough self defined RTTI)
5. properties should persist properly, regardless of their type

This last one hasn't anything to do with properties at all. In fact you
want to persist the internal state, not just properties.
 
This last one hasn't anything to do with properties at all. In fact you
want to persist the internal state, not just properties.

really? it's normal for a guy who never dealed with components to undertand
component life cycles, when NOT the underlying value (instance state) is
persisted but the actual property, with full blown side effects coming from
getters, setters, etc...
 
Or rather, C had support for function pointers since before your pet
language was dreamt up. Stop complaining about this non-issue.

don't really know what pet language you're talking about, didn't know i had
a pet language. of course, c has pointers to functions (i am using this since
1978, by that time, you were drinking milk). but you seam to miss the point
of being type safe! it's really a huge waste of time to trip you over
closures and so on... you would not understand since you don't seam to get it
why c++ is better than c and why c++0x should be better than today's c++ (and
it's obviously not gonna)

happy mvp
d
 
Daniel said:
don't really know what pet language you're talking about, didn't know
i had a pet language. of course, c has pointers to functions (i am
using this since 1978, by that time, you were drinking milk). but you

Actually I wasn't born yet. But though I may be young I seem to have
learned something in the meantime.
seam to miss the point of being type safe! it's really a huge waste

Function pointers are type-safe, don't know what makes you think otherwise.
In fact, the type-safety may be a little overly restrictive by not allowing
covariance and contravariance (as appropriate, on return values and
parameters, which may or may not be read-only/write-only pointers) which
would also be type-safe. But variance with pointer arguments is HARD so
it's no surprise that it simply isn't allowed.
of time to trip you over closures and so on... you would not

Closures really aren't so important, nor even anonymous functions, they're
just syntactic sugar for local types. Allowing templates to specialize to
local types is the important change, the other two are just minor effects of
that enabling decision.
 
Daniel said:
That's how I understand it, too.


IANAL either, but the statement here

http://trolltech.com/products/appdev/licensing/licensing

seems to say that they manage it somehow.

A quick look at that doesn't seem to have a zero-price-tag requirement. Can
you tell me what statement you are referring to?

The only thing I saw was that this statement is misleading:

"If you wish to use the Qt Open Source Edition, you must contribute all your
source code to the open source community in accordance with the GPL or Qt
Software's GPL Exception when your application is distributed."

You don't need to give your code to the community, only to the people who
buy your product. But they did say "in accordance with the GPL", so they
aren't actually wrong. Replacing "open source community" with "your users"
and "when ... distributed" to "if distributed" would be more clear and
accurate IMHO.

Again, IANAL. If you are building a business model around charging for GPL
software you definitely should consult a lawyer.
 
Daniel James said:
I was referring to the fact that they make Qt available under
different licences that allow the users to release their products in
different ways. In particular: if you don't want to release your
application under the GPL you have to use (and pay for) their
commercial licence, but if your application is Open Source you can use
their (free) Open Source licence.

I don't see an explicit statement that an Open Source Qt application
must be zero-cost, but it does say

The Qt Commercial Editions must be used for proprietary,
commercial development.

which rules out using the Open Source licence for anything but
non-commercial software. I have a little difficulty in imagining many
viable scenarios in which non-commercial software can be anything
other than zero-cost ... charityware, perhaps?

Well, in addition to "proprietary & commercial" and "non-commercial" there's
also "open source & commercial". Which the GPL permits.
 
Back
Top