Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why all tutorials/books use non-unicode string?
159 views
Skip to first unread message
JiiPee
Feb 21, 2015, 10:05:49 AM2/21/15
to
I am trying to learn how to use unicode string.. its not so easy really.
And difficult to find a guidelines how to do it. So still searching
(some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
life difficult as many functions like lenght would not work).
Everybody say that we should use unicode in our code. If so, then why
all turorials and C++ books use almost always char as a character type
(1 byte)? Why use examples which are not used in real world? This I do
not understand.
And even top C++ people like Bjorn does that.
And difficult to find a guidelines how to do it. So still searching
(some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
life difficult as many functions like lenght would not work).
Everybody say that we should use unicode in our code. If so, then why
all turorials and C++ books use almost always char as a character type
(1 byte)? Why use examples which are not used in real world? This I do
not understand.
And even top C++ people like Bjorn does that.
Mr Flibble
Feb 21, 2015, 10:17:53 AM2/21/15
to
like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
best as most common text is Latin) or UTF-32.
/Flibble
JiiPee
Feb 21, 2015, 11:09:57 AM2/21/15
to
uses UTF-16 and here I am talking about Windows/MFC programming what I
do currently. Visual C++ recommends using UTF-16 for sure and its used
there so I guess its better to use it there. Obviously programs come
when I save my string to file using my std-based C++ classes I made.
Well, need to convert I guess...
But... why do books teach strings using char-type (non-unicode)?
JiiPee
Feb 21, 2015, 11:10:33 AM2/21/15
to
On 21/02/2015 15:17, Mr Flibble wrote:
we try to find the truth.
JiiPee
Feb 21, 2015, 11:12:55 AM2/21/15
to
On 21/02/2015 15:17, Mr Flibble wrote:
working with std-string functions... for example lenght does not give
correct value.
Mr Flibble
Feb 21, 2015, 11:30:41 AM2/21/15
to
something like Qt instead (although Qt also fucktardedly uses UTF-16).
/Flibble
JiiPee
Feb 21, 2015, 11:35:46 AM2/21/15
to
VC++ is now free, so its a good deal and VC++ IDE is really good.... I
am so used to MFC its difficult to change. I guess its a matter of taste
as well? some like mfc some dont. I wish it used std-libraries though
instead of their own.
JiiPee
Feb 21, 2015, 11:39:23 AM2/21/15
to
they give VC++ now for free.... I cannot resist going back now :) .
MFC does the job for sure.. maybe not best but everything is there ,
isnt it?
Marcel Mueller
Feb 21, 2015, 11:54:13 AM2/21/15
to
On 21.02.15 17.12, JiiPee wrote:
> But does std::string work perfectly with UTF-8? I understood its not
> working with std-string functions... for example lenght does not give
> correct value.
Well, it depends on what you call the correct value.
> But does std::string work perfectly with UTF-8? I understood its not
> working with std-string functions... for example lenght does not give
> correct value.
Of course, it will not return the number of displayed characters. But
this is true for ASCII as well, if you include the control characters.
Unless you have a fixed width font there is no much use for the number
of displayed characters anyway.
On the other hand there are Unicode functions to determine the number of
visible characters. But be aware of pitfalls like invisible white space
(also used as BOM).
Marcel
Mr Flibble
Feb 21, 2015, 12:33:18 PM2/21/15
to
Qt a go as it is very good (and works with VC++).
/Flibble
Paavo Helde
Feb 21, 2015, 12:33:53 PM2/21/15
to
JiiPee <n...@notvalid.com> wrote in news:S81Gw.963871$I4.8...@fx34.am4:
> I am trying to learn how to use unicode string.. its not so easy
really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
For many programs, knowing the number of Unicode characters is not
important most of the time, so length() is all they need. Also note that
UTF-16 and UTF-8 are both packed formats, so length() works (or does not
work) exactly in the same way for both (albeit with UTF-16 any bugs will
probably remain hidden longer).
>
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
>
> And even top C++ people like Bjorn does that.
This is because there is no standard or portable way how to do that.
Choosing the best suited text encoding format depends on the operating
systems, used libraries and frameworks, type of the program (deep text
processing or not?) and the nomenclature of locales/languages which need
to be supported. So there is no single correct answer.
For tutorials, the best text format is indeed ASCII, to avoid delving
into unneeded details. For tutorials, also "using namespace std;" is a
good idea. Production code will be different in many ways from tutorial
code.
HTH
Paavo
> I am trying to learn how to use unicode string.. its not so easy
really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
important most of the time, so length() is all they need. Also note that
UTF-16 and UTF-8 are both packed formats, so length() works (or does not
work) exactly in the same way for both (albeit with UTF-16 any bugs will
probably remain hidden longer).
>
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
>
> And even top C++ people like Bjorn does that.
Choosing the best suited text encoding format depends on the operating
systems, used libraries and frameworks, type of the program (deep text
processing or not?) and the nomenclature of locales/languages which need
to be supported. So there is no single correct answer.
For tutorials, the best text format is indeed ASCII, to avoid delving
into unneeded details. For tutorials, also "using namespace std;" is a
good idea. Production code will be different in many ways from tutorial
code.
HTH
Paavo
Öö Tiib
Feb 21, 2015, 12:48:34 PM2/21/15
to
On Saturday, 21 February 2015 17:05:49 UTC+2, JiiPee wrote:
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
It is because it depends if your text editor and compiler understand and
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
support if you write code like:
char const banana[] = u8"🍌";
Even terrible to read code (that does same) is not supported by Visual
Studio 2013 like:
char const banana[] = u8"\U0001F34C";
https://msdn.microsoft.com/en-us/library/69ze775t.aspx
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
things. Unfortunately we often still have to rely on third party
libraries in practice (like ICU) for doing it because of the platform
vendors (like Microsoft).
> And even top C++ people like Bjorn does that.
JiiPee
Feb 21, 2015, 1:07:08 PM2/21/15
to
On 21/02/2015 17:33, Paavo Helde wrote:
> JiiPee <n...@notvalid.com> wrote in news:S81Gw.963871$I4.8...@fx34.am4:
>
>> I am trying to learn how to use unicode string.. its not so easy
> really.
>> And difficult to find a guidelines how to do it. So still searching
>> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
>> life difficult as many functions like lenght would not work).
> For many programs, knowing the number of Unicode characters is not
> important most of the time, so length() is all they need. Also note that
> UTF-16 and UTF-8 are both packed formats, so length() works (or does not
> work) exactly in the same way for both (albeit with UTF-16 any bugs will
> probably remain hidden longer).
>
>> Everybody say that we should use unicode in our code. If so, then why
>> all turorials and C++ books use almost always char as a character type
>> (1 byte)? Why use examples which are not used in real world? This I do
>> not understand.
>>
>> And even top C++ people like Bjorn does that.
> This is because there is no standard or portable way how to do that.
> Choosing the best suited text encoding format depends on the operating
> systems, used libraries and frameworks, type of the program (deep text
> processing or not?) and the nomenclature of locales/languages which need
> to be supported. So there is no single correct answer.
ok, I get your point
> JiiPee <n...@notvalid.com> wrote in news:S81Gw.963871$I4.8...@fx34.am4:
>
>> I am trying to learn how to use unicode string.. its not so easy
> really.
>> And difficult to find a guidelines how to do it. So still searching
>> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
>> life difficult as many functions like lenght would not work).
> For many programs, knowing the number of Unicode characters is not
> important most of the time, so length() is all they need. Also note that
> UTF-16 and UTF-8 are both packed formats, so length() works (or does not
> work) exactly in the same way for both (albeit with UTF-16 any bugs will
> probably remain hidden longer).
>
>> Everybody say that we should use unicode in our code. If so, then why
>> all turorials and C++ books use almost always char as a character type
>> (1 byte)? Why use examples which are not used in real world? This I do
>> not understand.
>>
>> And even top C++ people like Bjorn does that.
> This is because there is no standard or portable way how to do that.
> Choosing the best suited text encoding format depends on the operating
> systems, used libraries and frameworks, type of the program (deep text
> processing or not?) and the nomenclature of locales/languages which need
> to be supported. So there is no single correct answer.
JiiPee
Feb 21, 2015, 1:24:03 PM2/21/15
to
who supported it stopped supporting it....
Mr Flibble
Feb 21, 2015, 1:27:41 PM2/21/15
to
supported/updated.
http://www.qt.io/
/Flibble
Öö Tiib
Feb 21, 2015, 1:37:36 PM2/21/15
to
desk support from Digia. If you take open source license then you
get the support that random community member might bother to offer.
JiiPee
Feb 21, 2015, 1:50:39 PM2/21/15
to
On 21/02/2015 18:27, Mr Flibble wrote:
>
>> I read that Qt does not have anymore support properly as the old company
>> who supported it stopped supporting it....
>
> Wrong; Qt was sold to Digia which and is alive and well and
> continually supported/updated.
>
> http://www.qt.io/
>
> /Flibble
Also, I understand that making release programs one must buy a licence.
>
>> I read that Qt does not have anymore support properly as the old company
>> who supported it stopped supporting it....
>
> Wrong; Qt was sold to Digia which and is alive and well and
> continually supported/updated.
>
> http://www.qt.io/
>
> /Flibble
So its not open source
Mr Flibble
Feb 21, 2015, 1:52:58 PM2/21/15
to
a commercial license.
/Flibble
JiiPee
Feb 21, 2015, 1:55:58 PM2/21/15
to
On 21/02/2015 18:27, Mr Flibble wrote:
But, if the licence is too expensive then poor people like me just
cannot afford it, simple as that.. so we are forced to look other
alternativities
> On 21/02/2015 18:23, JiiPee wrote:
>>
>> I read that Qt does not have anymore support properly as the old company
>> who supported it stopped supporting it....
>
> Wrong; Qt was sold to Digia which and is alive and well and
> continually supported/updated.
>
> http://www.qt.io/
>
> /Flibble
Ok, paying a licence is not a problem as they do work to keep it well.
>>
>> I read that Qt does not have anymore support properly as the old company
>> who supported it stopped supporting it....
>
> Wrong; Qt was sold to Digia which and is alive and well and
> continually supported/updated.
>
> http://www.qt.io/
>
> /Flibble
But, if the licence is too expensive then poor people like me just
cannot afford it, simple as that.. so we are forced to look other
alternativities
JiiPee
Feb 21, 2015, 1:58:39 PM2/21/15
to
more than that I am not sure...and does not make sense to put more money
on that as there are free alternativities as well
But if its a very good program, then can pay, but not too much... people
who are rich can pay more maybe I know
Öö Tiib
Feb 21, 2015, 2:00:31 PM2/21/15
to
1) You do not have to buy commercial license to make commercial software
with Qt.
2) Qt is distributed as open source.
3) There are no relation between usage license and form of distribution.
Melzzzzz
Feb 21, 2015, 2:02:18 PM2/21/15
to
Mr Flibble
Feb 21, 2015, 2:04:49 PM2/21/15
to
can't statically link); I find this to be a pain in the arse.
/Flibble
Melzzzzz
Feb 21, 2015, 2:06:40 PM2/21/15
to
>
> /Flibble
>
>
JiiPee
Feb 21, 2015, 2:10:27 PM2/21/15
to
On 21/02/2015 19:00, Öö Tiib wrote:
> On Saturday, 21 February 2015 20:50:39 UTC+2, JiiPee wrote:
>> On 21/02/2015 18:27, Mr Flibble wrote:
>>>> I read that Qt does not have anymore support properly as the old company
>>>> who supported it stopped supporting it....
>>> Wrong; Qt was sold to Digia which and is alive and well and
>>> continually supported/updated.
>>>
>>> http://www.qt.io/
>>>
>>> /Flibble
>> Also, I understand that making release programs one must buy a licence.
>> So its not open source
> You are wrong on all three accounts.
> 1) You do not have to buy commercial license to make commercial software
> with Qt.
I am not lying.... year ago when I was checking which one to use, I also
>> On 21/02/2015 18:27, Mr Flibble wrote:
>>>> I read that Qt does not have anymore support properly as the old company
>>>> who supported it stopped supporting it....
>>> Wrong; Qt was sold to Digia which and is alive and well and
>>> continually supported/updated.
>>>
>>> http://www.qt.io/
>>>
>>> /Flibble
>> Also, I understand that making release programs one must buy a licence.
>> So its not open source
> You are wrong on all three accounts.
> 1) You do not have to buy commercial license to make commercial software
> with Qt.
seriously checked Qt, and this licence/fees put me off from that
straight away. ok, posssible they have changed rules....
There was a reason why I did not even try Qt.. one was its future and
other one the licence.... maybe they changed things.
Chris Vine
Feb 21, 2015, 2:10:57 PM2/21/15
to
the encoding definition. UTF-8 uses 8 bit datum types as part of the
encoding definition, end of story. So you store it in char arrays of 8
bits per char, which may of course be a char array within a std::string
object. An individual unicode code point may occupy from 1 to 5 chars.
std::u16string and UTF-16 are similar. UTF-16 uses a 16 bit datum type.
However, the character length of a UTF-16 string is not the number of
16 bit units in the string. A unicode code point may be represented by
1 or 2 16-bit units.
Unicode is not reducible in the way you assume. A unicode code point
is not the same as a glyph, which is probably what you are interested
in. This is partly because of combining characters and partly because
some CJK glyphs cannot be resolved except by looking at what other code
points are associated with it.
In other words, you have the wrong mental image of how glyphs are
represented.
Chris
JiiPee
Feb 21, 2015, 2:12:56 PM2/21/15
to
needs a licence.. or some kind of yearly fee or something. Reason I did
not even check more....year ago
Öö Tiib
Feb 21, 2015, 2:15:15 PM2/21/15
to
the users can relink it with improved/fixed version of the LGPL-ed part
if they so want. You may not make changes in LGPL-ed part without
distributing those changes as open source. It is definitely easier with
dynamic linking but it is not mandatory.
Melzzzzz
Feb 21, 2015, 2:16:07 PM2/21/15
to
On Sat, 21 Feb 2015 19:12:40 +0000
Qt is now LGPL which allows selling close source. GPL allows also
selling but source code must be provided.
selling but source code must be provided.
Öö Tiib
Feb 21, 2015, 2:25:33 PM2/21/15
to
On Saturday, 21 February 2015 21:10:27 UTC+2, JiiPee wrote:
> On 21/02/2015 19:00, Öö Tiib wrote:
> > On Saturday, 21 February 2015 20:50:39 UTC+2, JiiPee wrote:
> >> On 21/02/2015 18:27, Mr Flibble wrote:
> >>>> I read that Qt does not have anymore support properly as the old company
> >>>> who supported it stopped supporting it....
> >>> Wrong; Qt was sold to Digia which and is alive and well and
> >>> continually supported/updated.
> >>>
> >>> http://www.qt.io/
> >>>
> >>> /Flibble
> >> Also, I understand that making release programs one must buy a licence.
> >> So its not open source
> > You are wrong on all three accounts.
> > 1) You do not have to buy commercial license to make commercial software
> > with Qt.
>
> I am not lying.... year ago when I was checking which one to use, I also
> seriously checked Qt, and this licence/fees put me off from that
> straight away. ok, posssible they have changed rules....
I did not say you are lying. I said you are wrong. The Qt users have option
> On 21/02/2015 19:00, Öö Tiib wrote:
> > On Saturday, 21 February 2015 20:50:39 UTC+2, JiiPee wrote:
> >> On 21/02/2015 18:27, Mr Flibble wrote:
> >>>> I read that Qt does not have anymore support properly as the old company
> >>>> who supported it stopped supporting it....
> >>> Wrong; Qt was sold to Digia which and is alive and well and
> >>> continually supported/updated.
> >>>
> >>> http://www.qt.io/
> >>>
> >>> /Flibble
> >> Also, I understand that making release programs one must buy a licence.
> >> So its not open source
> > You are wrong on all three accounts.
> > 1) You do not have to buy commercial license to make commercial software
> > with Qt.
>
> I am not lying.... year ago when I was checking which one to use, I also
> seriously checked Qt, and this licence/fees put me off from that
> straight away. ok, posssible they have changed rules....
to choose LGPL license since 14 January 2009, version 4.5. 6 years have
passed meanwhile. It still does not mean you are lying, simply wrong.
> There was a reason why I did not even try Qt.. one was its future and
> other one the licence.... maybe they changed things.
wrong or outdated paper somewhere.
JiiPee
Feb 21, 2015, 2:28:08 PM2/21/15
to
there was that kind of information.
Maybe somebody on forum or something said also "Qt s future is not
certain".
Ok, let me quickly try to google it again....
Mr Flibble
Feb 21, 2015, 2:44:49 PM2/21/15
to
your source code; I don't think you can get away with shipping .o files.
/Flibble
Öö Tiib
Feb 21, 2015, 3:32:54 PM2/21/15
to
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
: Essentially, if it is a "work that uses the library", then it must
: be possible for the software to be linked with a newer version of
: the LGPL-covered program. The most commonly used method for doing
: so is to use "a suitable shared library mechanism for linking".
: Alternatively, a statically linked library is allowed if either
: source code or linkable object files are provided.
Jens Thoms Toerring
Feb 21, 2015, 3:45:14 PM2/21/15
to
Melzzzzz <m...@zzzzz.com> wrote:
> You can use Qt for free and sell commercial application, I think.
There are two licenses for Qt, one is a commercial license,
> You can use Qt for free and sell commercial application, I think.
and the other is the LGPL. Under the LGPL you must distribute
your program in a way that allows the user (potentially the
buyer) to relink it with other versions of the library under
the LGPL. So, for example, if you use Qt version 4.x for
ypur program the user must hav th possibility to link it in-
stead against Qt version 5.y. The user may have good reasons
for that, e.g. because he wants to use bug fixes, new features
etc. This can be definitely a problem for a commercial program
since too many things may depend on properties of t version
4.x. But if your "crown jewels" aren't in the GUI of the pro-
gram but can be separated from it (as well-written programs
often allow), there's nothing that keeps you from putting
those "crown jewels" e.g. into a shared, closed source li-
brary (which doesn't make any use of Qt) and distribute the
GUI part as open source, allowing all kinds of modifications
to adapt it to use other versions of Qt. What you need is, of
course, a clean interface betwen the library that does the
interesting stuff and the GUI part.
Thus, if you distribute a program whose main appeal is
in eye candy then you need to pay for Qt to keep it secret
- which sounds reasonable to me since the Qt guys put lots
of work into making it simple for you to write it in a plat-
form-independent way. If, on the other hand, the important
part of your program isn't in the graphics domain, you're
free to keep that secret and only expose those parts that
are the graphical user interface for using it - and allow
users to fiddle with that part for their own amusement
(but they can't legally distribute the "core" library with
your "intellectual property" without which their modifica-
tions to the GUI are rather useless). On the other hand, if
someone comes up with a much better GUI than yourself and
distributes it, it may make your commercial library even
more interesting for potential customers who know that there
is a nice replacement for your less than stellar attemot at
cobbling together a GUI. Basically a win-win situation;-)
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Mr Flibble
Feb 21, 2015, 3:45:14 PM2/21/15
to
like to withhold a part of it.
/Flibble
Jens Thoms Toerring
Feb 21, 2015, 5:03:34 PM2/21/15
to
JiiPee <n...@notvalid.com> wrote:
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
As some others have pointed out it adds an additipnal burden
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
because in a tutorial you now also have to explain how UTF-8
works, which distracts from what is the topic.
The std::string method length() doesn't stop working when you
use UTF-8 - of course dependent on what you call "work". It still
tells you ow many bytes the string occupies. What it doesn't do
anymore is telling you how many "letters" (or "glyphs" or what-
ever name you prefer - I try to avoid the word character since
it's too easily confused with the concept of a 'char') are con-
tained in the string. As you know UTF-8 a "letter" can be re-
presented by anything between 1 to 4 bytes. Thus you can't
equate "number of bytes" to "number of ;etters" anymore, as
has been traditionally done with ASCII. So you need a new
function for counting those "letters". Fortunately, writing
that isn't too hard: By inspecting the upper bits of the first
byte you can easily determine how many bytes that "letter"
occupies, which makes iterating over a string to count the
number of letters relatively simple.
There are a few pitfalls, though: not all 1 to 4 byte long
byte sets are valid UTf-8 entities, so, if you deal with
external input, you must check for that possibility and
design some strategy of dealing with such cases.
An imprtant aspect is dealing with the environment: if, for
example, the users keybooard is set up to send LATIN1 en-
coded charcters but you're expecting UTF-8 input that will
end in grief. Or when the output medium is set up to use a
different encoding than what your program emits the output
will look rather strange. So you will have to spend some
time giving more attention to locale settings etc. which in
a pure ASCII world usually are taken to be arcane stuff.
Another aspect is that, if you're serious about it, have
to start thinking about questions like: how do I enter
Chinese or Japanese or Greek etc. characters using a
standard US-English keyboard (or what tools does my
system supply for that purpose).
Dealing with UTF-8 in a program actually is relatively trivial
- you have to distinguish between byte count and letter count,
you should check if the input is "legal UTF-8 and you may have
to write some UTF-8 aware iterator when looping over a string
(so it gives you the next letter, not the next 'char') etc.
And, if this is for an already existing application, you'll
have to check whereever strings are used if what you want is
the "length" in bytes or in "letters".
I've recently done the switch from pure ASCII to UTF-8 for
a legacy library back from about 20 years ago. I've dragged
my feet for a long time doing that since I always thought that
"char-count equals letter count" would be that deep-rooted in
a piece of software that old that it would be nearly impossible
to fix that basic assumption. But, when I finally made the at-
tempt I was positively surprised that it was a lot easier than
I'd ever imagined - in most places dealing with strings it was
immediately clear if this was about the letters or bytes in a
string and, with a few functions for dealing with UTF-8, it took
me a very short time.
From that experience I tend to conclude that most pf the "angst"
about UTF-8 is more from unfamilarity than anything else. The
actual problems are often more the enviroment the user is wor-
king in - if the keyboard is set up to send LATIN1 or CJK or
whatever other legacy encoding, then there's were the real pro-
blems are. So, it's a new world definitely, and one has to
learn a few new things and become aware of a new potential
problems (and existing solutions;-).
I can only recommend to do a few experiments with some "toy"
programs. The concept behind UTF-8 is IMHO, while ingenious,
surprisingly simple, so I found it more helpful to write a few
functions for counting "letters" in a string or detecting in-
valid byte sequences than trying to understand some rather
complex libraries that do all the work for you. Not that I'd
consider those libaries to be useless, but to understand what
they're doing for you it's good to have spend a bit of time
trying to solve the simpler problems to get a feel of what's
involved - otherwise the documentation can often hard to un-
derstand;-)
Best regards, Jens
Mr Flibble
Feb 21, 2015, 5:10:09 PM2/21/15
to
On 21/02/2015 22:03, Jens Thoms Toerring wrote:
> From that experience I tend to conclude that most pf the "angst"
> about UTF-8 is more from unfamilarity than anything else. The
> actual problems are often more the enviroment the user is wor-
> king in - if the keyboard is set up to send LATIN1 or CJK or
> whatever other legacy encoding, then there's were the real pro-
In my experience keyboards send scan codes not characters; the OS
> From that experience I tend to conclude that most pf the "angst"
> about UTF-8 is more from unfamilarity than anything else. The
> actual problems are often more the enviroment the user is wor-
> king in - if the keyboard is set up to send LATIN1 or CJK or
> whatever other legacy encoding, then there's were the real pro-
translates scan codes into characters.
/Flibble
Chris Vine
Feb 21, 2015, 5:13:11 PM2/21/15
to
On 21 Feb 2015 20:45:02 GMT
those who purport to know, if you use static linking you are probably in
trouble and you may be required to distribute your code under the LGPL
if you distribute outside your organisation. If you use dynamic
linking you are generally OK. The requirement in such cases is that
your code must be relinkable against a different library (such as one
you yourself write) with the same ABI, which is a criterion met by all
current Windows and unix dynamic linking mechanisms. There is no
requirement for portability to different non-ABI compatible versions of
a particular library - that would serve no purpose.
The legal issue behind this is apparently whether you "use" the library
(OK) or if you are a derived work (you might be in trouble). Dynamic
linking seems to be regarded as the former. Static linking, or
extending the particular library itself for your own purposes, seems to
be regarded as the latter.
Chris
j...@toerring.de (Jens Thoms Toerring) wrote:
> Melzzzzz <m...@zzzzz.com> wrote:
> > You can use Qt for free and sell commercial application, I think.
>
> There are two licenses for Qt, one is a commercial license,
> and the other is the LGPL. Under the LGPL you must distribute
> your program in a way that allows the user (potentially the
> buyer) to relink it with other versions of the library under
> the LGPL. So, for example, if you use Qt version 4.x for
> ypur program the user must hav th possibility to link it in-
> stead against Qt version 5.y.
I think that's probably wrong. As it has been explained to me by
> Melzzzzz <m...@zzzzz.com> wrote:
> > You can use Qt for free and sell commercial application, I think.
>
> There are two licenses for Qt, one is a commercial license,
> and the other is the LGPL. Under the LGPL you must distribute
> your program in a way that allows the user (potentially the
> buyer) to relink it with other versions of the library under
> the LGPL. So, for example, if you use Qt version 4.x for
> ypur program the user must hav th possibility to link it in-
> stead against Qt version 5.y.
those who purport to know, if you use static linking you are probably in
trouble and you may be required to distribute your code under the LGPL
if you distribute outside your organisation. If you use dynamic
linking you are generally OK. The requirement in such cases is that
your code must be relinkable against a different library (such as one
you yourself write) with the same ABI, which is a criterion met by all
current Windows and unix dynamic linking mechanisms. There is no
requirement for portability to different non-ABI compatible versions of
a particular library - that would serve no purpose.
The legal issue behind this is apparently whether you "use" the library
(OK) or if you are a derived work (you might be in trouble). Dynamic
linking seems to be regarded as the former. Static linking, or
extending the particular library itself for your own purposes, seems to
be regarded as the latter.
Chris
Jens Thoms Toerring
Feb 21, 2015, 5:29:07 PM2/21/15
to
That was why I first wrote about the user's "environment" before
using the more colloquial "the kevboard is set up to send..." as
a shortcut for "the keyboard sends scan codes, which the OS (and
maybe even some other intermediaries) translates into something
which finally arrives at the application". Getting a grip on that
is, as far as I see it, often the hardest part, not the actual
dealing with UTF-8 encoded strings.
Jens Thoms Toerring
Feb 21, 2015, 5:54:22 PM2/21/15
to
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> On 21 Feb 2015 20:45:02 GMT
> j...@toerring.de (Jens Thoms Toerring) wrote:
> > Melzzzzz <m...@zzzzz.com> wrote:
> > > You can use Qt for free and sell commercial application, I think.
> >
> > There are two licenses for Qt, one is a commercial license,
> > and the other is the LGPL. Under the LGPL you must distribute
> > your program in a way that allows the user (potentially the
> > buyer) to relink it with other versions of the library under
> > the LGPL. So, for example, if you use Qt version 4.x for
> > ypur program the user must hav th possibility to link it in-
> > stead against Qt version 5.y.
> I think that's probably wrong. As it has been explained to me by
> those who purport to know, if you use static linking you are probably in
> trouble and you may be required to distribute your code under the LGPL
> if you distribute outside your organisation.
I don't see your point here since with static linking you'd
> On 21 Feb 2015 20:45:02 GMT
> j...@toerring.de (Jens Thoms Toerring) wrote:
> > Melzzzzz <m...@zzzzz.com> wrote:
> > > You can use Qt for free and sell commercial application, I think.
> >
> > There are two licenses for Qt, one is a commercial license,
> > and the other is the LGPL. Under the LGPL you must distribute
> > your program in a way that allows the user (potentially the
> > buyer) to relink it with other versions of the library under
> > the LGPL. So, for example, if you use Qt version 4.x for
> > ypur program the user must hav th possibility to link it in-
> > stead against Qt version 5.y.
> I think that's probably wrong. As it has been explained to me by
> those who purport to know, if you use static linking you are probably in
> trouble and you may be required to distribute your code under the LGPL
> if you distribute outside your organisation.
definitely make it impossible to link with a new version of
the LGPL'ed linrary. Static linking is a no-no in this case.
> If you use dynamic linking you are generally OK. The
> requirement in such cases is that your code must be relinkable
> against a different library (such as one you yourself write) with
> the same ABI, which is a criterion met by all current Windows and
> unix dynamic linking mechanisms. There is no requirement for
> portability to different non-ABI compatible versions of a
> particular library - that would serve no purpose.
> The legal issue behind this is apparently whether you "use" the library
> (OK) or if you are a derived work (you might be in trouble). Dynamic
> linking seems to be regarded as the former. Static linking, or
> extending the particular library itself for your own purposes, seems to
> be regarded as the latter.
whatever version of Qt (or whatever other LGPL library this is
about) by giving the user all the bits s/he needs to make that
possible (including the parts of the sources that rely on wor-
king with the LGPL library) is the most honest way to go. What
that doesn't exclude is having another dynamically linked but
closed source library you actually demand money for, and which
doesn't depend on any services of the LGPL'ed library (so there
is not the least bit of doubt that there's no "deriving" going
on) - but which does the really interesting bits of work that
make it something people may be motivated to pay for.
Best regards, Jens
Jens Thoms Toerring
Feb 21, 2015, 6:05:51 PM2/21/15
to
Mr Flibble <flibbleREM...@i42.co.uk> wrote:
while Trolltech -> Nokia -> Digia stopping supporting fur-
ther development can be a major issue, it's not necessarily
the end of the world as we know it. The KDE guys rely on it
heavily and while they probably don't have tons of money they
still would have a big incentive to keep it alive. In that
(hypothetical) case questions about the future of cross-plat-
form compatibility might arise, but we're not at that point
yet, I hope...
> On 21/02/2015 18:23, JiiPee wrote:
> > I read that Qt does not have anymore support properly as the old company
> > who supported it stopped supporting it....
> Wrong; Qt was sold to Digia which and is alive and well and continually
> supported/updated.
And there's also that thingy that Qt is open-source - so
> > I read that Qt does not have anymore support properly as the old company
> > who supported it stopped supporting it....
> Wrong; Qt was sold to Digia which and is alive and well and continually
> supported/updated.
while Trolltech -> Nokia -> Digia stopping supporting fur-
ther development can be a major issue, it's not necessarily
the end of the world as we know it. The KDE guys rely on it
heavily and while they probably don't have tons of money they
still would have a big incentive to keep it alive. In that
(hypothetical) case questions about the future of cross-plat-
form compatibility might arise, but we're not at that point
yet, I hope...
Chris Vine
Feb 21, 2015, 6:14:11 PM2/21/15
to
On 21 Feb 2015 22:54:12 GMT
Chris
j...@toerring.de (Jens Thoms Toerring) wrote:
[snip]
> Sorry, you've lost me here;-) In my book saying: link it against
> whatever version of Qt (or whatever other LGPL library this is
> about) by giving the user all the bits s/he needs to make that
> possible (including the parts of the sources that rely on wor-
> king with the LGPL library) is the most honest way to go. What
> that doesn't exclude is having another dynamically linked but
> closed source library you actually demand money for, and which
> doesn't depend on any services of the LGPL'ed library (so there
> is not the least bit of doubt that there's no "deriving" going
> on) - but which does the really interesting bits of work that
> make it something people may be motivated to pay for.
I believe you are deranged.
> whatever version of Qt (or whatever other LGPL library this is
> about) by giving the user all the bits s/he needs to make that
> possible (including the parts of the sources that rely on wor-
> king with the LGPL library) is the most honest way to go. What
> that doesn't exclude is having another dynamically linked but
> closed source library you actually demand money for, and which
> doesn't depend on any services of the LGPL'ed library (so there
> is not the least bit of doubt that there's no "deriving" going
> on) - but which does the really interesting bits of work that
> make it something people may be motivated to pay for.
Chris
Jens Thoms Toerring
Feb 21, 2015, 6:26:41 PM2/21/15
to
Would you care to elaborate a bit about were you consider me
to be completely wrong?
Regards, Jens
Richard Damon
Feb 21, 2015, 6:32:38 PM2/21/15
to
On 2/21/15 10:05 AM, JiiPee wrote:
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
>
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
>
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
>
> Everybody say that we should use unicode in our code. If so, then why
> all turorials and C++ books use almost always char as a character type
> (1 byte)? Why use examples which are not used in real world? This I do
> not understand.
>
> And even top C++ people like Bjorn does that.
There are some subtle issues with using unicode, which if you are doing
a simple tutorial may not be important.
Things like what do you mean by the length() function, if you want to
know how much storage it take, it works just fine with Unicode. If you
want to know how many characters have been displayed, this is actually
quite tricky in Unicode (Even using UTF-32/UCS-4 doesn't save you as
there are combining code points to allow you to build some glyphs that
don't have an assigned code point).
It actually turns out that much code written for Ascii, will just work
for UTF-8 encoded unicode by following just a few basic guidelines
(things like you need to handle the high bit of the character set, which
might cause issues with signed char, and you need to manipulate strings
at "known" points so you don't break apart multi-byte sequences, and you
can't assume that N bytes are N characters).
UTF-16 is mostly just used in Microsoft environments, and actually is
mostly a mistake. They adopted it when Unicode thought 16 bits were
going to be "big enough", and when the changed their mind UTF-16 became
an awkward orphan, it normally takes more space than UTF-8, and you
still need to worry about multi-unit characters (only the exceptions are
much rarer so you might not catch the problem in testing). If I remember
right, UTF-16 might make sense in the case of some asian languages,
where most "characters" will take 1 unit (2 bytes) in UTF-16, but might
take 3 in UTF-8.
Kai Bojens
Feb 22, 2015, 6:50:25 AM2/22/15
to
JiiPee <n...@notvalid.com> wrote:
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
A very good starting point:
> I am trying to learn how to use unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/unicode-cpp.pdf
JiiPee
Feb 22, 2015, 7:11:22 AM2/22/15
to
In many of these sites they have theories but no practical examples...
not really a good way to teach things. When I read C++ books the
examples tell me almost everything even without knowing the theory!!
Thats why I many times read first the examples and after that the theory
becouse then I also undertand the theory.
Thats what is really needed with these. But lets see if it has enough
examples.... it has some....
JiiPee
Feb 22, 2015, 7:14:12 AM2/22/15
to
he seems to be from Finland... even that (me also) :)
On 22/02/2015 11:42, Kai Bojens wrote:
On 22/02/2015 11:42, Kai Bojens wrote:
Lőrinczy Zsigmond
Feb 22, 2015, 7:53:01 AM2/22/15
to
On 2015.02.21. 16:05, JiiPee wrote:> I am trying to learn how to use
mbslen returns the number of characters.
unicode string.. its not so easy really.
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
When using utf8, strlen does work, it returns the number of bytes;
> And difficult to find a guidelines how to do it. So still searching
> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make
> life difficult as many functions like lenght would not work).
mbslen returns the number of characters.
David Brown
Feb 22, 2015, 11:42:42 AM2/22/15
to
that the other posters here have given you accurate information, or go
to the QT website and read their licensing information.
QT has changed hands a couple of times - as is usual in such cases, this
lead to lots of rumours about its demise, or the demise of the open
source licences for QT. And since QT was originally commercial-only,
then commercial+GPL, there is an abundance of old and outdated posts and
websites that do not know about the LGPL version.
Nobody
Feb 22, 2015, 7:24:16 PM2/22/15
to
On Sat, 21 Feb 2015 16:09:41 +0000, JiiPee wrote:
>> Do NOT use UTF-16 as it is useless (it is a variable length encoding
>> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
>> best as most common text is Latin) or UTF-32.
>>
>> /Flibble
>
> Yes like this maybe in non-Windows programming. But.... you know Windows
> uses UTF-16
Windows uses arrays of wchar_t. Whether those represent UTF-16 or UCS-2
>> Do NOT use UTF-16 as it is useless (it is a variable length encoding
>> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
>> best as most common text is Latin) or UTF-32.
>>
>> /Flibble
>
> Yes like this maybe in non-Windows programming. But.... you know Windows
> uses UTF-16
is ... underspecified to say the least. In practical terms, if the data
contains any surrogates, all bets are off.
Mr Flibble
Feb 22, 2015, 7:25:29 PM2/22/15
to
/Flibble
Robert Wessel
Feb 23, 2015, 3:12:40 AM2/23/15
to
but it wasn't that long ago some ancillary bits (notepad, for
example), didn't. But there is much Windows software that does not.
Christopher Pisz
Feb 23, 2015, 11:25:12 AM2/23/15
to
On 2/21/2015 12:23 PM, JiiPee wrote:
> On 21/02/2015 17:33, Mr Flibble wrote:
>> On 21/02/2015 16:39, JiiPee wrote:
>>> On 21/02/2015 16:30, Mr Flibble wrote:
>>>> On 21/02/2015 16:09, JiiPee wrote:
>>>>> On 21/02/2015 15:17, Mr Flibble wrote:
>>>>> do currently. Visual C++ recommends using UTF-16 for sure and its used
>>>>> there so I guess its better to use it there. Obviously programs come
>>>>> when I save my string to file using my std-based C++ classes I made.
>>>>> Well, need to convert I guess...
>>>>>
>>>>> But... why do books teach strings using char-type (non-unicode)?
>>>>
>>>> Don't use MFC as it is a complete and utter bag of ancient shite; use
>>>> something like Qt instead (although Qt also fucktardedly uses UTF-16).
>>>>
>>>> /Flibble
>>>
>>> I was actually using wxWidgets last year, but now turned back to MFC as
>>> they give VC++ now for free.... I cannot resist going back now :) .
>>
>> wxWidgets is also shite as it is similar to MFC; you really should
>> give Qt a go as it is very good (and works with VC++).
>>
>> /Flibble
To create new UI targeting Windows only, using any C++ framework is also
retarded.
Use .NET and WPF, or a web client. Get your UI done in 1/200th of the
time. This is what every company targeting Windows that I've worked at
for the last 5 years has done.
You don't need a high performance, low level control language to wait an
eon for a user to press a button.
> On 21/02/2015 17:33, Mr Flibble wrote:
>> On 21/02/2015 16:39, JiiPee wrote:
>>> On 21/02/2015 16:30, Mr Flibble wrote:
>>>> On 21/02/2015 16:09, JiiPee wrote:
>>>>> On 21/02/2015 15:17, Mr Flibble wrote:
>>>>>> On 21/02/2015 15:05, JiiPee wrote:
>>>>>>> I am trying to learn how to use unicode string.. its not so easy
>>>>>>> really.
>>>>>>> And difficult to find a guidelines how to do it. So still searching
>>>>>>> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would
>>>>>>> make
>>>>>>> life difficult as many functions like lenght would not work).
>>>>>>>
>>>>>>> I am trying to learn how to use unicode string.. its not so easy
>>>>>>> really.
>>>>>>> And difficult to find a guidelines how to do it. So still searching
>>>>>>> (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would
>>>>>>> make
>>>>>>> life difficult as many functions like lenght would not work).
>>>>>>>
>>>>>>> Everybody say that we should use unicode in our code. If so, then
>>>>>>> why
>>>>>>> all turorials and C++ books use almost always char as a character
>>>>>>> type
>>>>>>> (1 byte)? Why use examples which are not used in real world? This
>>>>>>> I do
>>>>>>> not understand.
>>>>>>>
>>>>>>> And even top C++ people like Bjorn does that.
>>>>>>
>>>>>>> why
>>>>>>> all turorials and C++ books use almost always char as a character
>>>>>>> type
>>>>>>> (1 byte)? Why use examples which are not used in real world? This
>>>>>>> I do
>>>>>>> not understand.
>>>>>>>
>>>>>>> And even top C++ people like Bjorn does that.
>>>>>>
>>>>>> Do NOT use UTF-16 as it is useless (it is a variable length encoding
>>>>>> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
>>>>>> best as most common text is Latin) or UTF-32.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Yes like this maybe in non-Windows programming. But.... you know
>>>>> Windows
>>>>> uses UTF-16 and here I am talking about Windows/MFC programming what I
>>>>>> like UTF-8 so offers no advantage over UTF-8); instead use UTF-8 (the
>>>>>> best as most common text is Latin) or UTF-32.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Yes like this maybe in non-Windows programming. But.... you know
>>>>> Windows
>>>>> do currently. Visual C++ recommends using UTF-16 for sure and its used
>>>>> there so I guess its better to use it there. Obviously programs come
>>>>> when I save my string to file using my std-based C++ classes I made.
>>>>> Well, need to convert I guess...
>>>>>
>>>>> But... why do books teach strings using char-type (non-unicode)?
>>>>
>>>> Don't use MFC as it is a complete and utter bag of ancient shite; use
>>>> something like Qt instead (although Qt also fucktardedly uses UTF-16).
>>>>
>>>> /Flibble
>>>
>>> I was actually using wxWidgets last year, but now turned back to MFC as
>>> they give VC++ now for free.... I cannot resist going back now :) .
>>
>> wxWidgets is also shite as it is similar to MFC; you really should
>> give Qt a go as it is very good (and works with VC++).
>>
>> /Flibble
>
> I read that Qt does not have anymore support properly as the old company
> who supported it stopped supporting it....
To create any new software using MFC is idiocy.
> I read that Qt does not have anymore support properly as the old company
> who supported it stopped supporting it....
To create new UI targeting Windows only, using any C++ framework is also
retarded.
Use .NET and WPF, or a web client. Get your UI done in 1/200th of the
time. This is what every company targeting Windows that I've worked at
for the last 5 years has done.
You don't need a high performance, low level control language to wait an
eon for a user to press a button.
Mr Flibble
Feb 23, 2015, 12:24:47 PM2/23/15
to
are *currently* targeting Windows doesn't mean you shouldn't use a
cross-platform GUI framework. Why? One word: flexibility.
/Flibble
Mr Flibble
Feb 23, 2015, 12:25:55 PM2/23/15
to
/Flibble
Christopher Pisz
Feb 23, 2015, 2:05:32 PM2/23/15
to
Employers just love paying for months of man hours to support other
platforms they told you up front they will never target...
I'm sure everyone you work with would also love to review and maintain
5000 lines of code that accomplishes what XAML will in 10.
Chris Vine
Feb 23, 2015, 3:38:49 PM2/23/15
to
On Mon, 23 Feb 2015 13:05:20 -0600
Christopher Pisz <nos...@notanaddress.com> wrote:
> On 2/23/2015 11:24 AM, Mr Flibble wrote:
> > On 23/02/2015 16:25, Christopher Pisz wrote:
[snip]
Christopher Pisz <nos...@notanaddress.com> wrote:
> On 2/23/2015 11:24 AM, Mr Flibble wrote:
> > On 23/02/2015 16:25, Christopher Pisz wrote:
> >> To create any new software using MFC is idiocy.
> >> To create new UI targeting Windows only, using any C++ framework
> >> is also retarded.
> >>
> >> Use .NET and WPF, or a web client. Get your UI done in 1/200th of
> >> the time. This is what every company targeting Windows that I've
> >> worked at for the last 5 years has done.
> >>
> >> You don't need a high performance, low level control language to
> >> wait an eon for a user to press a button.
> >
> > More bullshit mate, you really ought to try harder. Just because
> > you are *currently* targeting Windows doesn't mean you shouldn't
> > use a cross-platform GUI framework. Why? One word: flexibility.
> >
> > /Flibble
> >
>
> Is cross platform a religion of yours?
>
> Employers just love paying for months of man hours to support other
> platforms they told you up front they will never target...
>
> I'm sure everyone you work with would also love to review and
> maintain 5000 lines of code that accomplishes what XAML will in 10.
I think you looking at this the wrong way around, perhaps to be
> >> To create new UI targeting Windows only, using any C++ framework
> >> is also retarded.
> >>
> >> Use .NET and WPF, or a web client. Get your UI done in 1/200th of
> >> the time. This is what every company targeting Windows that I've
> >> worked at for the last 5 years has done.
> >>
> >> You don't need a high performance, low level control language to
> >> wait an eon for a user to press a button.
> >
> > More bullshit mate, you really ought to try harder. Just because
> > you are *currently* targeting Windows doesn't mean you shouldn't
> > use a cross-platform GUI framework. Why? One word: flexibility.
> >
> > /Flibble
> >
>
> Is cross platform a religion of yours?
>
> Employers just love paying for months of man hours to support other
> platforms they told you up front they will never target...
>
> I'm sure everyone you work with would also love to review and
> maintain 5000 lines of code that accomplishes what XAML will in 10.
contentious and make one of your sometimes (but not always) misaligned
points.
You choose C++ for a program because it fits the problem domain
(primarily, efficiency). If the program happens to have a GUI
interface, it is of secondary importance. If it happens to use a
GUI, you choose whatever seems best to you at the time, of which there
are several options.
If a program has such a complex GUI interface that programming it in
C++ is a significant impediment to a return on investment, it is
probably not a program where C++ is the correct solution to begin
with. So you are writing a piece of consumer krapware which you chuck
out as fast as you can? Then by all means use .NET, C# and XAML[1]. (I
like C# by the way, it is good for some things which don't have a
complex GUI and are not krapware also.)
Chris
[1] Qt, GTK+ (and so wxWidgets) and no doubt other toolkits have their
own version of XAML (QML and GtkBuilder respectively).
Christopher Pisz
Feb 23, 2015, 7:04:02 PM2/23/15
to
> If it happens to use a
> GUI, you choose whatever seems best to you at the time, of which there
> are several options.
>
> If a program has such a complex GUI interface that programming it in
> C++ is a significant impediment to a return on investment, it is
> probably not a program where C++ is the correct solution to begin
> with.
more suited for GUI then using another framework in C++.
> So you are writing a piece of consumer krapware which you chuck
> out as fast as you can?
anything made with .NET and XAML as krapware, then at least provide the
factors that make it fall into such a category.
Rapid development is not the only factor. Size, maintainability,
extendability all compare better. But none the less, put 50 managers in
a room and ask them to vote on what the number one thing is that is they
are looking for.
Development time is not usually the most important thing to me
personally, but it certainly is, and a lot of the time wrongfully so, to
almost every employer.
JiiPee
Feb 24, 2015, 2:20:52 AM2/24/15
to
On 24/02/2015 00:03, Christopher Pisz wrote:
>
>
>> If it happens to use a
>> GUI, you choose whatever seems best to you at the time, of which there
>> are several options.
>>
>> If a program has such a complex GUI interface that programming it in
>> C++ is a significant impediment to a return on investment, it is
>> probably not a program where C++ is the correct solution to begin
>> with.
>
> Complex or simple, it doesn't matter. There are other technologies far
> more suited for GUI then using another framework in C++.
>
>> So you are writing a piece of consumer krapware which you chuck
>> out as fast as you can?
>
> Where does your krapware qualifier come from? If you are going to
> label anything made with .NET and XAML as krapware, then at least
> provide the
> factors that make it fall into such a category.
>
> Rapid development is not the only factor. Size, maintainability,
> extendability all compare better. But none the
I think this is true.
>
>
>> If it happens to use a
>> GUI, you choose whatever seems best to you at the time, of which there
>> are several options.
>>
>> If a program has such a complex GUI interface that programming it in
>> C++ is a significant impediment to a return on investment, it is
>> probably not a program where C++ is the correct solution to begin
>> with.
>
> Complex or simple, it doesn't matter. There are other technologies far
> more suited for GUI then using another framework in C++.
>
>> So you are writing a piece of consumer krapware which you chuck
>> out as fast as you can?
>
> Where does your krapware qualifier come from? If you are going to
> label anything made with .NET and XAML as krapware, then at least
> provide the
> factors that make it fall into such a category.
>
> Rapid development is not the only factor. Size, maintainability,
> extendability all compare better. But none the
> less, put 50 managers in a room and ask them to vote on what the
> number one thing is that is they are looking for.
>
> Development time is not usually the most important thing to me
> personally, but it certainly is, and a lot of the time wrongfully so,
> to almost every employer.
quality code and use a lot of time for it or make the code fast so that
its just working and we get the product quickly out. His response was
more like "make it fast". Well, not sure if this small company was the
most professional but thats what they pushed a lot: making things fast
was priority all the time. I wanted to do things nicely and use my time,
but that was not really what they wanted.
Chris Vine
Feb 24, 2015, 7:13:21 AM2/24/15
to
On Mon, 23 Feb 2015 18:03:46 -0600
Christopher Pisz <nos...@notanaddress.com> wrote:
> On 2/23/2015 2:38 PM, Chris Vine wrote:
[snip]
Christopher Pisz <nos...@notanaddress.com> wrote:
> On 2/23/2015 2:38 PM, Chris Vine wrote:
> > If it happens to use a
> > GUI, you choose whatever seems best to you at the time, of which
> > there are several options.
> >
> > If a program has such a complex GUI interface that programming it in
> > C++ is a significant impediment to a return on investment, it is
> > probably not a program where C++ is the correct solution to begin
> > with.
>
> Complex or simple, it doesn't matter. There are other technologies
> far more suited for GUI then using another framework in C++.
You misunderstand my point. If your program is written in C++ because
> > GUI, you choose whatever seems best to you at the time, of which
> > there are several options.
> >
> > If a program has such a complex GUI interface that programming it in
> > C++ is a significant impediment to a return on investment, it is
> > probably not a program where C++ is the correct solution to begin
> > with.
>
> Complex or simple, it doesn't matter. There are other technologies
> far more suited for GUI then using another framework in C++.
that best suits what you are doing, then you choose a C++ framework for
the GUI, if there is one. You don't write part of the program as
native code in C++ and part on the .NET VM for the GUI (I don't even
think you can do that can you?). The point I am making is that you
don't decide what language to write a project in just by deciding what
is the best language for the GUI, if there is a GUI, unless the program
is very particularly and strongly GUI orientated.
We both agree development time is a very important factor. You think
in consequence that having to write a GUI in C++ is _the_ (or at least
_a major_) deciding factor against using C++ in a large number of cases.
I don't. Where .NET is used, it is for numerous other reasons as
well. For example, for a language running on a VM where that is what
you want, it is a nice piece of kit.
> > So you are writing a piece of consumer krapware which you chuck
> > out as fast as you can?
>
> Where does your krapware qualifier come from? If you are going to
> label anything made with .NET and XAML as krapware, then at least
> provide the factors that make it fall into such a category.
krapware", as should be completely obvious from my following words in
parenthesis. (Nor for that matter did I label what you were doing as
krapware, if that is what your rearrangement of the text was intended
to suggest. The "you" is a generic one. I have no idea what you are
doing.)
Chris
Christopher Pisz
Feb 24, 2015, 11:23:10 AM2/24/15
to
On 2/24/2015 6:12 AM, Chris Vine wrote:
> On Mon, 23 Feb 2015 18:03:46 -0600
> Christopher Pisz <nos...@notanaddress.com> wrote:
>> On 2/23/2015 2:38 PM, Chris Vine wrote:
> [snip]
>>> If it happens to use a
>>> GUI, you choose whatever seems best to you at the time, of which
>>> there are several options.
>>>
>>> If a program has such a complex GUI interface that programming it in
>>> C++ is a significant impediment to a return on investment, it is
>>> probably not a program where C++ is the correct solution to begin
>>> with.
>>
>> Complex or simple, it doesn't matter. There are other technologies
>> far more suited for GUI then using another framework in C++.
>
> You misunderstand my point. If your program is written in C++ because
> that best suits what you are doing, then you choose a C++ framework for
> the GUI, if there is one. You don't write part of the program as
> native code in C++ and part on the .NET VM for the GUI (I don't even
> think you can do that can you?).
> The point I am making is that you
> don't decide what language to write a project in just by deciding what
> is the best language for the GUI, if there is a GUI, unless the program
> is very particularly and strongly GUI orientated.
Perhaps this is where your differing point of view is coming from. If
> On Mon, 23 Feb 2015 18:03:46 -0600
> Christopher Pisz <nos...@notanaddress.com> wrote:
>> On 2/23/2015 2:38 PM, Chris Vine wrote:
> [snip]
>>> If it happens to use a
>>> GUI, you choose whatever seems best to you at the time, of which
>>> there are several options.
>>>
>>> If a program has such a complex GUI interface that programming it in
>>> C++ is a significant impediment to a return on investment, it is
>>> probably not a program where C++ is the correct solution to begin
>>> with.
>>
>> Complex or simple, it doesn't matter. There are other technologies
>> far more suited for GUI then using another framework in C++.
>
> You misunderstand my point. If your program is written in C++ because
> that best suits what you are doing, then you choose a C++ framework for
> the GUI, if there is one. You don't write part of the program as
> native code in C++ and part on the .NET VM for the GUI (I don't even
> think you can do that can you?).
> The point I am making is that you
> don't decide what language to write a project in just by deciding what
> is the best language for the GUI, if there is a GUI, unless the program
> is very particularly and strongly GUI orientated.
you are under the impression that you have to write the entire suite in
C# because you chose to do the GUI in C#, then I could see your
distaste. However, that is not the case. Yes, a C# GUI can communicate
to C++ and that is exactly what I am suggesting. This could be a local
application or on the web. There is some downside though in a few
scenarios. Often you have to duplicate some part of the domain on both
sides. There are frameworks that can eliminate that through generated code.
Mr Flibble
Feb 24, 2015, 1:23:53 PM2/24/15
to
ware; I have done this and it is a fucking nightmare to maintain; not
worth the effort just so you can use the krapware which is XAML (which
is a nightmare to debug).
C# is for lazy cunts who cannot survive without a garbage collector.
Sausages.
/Flibble
Christopher Pisz
Feb 24, 2015, 2:59:24 PM2/24/15
to
trolling. Soap, REST, COM, your own RPC, sockets, and a myriad of other
options exist to communicate between _native_ C++ and C#.
Debug XAML? That's like debugging HTML rather than the javascript it
contains, it makes no sense. Maybe you mean debugging your bindings.
Mr Flibble
Feb 24, 2015, 3:05:00 PM2/24/15
to
process? You've fallen out of your tree mate.
>
> Debug XAML? That's like debugging HTML rather than the javascript it
> contains, it makes no sense. Maybe you mean debugging your bindings.
errors.
/Flibble
Daniel
Feb 24, 2015, 3:14:10 PM2/24/15
to
On Tuesday, February 24, 2015 at 1:23:53 PM UTC-5, Mr Flibble wrote:
>
> C# is for lazy cunts who cannot survive without a garbage collector.
>
The sausage is big, but its skin is even bigger.
>
> C# is for lazy cunts who cannot survive without a garbage collector.
>
Daniel
Christopher Pisz
Feb 24, 2015, 3:22:21 PM2/24/15
to
continue trolling. No one ever said anything about same process.
Quite often in the real world the UI is not in the same process and if
it is, there is nothing stopping anyone from separating it out. In fact,
it is better separated out for reasons you can Google yourself. If you
excelled at reading comprehension then you would have read the earlier
bits about the possibility of web client, etc.
I am sure you'll just continue on all day, so I'm gonna go ahead and
flip the filter on now. I responded for the sake of the OP, not to argue
for the next 10 hours with you yet again. It's a pointless waste of
time. You contribute nothing.
--
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
---
Mr Flibble
Feb 24, 2015, 3:29:36 PM2/24/15
to
application and the GUI which renders that model in the same process; to
do that with a C# GUI requires C++/CLI. If you are talking about
ordinary IPC between processes then you are not really talking about
interfacing between different languages. If your application is C++ and
you want a GUI in the same process then you would be a nutter if you
didn't use a C++ GUI framework such as Qt.
>
> Quite often in the real world the UI is not in the same process and if
> it is, there is nothing stopping anyone from separating it out. In fact,
> it is better separated out for reasons you can Google yourself. If you
> excelled at reading comprehension then you would have read the earlier
> bits about the possibility of web client, etc.
at work were designed with a GUI in a separate process; I wasn't talking
about IPC between different processes and I believe neither was Chris Vine.
>
> I am sure you'll just continue on all day, so I'm gonna go ahead and
> flip the filter on now. I responded for the sake of the OP, not to argue
> for the next 10 hours with you yet again. It's a pointless waste of
> time. You contribute nothing.
Sausages.
/Flibble
Richard
Feb 24, 2015, 3:57:02 PM2/24/15
to
[Please do not mail me a copy of your followup]
n...@notvalid.com spake the secret code
<_CVGw.969747$Ud7.2...@fx11.am4> thusly:
>I asked once my manager, back in 2000, that is it better to make good
>quality code and use a lot of time for it or make the code fast so that
>its just working and we get the product quickly out. His response was
>more like "make it fast".
The choice as you've described it is a false one. It isn't a choice
between fast and quality. It is a trade-off between scope, cost and
schedule where "quality" usually falls into the cost category.
See <https://en.wikipedia.org/wiki/Project_management_triangle>
Basically, you can have any two of scope, cost and schedule:
- (scope, cost) many features delivered later at high quality
- (cost, schedule) few features delivered quickly at high quality
- (scope, schedule) many features delivered quickly at low quality
In reality, noone wants to deliver low quality software, but they are
forced into doing it because they thought they could ignore the iron
triangle and thought that they could deliver a large scope product in
a short period of time. Often they think that simply having good
engineers is enough to accomplish this, but that is hubris.
I'm surprised how many managers and executives don't understand the
iron triangle. It could be simply because noone from the technical
team has ever bothered to explain it to them. In a worst case, you
have people who have succumbed to hubris and think somehow the iron
triangle doesn't apply to their company, project or team. Such
organizations will constantly "fail" in their objectives because when
you argue with reality, reality always wins no matter how good your
argument.
The best way to not be trapped by the iron triangle is to accept the
reality of it and plan accordingly. Again, since noone intentionally
sets out to deliver poor quality software, your choice is to balance
scope and schedule.
If you have a fixed scope, then allow the schedule to float.
If you have a fixed schedule, then allow the scope to float.
In both cases, your scope should be prioritized with the most
important business value appearing first on the list of things to do.
This means you work on all your "must haves" first with the "nice to
haves" being worked on later. (See the Kano model of customer
satisfaction <https://en.wikipedia.org/wiki/Kano_model>.)
If you do this, then you'll be delivering the most important value to
your business first and if you run out of time, the things that are
dropped are hopefully in the "nice to have" category. Even when you
operate with an assumption of a floating schedule, people get
impatient and they won't wait forever for you to develop the software.
Along the way you have to provide feedback to the stakeholders in your
project. The best way is to give periodic demonstrations of the
software showing the progress that's been made since the last demo.
This is closing the feedback loop between the development team and the
business team.
--
"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>
n...@notvalid.com spake the secret code
<_CVGw.969747$Ud7.2...@fx11.am4> thusly:
>I asked once my manager, back in 2000, that is it better to make good
>quality code and use a lot of time for it or make the code fast so that
>its just working and we get the product quickly out. His response was
>more like "make it fast".
between fast and quality. It is a trade-off between scope, cost and
schedule where "quality" usually falls into the cost category.
See <https://en.wikipedia.org/wiki/Project_management_triangle>
Basically, you can have any two of scope, cost and schedule:
- (scope, cost) many features delivered later at high quality
- (cost, schedule) few features delivered quickly at high quality
- (scope, schedule) many features delivered quickly at low quality
In reality, noone wants to deliver low quality software, but they are
forced into doing it because they thought they could ignore the iron
triangle and thought that they could deliver a large scope product in
a short period of time. Often they think that simply having good
engineers is enough to accomplish this, but that is hubris.
I'm surprised how many managers and executives don't understand the
iron triangle. It could be simply because noone from the technical
team has ever bothered to explain it to them. In a worst case, you
have people who have succumbed to hubris and think somehow the iron
triangle doesn't apply to their company, project or team. Such
organizations will constantly "fail" in their objectives because when
you argue with reality, reality always wins no matter how good your
argument.
The best way to not be trapped by the iron triangle is to accept the
reality of it and plan accordingly. Again, since noone intentionally
sets out to deliver poor quality software, your choice is to balance
scope and schedule.
If you have a fixed scope, then allow the schedule to float.
If you have a fixed schedule, then allow the scope to float.
In both cases, your scope should be prioritized with the most
important business value appearing first on the list of things to do.
This means you work on all your "must haves" first with the "nice to
haves" being worked on later. (See the Kano model of customer
satisfaction <https://en.wikipedia.org/wiki/Kano_model>.)
If you do this, then you'll be delivering the most important value to
your business first and if you run out of time, the things that are
dropped are hopefully in the "nice to have" category. Even when you
operate with an assumption of a floating schedule, people get
impatient and they won't wait forever for you to develop the software.
Along the way you have to provide feedback to the stakeholders in your
project. The best way is to give periodic demonstrations of the
software showing the progress that's been made since the last demo.
This is closing the feedback loop between the development team and the
business team.
--
"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>
Geoff
Feb 24, 2015, 4:06:16 PM2/24/15
to
Cheap, fast, correct. Pick any two.
Great post.
-2 points for spelling "no one" wrong.
JiiPee
Feb 24, 2015, 5:14:18 PM2/24/15
to
On 24/02/2015 20:56, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> n...@notvalid.com spake the secret code
> <_CVGw.969747$Ud7.2...@fx11.am4> thusly:
>
>> I asked once my manager, back in 2000, that is it better to make good
>> quality code and use a lot of time for it or make the code fast so that
>> its just working and we get the product quickly out. His response was
>> more like "make it fast".
> 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? At least in chess we
> [Please do not mail me a copy of your followup]
>
> n...@notvalid.com spake the secret code
> <_CVGw.969747$Ud7.2...@fx11.am4> thusly:
>
>> I asked once my manager, back in 2000, that is it better to make good
>> quality code and use a lot of time for it or make the code fast so that
>> its just working and we get the product quickly out. His response was
>> more like "make it fast".
> The choice as you've described it is a false one. It isn't a choice
> between fast and quality.
know that the more time you give Master to analyze a position, the
better moves they make (it can be proven by statistical figures... for
example a human playing like this gets very good results against a
computer, but a human playing faster game against a computer gets worse
results).
> It is a trade-off between scope, cost and
> schedule where "quality" usually falls into the cost category.
> See <https://en.wikipedia.org/wiki/Project_management_triangle>
>
>
>
> In both cases, your scope should be prioritized with the most
> important business value appearing first on the list of things to do.
> This means you work on all your "must haves" first with the "nice to
> haves" being worked on later. (See the Kano model of customer
> satisfaction <https://en.wikipedia.org/wiki/Kano_model>.)
>
> If you do this, then you'll be delivering the most important value to
> your business first and if you run out of time, the things that are
> dropped are hopefully in the "nice to have" category. Even when you
> operate with an assumption of a floating schedule, people get
> impatient and they won't wait forever for you to develop the software.
surely a good strategy
> important business value appearing first on the list of things to do.
> This means you work on all your "must haves" first with the "nice to
> haves" being worked on later. (See the Kano model of customer
> satisfaction <https://en.wikipedia.org/wiki/Kano_model>.)
>
> If you do this, then you'll be delivering the most important value to
> your business first and if you run out of time, the things that are
> dropped are hopefully in the "nice to have" category. Even when you
> operate with an assumption of a floating schedule, people get
> impatient and they won't wait forever for you to develop the software.
Christopher Pisz
Feb 24, 2015, 5:36:27 PM2/24/15
to
I just figure that all managers majored in Business and that Business
majors don't have to learn how to multiply fractions together, but
instead spend most of their time finger painting.
In reality, I think it is a big part of cooperate culture to bid as low
as it takes to secure work, looking only afterward at the budget they've
allowed for their promises. Because it seems, it is OK to lie and
promise something you can't deliver, get the check, and then make
excuses. There doesn't seem to be repercussions.
Some other silly managers, actually do believe in squeezing water out of
rocks.... "We use Agile now, we're suppose to be getting more done
faster", "We have weekly meetings now, we should be getting more done
because you guys can caliberate."...."You're a genious, you'll get it
done by tomorrow somehow"...and you are absolutely right in that they
make their business fail. I've seen shut down after shutdown as a result
of the "water out of rocks" management.
Bo Persson
Feb 25, 2015, 5:51:03 AM2/25/15
to
On 2015-02-24 23:36, Christopher Pisz wrote:
> In reality, I think it is a big part of cooperate culture to bid as low
> as it takes to secure work, looking only afterward at the budget they've
> allowed for their promises. Because it seems, it is OK to lie and
> promise something you can't deliver, get the check, and then make
> excuses. There doesn't seem to be repercussions.
>
A problem is that if you tell the truth up front, you will hardly ever
> In reality, I think it is a big part of cooperate culture to bid as low
> as it takes to secure work, looking only afterward at the budget they've
> allowed for their promises. Because it seems, it is OK to lie and
> promise something you can't deliver, get the check, and then make
> excuses. There doesn't seem to be repercussions.
>
get any checks.
That's worse than being caught with "bad predictions".
Bo Persson
Message has been deleted
Message has been deleted
JiiPee
Feb 25, 2015, 10:00:09 AM2/25/15
to
Martin Shobe
Feb 25, 2015, 10:47:47 AM2/25/15
to
On 2/25/2015 7:08 AM, Stefan Ram wrote:
> Paavo Helde <myfir...@osa.pri.ee> writes:
>> For tutorials, the best text format is indeed ASCII, to avoid delving
>> into unneeded details. For tutorials, also "using namespace std;" is a
>> good idea. Production code will be different in many ways from tutorial
>> code.
>
> When people do /not/ learn how to write production code in tutorials,
> where /do/ they learn to write production code?
When they start writing code that is intended for actual use.
> Why shouldn't there be a tutorial »How To Write Production Code«?
If someone could overcome some major obstacles, there's no reason why
there shouldn't. Examples of obstacles include,
1) A good deal of production code is written by teams. Each team will
have it's own set of restrictions, preferences, and expectations that
will impact how code is written. In other words, there isn't a single
way to write production code.
2) Production code is usually a good deal larger than code that can be
easily fit into a tutorial.
Martin Shobe
> Paavo Helde <myfir...@osa.pri.ee> writes:
>> For tutorials, the best text format is indeed ASCII, to avoid delving
>> into unneeded details. For tutorials, also "using namespace std;" is a
>> good idea. Production code will be different in many ways from tutorial
>> code.
>
> When people do /not/ learn how to write production code in tutorials,
> where /do/ they learn to write production code?
When they start writing code that is intended for actual use.
> Why shouldn't there be a tutorial »How To Write Production Code«?
If someone could overcome some major obstacles, there's no reason why
there shouldn't. Examples of obstacles include,
1) A good deal of production code is written by teams. Each team will
have it's own set of restrictions, preferences, and expectations that
will impact how code is written. In other words, there isn't a single
way to write production code.
2) Production code is usually a good deal larger than code that can be
easily fit into a tutorial.
Martin Shobe
woodb...@gmail.com
Feb 25, 2015, 11:01:41 AM2/25/15
to
Leigh,
Please don't swear or use sexual slurs here.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Please don't swear or use sexual slurs here.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
woodb...@gmail.com
Feb 25, 2015, 11:28:50 AM2/25/15
to
On Wednesday, February 25, 2015 at 4:51:03 AM UTC-6, Bo Persson wrote:
> On 2015-02-24 23:36, Christopher Pisz wrote:
>
> > In reality, I think it is a big part of cooperate culture to bid as low
> > as it takes to secure work, looking only afterward at the budget they've
> > allowed for their promises. Because it seems, it is OK to lie and
> > promise something you can't deliver, get the check, and then make
> > excuses. There doesn't seem to be repercussions.
> >
>
> A problem is that if you tell the truth up front, you will hardly ever
> get any checks.
Yes, you'll pay a price, but it's pay me now or pay me
> On 2015-02-24 23:36, Christopher Pisz wrote:
>
> > In reality, I think it is a big part of cooperate culture to bid as low
> > as it takes to secure work, looking only afterward at the budget they've
> > allowed for their promises. Because it seems, it is OK to lie and
> > promise something you can't deliver, get the check, and then make
> > excuses. There doesn't seem to be repercussions.
> >
>
> A problem is that if you tell the truth up front, you will hardly ever
> get any checks.
1000 times more later.
Brian
Ebenezer Enterprises - "All the world is just a narrow bridge,
the most important thing is not to be afraid." Rebbe Nachman
http://webEbenezer.net
Bo Persson
Feb 25, 2015, 12:11:20 PM2/25/15
to
you are allowed to add more cost later, it's tempting to be VERY optimistic.
I have seen that when some internal projects were actually killed rather
than allocated more money when needed, the estimates for the following
projects were significantly higher.
Is that lying, or adapting to the rules?
Bo Persson
JiiPee
Feb 25, 2015, 12:17:09 PM2/25/15
to
Also other aspects of programming, I basically always tell the truth
(like: "this is gonna take you very long time to get working...so not
sure if its possible")
Mr Flibble
Feb 25, 2015, 12:38:21 PM2/25/15
to
Sausages.
/Flibble
Richard
Feb 26, 2015, 6:40:15 PM2/26/15
to
<PI6Hw.1136027$V%3.47...@fx06.am4> thusly:
>On 24/02/2015 20:56, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> n...@notvalid.com spake the secret code
>> <_CVGw.969747$Ud7.2...@fx11.am4> thusly:
>>
>>> I asked once my manager, back in 2000, that is it better to make good
>>> quality code and use a lot of time for it or make the code fast so that
>>> its just working and we get the product quickly out. His response was
>>> more like "make it fast".
>> 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.
>On 24/02/2015 20:56, Richard wrote:
>> [Please do not mail me a copy of your followup]
>>
>> n...@notvalid.com spake the secret code
>> <_CVGw.969747$Ud7.2...@fx11.am4> thusly:
>>
>>> I asked once my manager, back in 2000, that is it better to make good
>>> quality code and use a lot of time for it or make the code fast so that
>>> its just working and we get the product quickly out. His response was
>>> more like "make it fast".
>> 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?
must ship this game in time for Christmas, not the time required to
develop a feature.
Richard
Feb 26, 2015, 6:42:59 PM2/26/15
to
[Please do not mail me a copy of your followup]
Bo Persson <b...@gmb.dk> spake the secret code
<cl5no1...@mid.individual.net> thusly:
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.
Lynn McGuire
Mar 2, 2015, 8:45:04 PM3/2/15
to
On 2/21/2015 9:05 AM, JiiPee wrote:
> I am trying to learn how to use unicode string.. its not so easy really. And difficult to find a guidelines how to do it. So still
> searching (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make life difficult as many functions like lenght would
> not work).
>
> Everybody say that we should use unicode in our code. If so, then why all turorials and C++ books use almost always char as a
> character type (1 byte)? Why use examples which are not used in real world? This I do not understand.
>
> And even top C++ people like Bjorn does that.
Here is your unicode reference:
http://www.joelonsoftware.com/articles/Unicode.html
Lynn
> I am trying to learn how to use unicode string.. its not so easy really. And difficult to find a guidelines how to do it. So still
> searching (some say use UTF-8 , some UTF-16. but using UTF-8 in a code would make life difficult as many functions like lenght would
> not work).
>
> Everybody say that we should use unicode in our code. If so, then why all turorials and C++ books use almost always char as a
> character type (1 byte)? Why use examples which are not used in real world? This I do not understand.
>
> And even top C++ people like Bjorn does that.
Here is your unicode reference:
http://www.joelonsoftware.com/articles/Unicode.html
Lynn
0 new messages